* 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 scripted. 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? Thierry
Attachment:
signature.asc
Description: Digital signature