Re: On cadence and collaboration
Hi, Julien:
On Wednesday 05 August 2009 22:09:04 Julien BLACHE wrote:
> "Jesús M. Navarro" <jesus.navarro@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.
Reply to: