Re: Debian XSF SVN to git migration
On Thu, Jan 04, 2007 at 07:57:08AM +0100, Thierry Reding wrote: > * David Nusinow wrote: > > On Mon, Dec 25, 2006 at 02:16:23PM +0100, Michel Dänzer wrote: > > > On Sat, 2006-12-23 at 15:29 -0500, David Nusinow wrote: > [...] > > After discussing this with Michel on irc, it doesn't look like it'll be > > possible to use git the way I had written down. I've revised the policy > > based on what Michel and I discussed[0]. > > > > It's much simplified, and basically behaves as you expect it to. If you > > want to work on bleeding edge stuff from upstream, just pulling from the > > debian* branch should give you the packaging. We believe it won't overwrite > > local changes if you've cloned from, say, freedesktop.org because the > > history should be intact. > > > > The one weird thing is that there's no master branch by default, nor is > > there an upstream branch, both of which git-buildpackage expects by default. > > It's trivial to locally create those branches depending on what you're doing > > though. > > > > I'm going to wait a little while longer to see what everyone thinks. I want > > to make sure everyone is back from holidays and had a chance to chew this > > over before we make the move. > > > > - David Nusinow > > > > [0] http://wiki.debian.org/XStrikeForce/git-usage > > The usage page still mentions that upstream changes should be cherry-picked > into the master branch which we won't be using anymore. I'm guessing > cherry-picks should go into upstream-* branches instead of the debian-* ones? Either way is fine by me. The reason I had decided to go with the debian branch was to keep the upstream as close to a linear history as possible. I had envisioned the upstream branch being more like a released version. I guess that having cherry picks go to the upstream* branch is more intuitive though, since everyone seems confused about it, so let's go with that. I'll update the wiki tonight. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian XSF SVN to git migration
* David Nusinow wrote: > On Mon, Dec 25, 2006 at 02:16:23PM +0100, Michel Dänzer wrote: > > On Sat, 2006-12-23 at 15:29 -0500, David Nusinow wrote: [...] > After discussing this with Michel on irc, it doesn't look like it'll be > possible to use git the way I had written down. I've revised the policy > based on what Michel and I discussed[0]. > > It's much simplified, and basically behaves as you expect it to. If you > want to work on bleeding edge stuff from upstream, just pulling from the > debian* branch should give you the packaging. We believe it won't overwrite > local changes if you've cloned from, say, freedesktop.org because the > history should be intact. > > The one weird thing is that there's no master branch by default, nor is > there an upstream branch, both of which git-buildpackage expects by default. > It's trivial to locally create those branches depending on what you're doing > though. > > I'm going to wait a little while longer to see what everyone thinks. I want > to make sure everyone is back from holidays and had a chance to chew this > over before we make the move. > > - David Nusinow > > [0] http://wiki.debian.org/XStrikeForce/git-usage The usage page still mentions that upstream changes should be cherry-picked into the master branch which we won't be using anymore. I'm guessing cherry-picks should go into upstream-* branches instead of the debian-* ones? Thierry signature.asc Description: Digital signature
Re: Debian XSF SVN to git migration
On Tue, Jan 02, 2007 at 11:49:53PM +1100, Drew Parsons wrote: > David wrote: > > After discussing this with Michel on irc, it doesn't look like it'll be > > possible to use git the way I had written down. I've revised the policy > > based on what Michel and I discussed[0]. > > > > It's much simplified, and basically behaves as you expect it to. If you > > want to work on bleeding edge stuff from upstream, just pulling from the > > debian* branch should give you the packaging. We believe it won't overwrite > > local changes if you've cloned from, say, freedesktop.org because the > > history should be intact. > > > > The one weird thing is that there's no master branch by default, nor is > > there an upstream branch, both of which git-buildpackage expects by > > default. It's trivial to locally create those branches depending on > > what you're doing though. > > > > I'm going to wait a little while longer to see what everyone thinks. I want > > to make sure everyone is back from holidays and had a chance to chew this > > over before we make the move. > > > > - David Nusinow > > > > [0] http://wiki.debian.org/XStrikeForce/git-usage > > > Your ideas seem to make sense, though I haven't spent as much time > thinking it all through as you Thierry, Michel and others have. > > With all the various branches coming from different directions all at > once, it's tricky to keep the proposed policy all in one's head all at > once. Would it be possible to commit one of the lesser, smaller modules > to git, one of the protos, say? With some hands on access I think it > might be easier to evaluate whether it all holds together the way we > want it to. libdrm is already there, but it's not quite xorg. Thierry already went ahead with this, and if you want anything else just go for it. I think we've nailed down a good way to handle things for the most part, and anything that's left can be easily repaired later once we sort out the upstream naming stuff. It looks like we're pretty much ready to make the move finally. > Drew > > p.s. The first and third points in the tutorial at > http://wiki.debian.org/XStrikeForce/git-usage, is one of them > redundant? Yeah, the tutorial needs updating. Once we get the upstream naming scheme sorted out, I'll update it and actually make it nice. I'd like to have that page be a lot more comprehensive than it is, and it needs some work. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian XSF SVN to git migration
David wrote: > After discussing this with Michel on irc, it doesn't look like it'll be > possible to use git the way I had written down. I've revised the policy > based on what Michel and I discussed[0]. > > It's much simplified, and basically behaves as you expect it to. If you > want to work on bleeding edge stuff from upstream, just pulling from the > debian* branch should give you the packaging. We believe it won't overwrite > local changes if you've cloned from, say, freedesktop.org because the > history should be intact. > > The one weird thing is that there's no master branch by default, nor is > there an upstream branch, both of which git-buildpackage expects by > default. It's trivial to locally create those branches depending on > what you're doing though. > > I'm going to wait a little while longer to see what everyone thinks. I want > to make sure everyone is back from holidays and had a chance to chew this > over before we make the move. > > - David Nusinow > > [0] http://wiki.debian.org/XStrikeForce/git-usage Your ideas seem to make sense, though I haven't spent as much time thinking it all through as you Thierry, Michel and others have. With all the various branches coming from different directions all at once, it's tricky to keep the proposed policy all in one's head all at once. Would it be possible to commit one of the lesser, smaller modules to git, one of the protos, say? With some hands on access I think it might be easier to evaluate whether it all holds together the way we want it to. libdrm is already there, but it's not quite xorg. Drew p.s. The first and third points in the tutorial at http://wiki.debian.org/XStrikeForce/git-usage, is one of them redundant? -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian XSF SVN to git migration
On Mon, Dec 25, 2006 at 02:16:23PM +0100, Michel Dänzer wrote: > On Sat, 2006-12-23 at 15:29 -0500, David Nusinow wrote: > > > > Ok, after talking to several people, I think we've settled on a good option > > that allows the flexibility we're all after. I've taken a first stab at > > documenting it on the wiki: http://wiki.debian.org/XStrikeForce/git-usage > > > > By separating the packaging and the upstream source, and then merging them > > to actually build the package, we gain pretty much all the flexibility we > > want at the cost of a small amount of complexity. It also makes it easy to > > just pull changes, which is really the model of development that git is set > > up for. > > Right, I've always advocated one branch per tracked upstream branch and > per Debian upload target, so I definitely like that aspect. However, I'm > not sure having completely separate packaging branches with only the > packaging files is feasible. Have you figured out a way to fork several > branches from the initial empty repository, or otherwise to manage > branches with completely disjoint filesets? > > Also, it doesn't make sense to me to special-case the branch for sid, > with a suggestion how to make it consistent with the other branches. I > think it should be the other way around; consistent by default, possibly > with a suggestion how to make it inconsistent if preferred. After discussing this with Michel on irc, it doesn't look like it'll be possible to use git the way I had written down. I've revised the policy based on what Michel and I discussed[0]. It's much simplified, and basically behaves as you expect it to. If you want to work on bleeding edge stuff from upstream, just pulling from the debian* branch should give you the packaging. We believe it won't overwrite local changes if you've cloned from, say, freedesktop.org because the history should be intact. The one weird thing is that there's no master branch by default, nor is there an upstream branch, both of which git-buildpackage expects by default. It's trivial to locally create those branches depending on what you're doing though. I'm going to wait a little while longer to see what everyone thinks. I want to make sure everyone is back from holidays and had a chance to chew this over before we make the move. - David Nusinow [0] http://wiki.debian.org/XStrikeForce/git-usage -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian XSF SVN to git migration
On Sat, 2006-12-23 at 15:29 -0500, David Nusinow wrote: > > Ok, after talking to several people, I think we've settled on a good option > that allows the flexibility we're all after. I've taken a first stab at > documenting it on the wiki: http://wiki.debian.org/XStrikeForce/git-usage > > By separating the packaging and the upstream source, and then merging them > to actually build the package, we gain pretty much all the flexibility we > want at the cost of a small amount of complexity. It also makes it easy to > just pull changes, which is really the model of development that git is set > up for. Right, I've always advocated one branch per tracked upstream branch and per Debian upload target, so I definitely like that aspect. However, I'm not sure having completely separate packaging branches with only the packaging files is feasible. Have you figured out a way to fork several branches from the initial empty repository, or otherwise to manage branches with completely disjoint filesets? Also, it doesn't make sense to me to special-case the branch for sid, with a suggestion how to make it consistent with the other branches. I think it should be the other way around; consistent by default, possibly with a suggestion how to make it inconsistent if preferred. -- Earthling Michel Dänzer | http://tungstengraphics.com Libre software enthusiast | Debian, X and DRI developer
Re: Debian XSF SVN to git migration
On Sat, Dec 23, 2006 at 03:29:37PM -0500, David Nusinow wrote: > up for. Please reply, if for nothing else, to give your approval, so I can > feel comfortable pushing ahead with the move :-) Or, obviously, if you loathe the idea and have a better one :-) - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian XSF SVN to git migration
On Thu, Dec 21, 2006 at 09:52:56PM -0500, David Nusinow wrote: > On Tue, Dec 19, 2006 at 02:32:48PM +0100, Thierry Reding wrote: > > First of all is the question of the repository layout. What was clear from > > the start is that we'd like to mirror the directory structure from upstream. > > The second issue is what to do with the upstream sources. So far the > > alternatives we've been discussing are 1) having selected upstream branches > > cloned into our repositories and 2) leaving it up to the packager to use > > upstream branches in their local clones of the Debian repositories. Does any > > of these alternatives have a significant advantage over the other? Is there > > perhaps a different approach that would work even better? > > To me, the most important thing is consistency. Having to do two or three > different things depending on the packager is just going to be an > irritating barrier to getting anything done, especially if we want to > attract new people. From my experience, we definitely want to keep > attracting people. Ok, after talking to several people, I think we've settled on a good option that allows the flexibility we're all after. I've taken a first stab at documenting it on the wiki: http://wiki.debian.org/XStrikeForce/git-usage By separating the packaging and the upstream source, and then merging them to actually build the package, we gain pretty much all the flexibility we want at the cost of a small amount of complexity. It also makes it easy to just pull changes, which is really the model of development that git is set up for. Please reply, if for nothing else, to give your approval, so I can feel comfortable pushing ahead with the move :-) - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian XSF SVN to git migration
David Nusinow <[EMAIL PROTECTED]> writes: > It's a tough choice. The ease of use of stgit sounds really nice to me, but > I also love the transparency that having the patches in a location like > debian/patches affords us. I'm not horribly worried about that though, but > it is a real benefit. We can get around that by artificially exporting all > the patches to debian/patches. It's more work, although I'd be happy to > write a simple script to do this. My feeling is that this would be the best > of both worlds. What do you guys think? I personally loves stgit and we're using it here on the company to follow projects that use other patch systems like svn or when we're developing a not yet ready for merging change. It does great. The only problem that I found on stgit is the difficult to push its full meta-data for the git repository. The only way I've found is to use rsync. Comments on that? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian XSF SVN to git migration
On Wed, Dec 20, 2006 at 10:28:07PM -0500, David Nusinow wrote: > On Wed, Dec 20, 2006 at 01:02:45PM +0100, Thierry Reding wrote: > > * Otavio Salvador wrote: > > > That means we'll stop to use the quilt to manage the patches and leave > > > git to manage all delta between Debian and original upstream code? > > > > That is still something that's up for discussion. I think stgit was being > > considered as an alternative to quilt for managing the Debian-specific > > patches. As I understand it, it's pretty much the same as quilt only it's > > using git as backend. > > When we last had this discussion[0], everyone was in favor of keeping the > quilt system. No one really spoke up in favor of stgit, although it was > listed as an option. Given that discussion, and a currently working patch > system with quilt, I think we should keep using quilt. > > - David Nusinow > > [0] http://lists.debian.org/debian-x/2006/08/msg00110.html Looking at this again, let's do a more serious analysis before making rash decisions. The benefits of quilt: 1) We already know it works and works well. We've had no problems related to quilt since we adopted it. stgit is an unknown at this point. 2) We already have both our own and the quilt package's makefile stuff written 3) Because of (2) we can easily customize it to fit our needs. This allows things like patch-audit (I'm not sure if stgit can be customized this easily. Does anyone else know?) 4) quilt has become more popular, and so it's generally well known to the general developer population 5) Each patch is a file, which makes it very easy to extract them for things like emailing them. It's also trivial to see which patches we apply simply by looking at git.debian.org 6) quilt is somewhat transparent because of this. Anyone can look in debian/patches and see what we're applying. They have to know that this exists though. Now the benefits of stgit: 1) Integrates very nicely with git. Having it as an extension to the git interface is really lovely. 2) Probably more transparent to upstream or other people less familiar with Debian packaging. Just tell them that debian-specific patches are in stgit, and they already know the interface to use it. 3) Working with it day to day will probably be a lot easier than using quilt. quilt requires you to set an environment variable to tell it where the patches directory is, and so forth, or use the symlink scheme like we currently have. stgit just works. 4) The .diff.gz becomes easier to read. Rather than looking at diffs of diffs like the current scheme, you just look at a diff. 5) No makefile stuff! We'll probably have to adapt git-buildpackage to automagically push all the patches before building, but this should be trivial. 6) Integrates very nicely with qgit (though not gitk yet). It's a tough choice. The ease of use of stgit sounds really nice to me, but I also love the transparency that having the patches in a location like debian/patches affords us. I'm not horribly worried about that though, but it is a real benefit. We can get around that by artificially exporting all the patches to debian/patches. It's more work, although I'd be happy to write a simple script to do this. My feeling is that this would be the best of both worlds. What do you guys think? - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian XSF SVN to git migration
On Tue, Dec 19, 2006 at 02:32:48PM +0100, Thierry Reding wrote: > First of all is the question of the repository layout. What was clear from > the start is that we'd like to mirror the directory structure from upstream. > The second issue is what to do with the upstream sources. So far the > alternatives we've been discussing are 1) having selected upstream branches > cloned into our repositories and 2) leaving it up to the packager to use > upstream branches in their local clones of the Debian repositories. Does any > of these alternatives have a significant advantage over the other? Is there > perhaps a different approach that would work even better? To me, the most important thing is consistency. Having to do two or three different things depending on the packager is just going to be an irritating barrier to getting anything done, especially if we want to attract new people. From my experience, we definitely want to keep attracting people. Also, I'm in favor of option 1 myself. Given the toolset, it seems to be the easiest option and the one with the least surprise. There's several advantages to it that I see: 1) Anyone who clones our repository will get the whole source code, making it easier to see what's going on. It also makes it easier to do work on the package right away. Encouraging people who aren't normally involved to get involved, if for nothing else than to submit a single patch, is something we should place as a high priority. It also has the side benefit of helping ensure that we all have the same repositories. 2) It allows us to easily cherry-pick from upstream. If we don't keep the source tree in the repo, we have to apply all changes using quilt the way we do now. This is extra hassle, and it's kind of silly given that we don't need to keep these patches separate from the mainline codebase across upstream revisions, which really is the primary benefit from using quilt. Now for the other option, keeping just the debian directory in the repo by default. The advantages that I see for this are 1) Less to download for the user who just wants to look at the packaging. Honestly though, I see this as a very small gain because most people will probably be interested in the code. The alioth guys don't have a problem with us keeping the whole repo there, so server space isn't an issue. And as keithp likes to harp on, disk space is cheap :-) 2) Fairly simple integration in to existing git repos. This is similar to the first, in that x.org developers who already have upstream git checkouts need only add our repo to their remotes and check out the minimum necessary to build the debian package. Then they can do whatever customization they like. Again, this is a minimal gain, and can be potentially harmful since we aren't ensuring that that person has what the packaging claims by default. I was actually pretty well in favor of this option originally, but after exploring the actual mechanics of how it would work, I think importing the source in to our repo is a good idea. git-buildpackage requires you to import the source in to the repo anyway (git-import-orig does this) and then merges it to master to build, so our scripting requires the source to be in the tree anyhow. My feeling is that we should just do this once and keep it in the repo so everyone building the package doesn't have to repeat the work. - David Nusinow -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian XSF SVN to git migration
On Wed, Dec 20, 2006 at 01:02:45PM +0100, Thierry Reding wrote: > * Otavio Salvador wrote: > > Thierry Reding <[EMAIL PROTECTED]> writes: > > > > > A very related issue is how to work with Debian-specific branches. Should > > > we > > > use a master branch which we keep the packaging files in and into which we > > > merge/cherry-pick from the upstream branches as necessary? Or would it be > > > better to have separate upstream and Debian branches and merge those two > > > into > > > the master branch? What we're looking for is the easiest way to pull and > > > push > > > patches so we can keep the difference between the Debian packages and > > > upstream as small as possible. > > > > That means we'll stop to use the quilt to manage the patches and leave > > git to manage all delta between Debian and original upstream code? > > That is still something that's up for discussion. I think stgit was being > considered as an alternative to quilt for managing the Debian-specific > patches. As I understand it, it's pretty much the same as quilt only it's > using git as backend. When we last had this discussion[0], everyone was in favor of keeping the quilt system. No one really spoke up in favor of stgit, although it was listed as an option. Given that discussion, and a currently working patch system with quilt, I think we should keep using quilt. - David Nusinow [0] http://lists.debian.org/debian-x/2006/08/msg00110.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Re: Debian XSF SVN to git migration
* Otavio Salvador wrote: > Thierry Reding <[EMAIL PROTECTED]> writes: > > > A very related issue is how to work with Debian-specific branches. Should we > > use a master branch which we keep the packaging files in and into which we > > merge/cherry-pick from the upstream branches as necessary? Or would it be > > better to have separate upstream and Debian branches and merge those two > > into > > the master branch? What we're looking for is the easiest way to pull and > > push > > patches so we can keep the difference between the Debian packages and > > upstream as small as possible. > > That means we'll stop to use the quilt to manage the patches and leave > git to manage all delta between Debian and original upstream code? That is still something that's up for discussion. I think stgit was being considered as an alternative to quilt for managing the Debian-specific patches. As I understand it, it's pretty much the same as quilt only it's using git as backend. Thierry signature.asc Description: Digital signature
Re: Debian XSF SVN to git migration
Thierry Reding <[EMAIL PROTECTED]> writes: > A very related issue is how to work with Debian-specific branches. Should we > use a master branch which we keep the packaging files in and into which we > merge/cherry-pick from the upstream branches as necessary? Or would it be > better to have separate upstream and Debian branches and merge those two into > the master branch? What we're looking for is the easiest way to pull and push > patches so we can keep the difference between the Debian packages and > upstream as small as possible. That means we'll stop to use the quilt to manage the patches and leave git to manage all delta between Debian and original upstream code? -- O T A V I OS A L V A D O R - E-mail: [EMAIL PROTECTED] UIN: 5906116 GNU/Linux User: 239058 GPG ID: 49A5F855 Home Page: http://otavio.ossystems.com.br - "Microsoft sells you Windows ... Linux gives you the whole house." -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Debian XSF SVN to git migration
Hi all, The Debian X Strike Force is about to move their repository for X-related packages from SVN to git. The scripts we use for the migration seem pretty much finished, but there are a couple of issues that still need discussion. I'm Cc'ing the X.org mailing list because we want to make it as easy as possible for you to see what we're doing and would appreciate any help or insights you could share. I guess the results of this discussion could be equally useful for other distributions that want to use git for packaging purposes. First of all is the question of the repository layout. What was clear from the start is that we'd like to mirror the directory structure from upstream. The second issue is what to do with the upstream sources. So far the alternatives we've been discussing are 1) having selected upstream branches cloned into our repositories and 2) leaving it up to the packager to use upstream branches in their local clones of the Debian repositories. Does any of these alternatives have a significant advantage over the other? Is there perhaps a different approach that would work even better? A very related issue is how to work with Debian-specific branches. Should we use a master branch which we keep the packaging files in and into which we merge/cherry-pick from the upstream branches as necessary? Or would it be better to have separate upstream and Debian branches and merge those two into the master branch? What we're looking for is the easiest way to pull and push patches so we can keep the difference between the Debian packages and upstream as small as possible. Those are the major issues I can currently think of, but if I've left something out feel free to raise anything you think could be important. - Thierry signature.asc Description: Digital signature
