Le vendredi 09 mars 2007 à 21:43 +0100, Loïc Minier a écrit : > The most important change I I would like to do is to introduce a trunk/ > branch. Its role would be to centralize all packaging fixes and track > the newest packaged upstream release. I don't have really anything against it, but I fail to see what it would bring over the current scheme. > I see two reasons to have a trunk: > - we currently have no defined merge process, so we commit some changes > in unstable and other changes in experimental; we then have to guess > how to merge the branches together: merge from unstable to > experimental, or the other way around, or both ways... This is > suboptimal and risky. We'll still have to merge things from the trunk to the other branches. What exactly would it bring? > - we have no place to prepare the latest upstream development releases, > experimental only allows for one more GNOME series which is > currently GNOME 2.16 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. > Using tags/ could be a nice addition as we currently don't have an easy > way to retrieve the debian/ of a package. I understand it adds a > burden; I'm fine with or without, please voice your preference. 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. > My personal preference goes to not having a "branches/" dir. Mine would as well. I'm not even convinced of the usefulness of this layout for a traditional development scheme. > My personal preference goes to a layout similar to the current one (2), > or a flat layout (1) as I think modules move between sections, or gain > / lose official status, and also to make merge URLs a bit simpler to > type. Layout (3) is more elegant, but I agree that for everyday use layout (1) is the simplest. -- .''`. : :' : 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?=