Le jeudi 15 mars 2007 à 10:48 +0100, Loïc Minier a écrit : > > We'll still have to merge things from the trunk to the other branches. > > What exactly would it bring? > > Not only would it be clear in which way you have to do the merge -- and > hence more scriptable -- but also the responsability of the merge would > IMO be clearer. Of course, as Sjoerd reminded us, we should document > the process better, but currently we all commit stuff in whatever > branch we're doing an upload, but we do not always merge to the other > branches. In the case of a trunk, it would be clear that each > packaging change which is not specific to a dist should be made or > merged in trunk, and dist specific changes would only be done in the > dist branch, not in trunk. It makes it clearer which changes are > specific to a dist or not, and it encourages making this distinction at > the time the change is made ... instead of scratching one's head at the > time of the merge. I've always considered the latest version this way, and was hoping other people were doing the same. If you believe changing the name to "trunk" can help that, then let it be, but it's a bit annoying to see a name change - which will mess up the whole history of the repository - for such a frivolous reason. Admittedly, it will help us in the future to always keep the correct history in the trunk. You should also consider that, without a clear separation between experimental and unstable, we lose the view of which packages have been uploaded to which archive. Of course, there are some web summaries, but they don't give such a clear view when actually working on the packages. > > This, I disagree with. We have experimental for that purpose. We should > > not make the current situation (experimental as a staging area for > > already stable upstream packages) the norm. > > Unfortunately, with our current release strategy, there will always be > a problem between a 6 months upstream version freeze in Debian and a 6 > months release cycle upstream. More and more voices are asking for a more aggressive release strategy. I'd like to know how the lenny release will be handled before making such decisions. > Also, we have no place to prepare packages of development versions > which we do not want to publish to everybody. I think we need a place > to prepare the latest available tarballs -- and perhaps upload these to > a private archive, such as on alioth -- to be ready to do massive > uploads of a new GNOME release. This can also serve to confirm a bug > has been fixed upstream or to test development releases of GNOME before > uploading them to an official archive (even if it's experimental). First, I'd like to be convinced that we have the manpower to package development releases. Currently it seems very unlikely. Furthermore, there's little point in building packages if no one uses them. > > I agree it would be nice to have, but without some automation it won't > > be as helpful. We already often forget to commit what we upload or to > > upload what we commit. If there is one more step, we're likely to forget > > it even more often, or, like it happened when branching for the last > > stable, to tag the wrong version. > > svn-buildpackage supposedly has such support; I'm not too happy with it > (#414564), but once fixed it should be good enough. Rather than tagging at svn-buildpackage time, when it's too early to know whether the package actually works, I'd prefer something like a svn-dput wrapper which would do everything in a single run. > > Layout (3) is more elegant, but I agree that for everyday use layout (1) > > is the simplest. > > What do you think of layout 2 which is somewhat between 1 and 3 in > terms of hashing? It's sjoerd's and my preferred one, and close to the > current one (the name are a bit more explicit in my example than in the > current repository, with official = admin + bindings + desktop + > devtools + platform). Especially the concept of "extra" is used in > a lot of teams. If we switch to layout 1, we have a (small) improvement as generally, when we work on packages, we don't wonder whether they are platform, desktop or extra. We just know the package name. I wouldn't be really bothered by other layouts, but keeping 2 with just a rename seems gratuitous. Now, if you want to do this rename as part of a global renaming which is needed for other reasons, I don't f*cking care of the new names. You can call them Hansel & Gretel, or Laurel & Hardy if you want. -- .''`. : :' : We are debian.org. Lower your prices, surrender your code. `. `' We will add your hardware and software distinctiveness to `- our own. Resistance is futile.
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=