[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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 

> 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) 

> 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: