Re: On cadence and collaboration
"Jesús M. Navarro" <jesus.navarro@undominio.net> wrote:
Hi,
>> I think we'll lose part of the "we release when it's ready" philosophy
>> (that our RMs seem to despise so much). Because part of this is to
>> freeze when it's ready.
>
> Not at all if done properly. Freeze on a date simply means that what it's
> ready on that date is included, what it's not ready won't be included, simply
> as that. When you couple that with a freeze date well known in advance, you
> allow interested people to plan properly.
The freeze date for the past few releases has always been known in
advance and refined as we went. The problem is that a lot of
upstreams do not have a planning that we can compare against and base
our work upon, so for a lot of the packages we "just" follow upstream.
Not to mention our very own infrastructure issues that have bitten us.
> (pleeease, wait for another two weeks for our new and shinny).
That's largely an end-user-induced issue, desperately trying to escape
the "Debian obsolete" nickname for Debian stable. We're weak ;)
>> A time-based freeze could mean for some teams that they'll have to
>> stop work basically for months to a year. It already takes too much
>> time to recover after a release, this won't help.
>
> 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.
> everbody's bag that it is 'experimental' that has demonstrated not to be a
> solution at all). This needs to be changed and I expect the time-based
> freeze to be the tick that will finally push this change.
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).
> If that's what you meant, I think you don't have an argument against
> time-based freezes but against the "first time-based freeze on Dec-2009" but
A lot of things need to line up for a release. Debian is very large
and the windows of opportunity are few and small. 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). Seriously, everybody gets bored and fed up
during a freeze.
I am of the opinion that no matter how hard you try, you can't *make*
a Debian release 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.
> 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?
>> In this day and age, you have to look at features in addition to the
>> version number, because the latter isn't necessarily very telling of
>> the real changes from one release to another. Major features are
>> delivered in minor releases nowadays...
>
> I already said that to be simply malpractice and beyond a distribution's
> ability to correct (while I'm with Shuttleworth in that concurrent freezes
> would help to "show the proper path" to upstreamers).
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)
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: