[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: git-migration: Changes to 'master'

* David Nusinow wrote:
> On Wed, Jan 03, 2007 at 05:53:29PM +0100, Thierry Reding wrote:
> >  clone |   26 ++++++++++++++++++++++----
> >  1 files changed, 22 insertions(+), 4 deletions(-)
> > 
> > New commits:
> > commit 0726222645eb8e6e4f25056e8f7244b4566825e3
> > Author: Thierry Reding <thierry@gilfi.de>
> > Date:   Wed Jan 3 17:50:06 2007 +0100
> > 
> >     Implement the proposed XSF git archive policy.
> > 
> Why did you use 'upstream-master'? I probably was unclear in what I wrote
> down, looking back on the draft. What I had in mind was
> 'upstream-unstable', 'upstream-experimental', etc. I'm not certain that
> this is the best way to divide up the branches though. Do you think having
> 'upstream-master' is a better way of handling things?
>  - David Nusinow

We've already discussed this on IRC, but here goes for everyone to read:
since it's pretty difficult to figure out which tags to create the upstream-*
branches off for each package, I thought to just put upstream-master into the
repositories so that there would be some reference from which the other
branches could be split off.

After discussing this with David on IRC, I believe it would be better to
rename upstream-master to upstream-unstable. Since we're pretty much at the
beginning of a new release cycle, it would be the logical choice to have
unstable track upstream's master. Once upstream tags releases,
upstream-unstable could be updated to those tags to comply with the policy.
This would leave it up to people working on the packages to create the
upstream-etch (based off the corresponding upstream tag) and debian-etch
branches for etch support. The same goes for experimental packages or for
lenny once we get to its freeze.

For some packages upstream's master might not be the optimal choice (take the
X server for instance), but it should be possible to roll back upstream- and
debian-unstable to some other tag or branch manually later on. We've settled
on this primarily so most of the cloning, naming and possibly pushing can be

It would still be good to have upstream's master branch when working on a
package (for cherry-picking), so we've been thinking about ways to make it as
easy as possible to pull it in while keeping it out of the Alioth
repositories. Since git doesn't support anything similar to svn:externals and
hooks don't seem to be able to do this when a repo is cloned, the only
alternative would seem to be a script that needs to be run manually on each
repository that clones upstream's master branch into the local repository.

Does this sound about right to everyone?


Attachment: signature.asc
Description: Digital signature

Reply to: