Re: On cadence and collaboration
"Jesús M. Navarro" <jesus.navarro@undominio.net> wrote:
Hi,
>> That's exactly my point. We suck at freezing.
>
> The problem is not "we suck at freezing". Quite on the contrary I think
I should have written "we suck at operating during the freeze" or
something alike, that was a bit of a bad shorthand :)
> 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.
All things considered (size and nature of the project, nature of the
contributions, governance model, ...) I think we're doing amazingly
well. It could be a lot worse, especially given nobody has ever done
that before. We're bigger than any other project, nobody has been
there before us.
> 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.
Back in the days, frozen was just that and unstable was carrying on
with its life (with a bit less activity, but only a bit). Today,
unstable is just as frozen as testing is during the freeze.
In the end, testing kind of works to prepare a consistent set of
packages that we can freeze at some point, so it's a good development
tool, but it's not a good release tool.
WRT unstable, testing is a step backward.
>> 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
If you're talking of freezing/releasing different sets of packages
more or less independently etc, this has been discussed to death
already.
> You forget that on a branched dependency path it would be quite difficult for
> something really nasty reaching testing (for a conceptually similar approach
It's not that difficult. It does happen, simply because since the
testing introduction (and Ubuntu) we have less users using unstable
and reporting bugs. The direct consequence is that bugs do make it to
testing more than we'd like.
>> 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.
Both, actually.
>> 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.
My point exactly. You can *only* help the process. I understand just
how frustrating that can be for release managers, but it's something
that you need to accept to do this job.
>> 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
Absolutely.
> 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.
I think there's been a real push over the last years and a lot more
DDs are focused on getting releases out the door now. We talk about
releasing more than ever, so this cannot escape anyone nowadays.
As for the cadence, the 18/24 months is something that looks like it
can work repeatedly and is generally a good pace for us etc.
So, in a nutshell, it's all there already, though not as formal as
some would like it to be, it seems.
>> > 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.
Fair enough.
>> What we'd need is some sort of "upstream academy" where we could teach
>> upstream:
[...]
> 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
I think something more interactive and hands on would be best. "RTFM"
never worked that well in this case.
JB.
--
Julien BLACHE - Debian & GNU/Linux Developer - <jblache@debian.org>
Public key available on <http://www.jblache.org> - KeyID: F5D6 5169
GPG Fingerprint : 935A 79F1 C8B3 3521 FD62 7CC7 CD61 4FD7 F5D6 5169
Reply to: