Hi, Julien: On Wednesday 05 August 2009 22:09:04 Julien BLACHE wrote: > "Jesús M. Navarro" <jesus.nava...@undominio.net> wrote: >
[...] > > > > Why? I really don't see your point unless you mean for the packager > > under current conditions where no real branches are allowed on Debian > > (but the > > That's exactly my point. We suck at freezing. The problem is not "we suck at freezing". Quite on the contrary I think Debian developers, the release team, the debian-installer team... all of them have done a really *amazing* work in the past, and I can say this without being suspected being just "a mere user" myself. The problem is that there's no non-sucking way to freeze the vast amount of packages and archs managed by Debian as a monolithic single entity. In the early days of Debian, the lesser number of packages and archs made (barely) possible the monolithic freeze. When people where overhauled (I think I remember it by the slink->potato or maybe potato->woody days) new tools pushed forward the frontier (and due to this package and arch numbers skyrocketeed), then the woody->sarge days again exposed the problem. The "monolithic freeze" is the simplest way both technically and from perception but maybe it's time to look for less straigthforward but more powerful ways to deal with the engineering challenges a project like Debian rises. > It all boils down to the current testing system being inadapted to our > needs. But that's something we couldn't really know for sure until we > had tried it for a couple of releases, and I think we still won't know > for a release or two because of the new tools that have been put in > place to handle transitions (and others). They might help but only on a "diminishing returns" way: it is the management itself (the monolithic freeze concept) the one that is being stretched past its natural bounds (where complexity tends to grow exponentially as the number of packages/archs -and DDs! grow just linearly). > A lot of things need to line up for a release. Debian is very large > and the windows of opportunity are few and small. True. But that adds more value to the cartesian "divide and conquer" idea for problem approaching. This, of course, wouldn't be without its own share of problems, but they would probably be less weigthening (instead of a release being done three years from the last one as is to-date the worse case scenario with current methods, you would have a "less than glamorous" but decently actualized release on time due to the shiny changes not being in time to be on board -but they'll have a new chance on next release). > Deciding on versions > of core packages between distributions could help, but a fixed-date > freeze probably won't. It could even make things worse, as it could > make it harder to iron out the issues (like having to convince the > release team to let a new upstream in to fix something because there's > really no better way). You forget that on a branched dependency path it would be quite difficult for something really nasty reaching testing (for a conceptually similar approach see FreeBSD backports from CURRENT to STABLE; No: CURRENT->STABLE->RELEASE is not the same as Unstable->Testing->Stable although it might seem at first glance) and, of course, everything (but death) can have its (rare) exceptions. > Seriously, everybody gets bored and fed up > during a freeze. Not because of the freeze itself but because it takes so long. Again, i.e. FreeBSD devels don't feel that pain and they still manage to produce quite robust releases. > I am of the opinion that no matter how hard you try, you can't *make* > a Debian release happen. I never thought about it that way but I think you marked the bull-eye. I think to remember something Schopenhauer said once about intuitions. And then, following Schopenhauer on this, although you cannot "make it happen" you still can make it easier for it to happen. > There's some point at which the release > starts to happen, a point where a critical mass of DDs is reached, the > point where everybody uses the word "release" more than any other > word. All of which have some very real technical grounds and a heavy psycological nature too. Just the fact of being seriously comitted to a time-based release instead of current "we aim towards this or that date" that nobody takes really seriously but as a wishful grosstimate would heavily help for the critical DD mass and the "going for the release" attitude to happen. > > > to push it to a latter date in order to have time for the tools to be > > developed (hey, Mr. Canonical, there you have a very interesting case > > where your hands and moneys would certainly be more than welcome). > > Remember dunc-tank? Yes, but I don't think it as a demonstration that "money can't really help" (or can just really help that much) but as a misguided and mistimed attempt doomed to fail. > What we'd need is some sort of "upstream academy" where we could teach > upstream: > - how to version properly > - how to properly manage their API/ABI for shared libraries > - how not to make a mess of their release tarball > - ... (let's not make a list, it'd be depressing) Yes... It might be worth it some kind of "best practices" manual coupled with some kind of peer-review process for such practices (the equivalent to the ISO-9001 for community based development only that due to its open nature it would work instead of being a misguiding piece of paper) which would allow for some kind of objective assertion on the quality/maturity of a project. -- To UNSUBSCRIBE, email to debian-project-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
