GCC SVN vs. BZR/LP
ams at codesourcery.com
Tue Nov 9 13:36:32 UTC 2010
On 09/11/10 12:55, Ira Rosen wrote:
> * We can't really apply anything we want just for ourselves
> Why? It will be our "private" Linaro branch. We can apply whatever we
> want there (we can also decide on reviewers and/or some submit/commit
> procedure). We can mark our patches with both [<our branch name>] and
> [4.7] when we send them to gcc-patches.
Applying patches that are not intended to go upstream would defeat the
object of easing the merge. We'd need to revert all those bits before
merging. It'd be clearer and easier to commit the individual patches we
do want upstream one at a time when the time comes.
> * Write permissions not clear.
> Do you mean we have people without GCC write-after-approval permissions?
Well, yes, but I'm assuming there aren't many of those. The question
that was raised what about who is permitted to add junk into the GCC
repo. I believe that it's not a problem, but I'm not certain. There's
also the question of what the assignment status of patches on branches
needs to be?
> I think the big question here is, when will we start wanting to make
> (unstable/experimental) Linaro GCC 4.6 releases? If we want to do it
> early, then we'll have no choice but to have an LP branch to release
> Again, I don't understand why our SVN branch needs to be stable ;)
I don't think I said it had to be? My point is that numbered Linaro GCC
releases really ought to be tagged in a LP branch somewhere. This is
simply good practice, and not about stability. My 'unstable' comment was
merely pointing out that pre-4.6.0 snapshots should not be marketed as
trusted, high-quality releases.
More information about the linaro-toolchain