Sorry for the late reply, but I've been busy thinking about that last days, and I've reached no conclusion yet. On 27/05/2008, Miriam Ruiz wrote: > Right now we have two different repositories, SVN and git. Until now, > everything was stored in SVN, and all the packages followed a certain > policy [1] (everything in debian/, patches with quilt, debhelper and > so), so everyone knew how to manage it. With the second repository, > the git one, the games might be packaged differently to SVN ones. I > not that familiar with git (yet), fur AFAIK git might be kind of an > alternative to quilt, isn't it? Disclaimer: I don't follow vcs-pkg (yet), so the following will be based on my own views about Debian packaging done with git. Basically, there are two ways to handle that. One is very similar to the current policy we have with svn: only store debian/ under git, and that's all. A possible layout is having branches called “unstable”, “etch-backports”, etc., and you can play with git branching capabilities to merge latest unstable into the etch backport branch quite efficiently (usually, only a matter of tweaking the changelog). Additionally, one can keep track of the upstream branch, as a *separate* branch. That helps keeping a copy of the upstream files around, and can even provide with the ability to regenerate pristine (bit-identical) tarballs, for a ridiculous cost, using pristine-tar. Another one is to have an upstream branch from which you branch a debian-unstable one, and do your packaging in that branch. That way, it's very clear that you branched from or merged into this or that branch, etc. The first one implies a rather low learning curve, especially since we've been doing the same with svn. That's also what I have been using for all my packages for quite some time now (from graphviz.git's log, looks like since Apr 2007), and I'm very happy with it. The second one means that one is stronger connected to the upstream branch, and also means (I think) extra git skills to be done properly. I've been thinking about it for pkg-games, but I'm still undecided whether we should be giving it a shot, or whether we should just stick to the “easy” one. Since I'm still in doubt, I think I would got for the first layout, since I feel it's a safe bet. About your “git might be kind of an alternative to quilt”, I think you mean that with that second layout, the series of (Debian) patches is the list of commits between the upstream branch and your debian branch. If that's not what you meant, I shall point that with the first layout, one is still supposed to use a patch system (e.g. quilt) to manage the patches stored in debian/patches (and again, that's what I've been doing for all my stored-in-git packages). > We still have to decide if the same policy that for SVN applies to the > git one. I'm a bit concerned about the team ending up with two > separate repositories handled so diferently that the learning curve > for the game develoopers would be harder. Until now, all you had to do > was download all the SVN data, change all the files, in some cases > with just a script, and it was done. I don't know how to handle those > situations now with some games in SVN and packages a certain way, and > other games in git packaged in a very different way. From a quick look some days ago, looks like the second layout was chosen. > As we will soon have to import quite few games to git, as they already > come from other git repositories, we should have to decide on how to > handle them. I not really that familiar with git so as to have an > opinion, so everyone is invited to step in and make suggestions. This > might be considered as a kind of reengineering process, so feel free > to throw your suggestions, whatever they are, and lets see what comes > from there. At some point we'll have to decide on a newer policy for > our repositories that handles the newer git one. Agreed, so that everyone is able to understand how things are being stored, and how to use/work on them. Mraw, KiBi.
Attachment:
pgpV8HxZQ0BDg.pgp
Description: PGP signature