Re: so what? Re: Debian development modem
Hi. I apologize in advance for the somewhat negative tone of my reply.
I think that Ian's proposal is unrealistic, and does not address our
current problems at all.
Ian Jackson wrote:
> We must decouple our development tracks much more. I propose that we
> resolve never again to plan a release with is not fully backward
> compatible with the current stable version.
I don't see any way we could have preserved compatibility more than
we did, with the hamm release. The entire altdev scheme was devised
for it. What more could have been done?
> We should abandon the idea of `release goals'. Instead, if someone
> thinks a thing definitely needs doing by the time of a release, they
> do it. If it doesn't get done then we release anyway.
"They do it" is easily said, but it runs counter to the principle of
letting maintainers have the final word on their packages. That
principle is the main reason why absentee maintainers are such a
problem. Do you propose to drop it?
> So, in detail:
>
> Every three months (fixed date) we copy the current `unstable' into
> `frozen'. At this point `stable', `frozen' and `unstable' should all
> stay interoperable both in source and binary form.
This is still a major operation at every freeze time. I like the
"stable pool" approach much better. That way we are ready to release
*at any time*, modulo newly discovered bugs in the stable packages
that have to be fixed.
(How much a problem such bugs are probably depends on how well we automate
the process of getting bugfixes into the stable pool.)
> Bugfixes must be applied to frozen, and important ones to stable too.
> After one or two months of beta frozen should be stable enough to
> release.
What happens if the bugs don't get fixed? Release buggy packages?
Deciding not to release a package that has grave bugs is entirely
different from threatening to burn the house down.
> [...] Probably our libc7 distribution will still
> have libc5 programs in it - but that's fine !
>
> If it's not fine with you then let's not hold up the releases -
> instead, go and fix those packages.
It's not fine with me if hamm is released with "crafty" in main,
because crafty is not DFSG-free. How do I fix that?
(I'm taking examples here for the sake of specificness, I don't mean
to pick on them.)
It's also not fine with me if hamm is released with a non-working p2c.
(The package is currently orphaned). That doesn't mean I want to fix
it, since I have no interest in p2c. Unless someone cares enough to
maintain it, it should be dropped from the distribution. How do I
"fix" that?
> We also need to make automatic building a real possibility.
Now this I agree with. It is already happening. Witness netgod's
recent efforts at getting the sparc tree up to date, he uploaded
some 300 packages in one day.
Richard Braakman
--
To UNSUBSCRIBE, email to debian-devel-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
Reply to: