On Sat, Oct 23, 2004 at 12:56:36PM +0200, Eduard Bloch wrote:
> One of the first and most known things: it puts a lot of outdated packages on
> the head of our users! Yes, testing sounds like a good compromise for people
> that want to have bleeding edge software without taking the risk, but we saw in
> the past years that testing created more problems that it was really worth.
Excluding RC bugs and complications, the wait time for a package to reach
testing from unstable is 10 days. The lifetime of a stable release is much
longer than 10 days, during which time all of those packages are "outdated".
Why is this a criticism of testing, but not of stable?
> Debian Testing is not stable and is not mature. It is full of shitty bugs
> (let me define this term as name for ugly bugs that bother the users but do
> not look appear as critical for maintainer, or not important enough to touch
> package in the holy "frozzen" state). Such bugs are a disaster, they make
> our definition of a Stable release absurd. Yes, Debian Stable has become a
> buggy stable release. Just face it.
This is both an unhelpful, subjective assessment of testing, and not
something that would be fixed by dropping testing. If there are
undocumented bugs in testing that you consider release-critical, the answer
is for you to file the reports to document them. If the maintainer
disagrees with you about whether it's release-critical, you can appeal the
question to the release team -- or, better yet, prepare a patch on your own
that's good enough that the maintainer will apply it without any further
need for arguing over severities.
If you're not willing to do the above, or if for whatever reason this
doesn't work, eliminating testing isn't going to help you either. The bugs
would still be there, whether "there" is named "testing" or "unstable".
So no, I won't "just face it". If you're not happy with the quality of the
software going into sarge, there is a public BTS available for you to use in
addressing these problems. Given the declining number of RC bugs open
against sarge, however, I would offer that this is something of a minority
view.
> The major goal (making Freeze periods shorter) was not reached. The second
> goal (faster releases) was not reached.
There's a lack of useful evidence on this question. Among the other factors
involved which make it difficult to determine what the effect of testing has
been on release cycles, we have:
- the number of released architectures
- the number of packages targetted for the release
- the number of developers involved who must coordinate among themselves
to bring about a release
- individual developers' life circumstances and resource committment to
Debian
- individual RC issues that introduce release delays
- a very small sample size
The last point is particularly relevant, given that most of sarge has not
frozen yet at all. While the freeze for base has been much longer than we
might have hoped, for most packages it has had zero impact so far; and we
have every reason to believe that a quick freeze of the rest of the system
will be possible once the current blocking issues are sorted out.
> The third goal (better software quality in the development branch) was not
> reached, at most partially (the users did not have to deal with PAM bugs
> this time, hahaha).
Subjective, not to mention insulting to the efforts of all the developers
who have been doing their part to make sarge a top-quality OS. Or did you
have statistics on the frequency & fix rate of RC bugs in pre-sarge testing
vs. unstable prior to the introduction of testing?
> So how would the removal of Testing help?
> =========================================
> - frozen would have better software - more up-to-date upstream versions with
> less ugly upstream/packaging bugs
Unsubstantiated assertion. The software would be more up-to-date at the
beginning of the freeze, but the freeze would almost certainly last longer
since there would be no way to deal with RC-buggy package versions except
for fixing them or dropping them after the freeze has started; so by the end
of the freeze, the software is likely to be *less* up-to-date.
> - maintainers would actually be forced to fix
Er, as opposed to what?
> A possible future model for the release cycle and freze method will be so
> called Tristate freeze model. It consists of three states:
> - PRE-FREEZE, 2-3 Weeks before the freeze day. A frozen directory is created
> on a dedicated machine and release managers can start testing the freeze
> management scripts. Release team and few selected users should have access
> to this resource. This testing environment is not stable and may (or not) be
> purged before the main freeze begins
> - MAIN FREEZE: takes three weeks, beginning from the freeze day. Unstable
> branch will be moved to "frozen". Packages uploaded to "frozen" or
> "unstable" are mapped to "frozen-candidates" and are to be reviewed by the
> release team.
> - DEEP FREEZE: 1-2 weeks. Only important updates are allowed to be moved from
> "frozen-candidates". Release team has to decide with majority about this actions.
> - After the release, the contents of "stable" are synchronized with "unstable"
> and the new iteration begins.
Over the course of the sarge release cycle, we have had various RC bugs in
the base system practically constantly. These are packages that *cannot* be
dropped for bugginess; they either get fixed, or the bugs get downgraded,
though the latter option is also usually not practical.
At the time of the base freeze announcement, the RC bug count on
base+standard packages was at a relative low, and the remaining RC bugs
appeared to be straightforward to fix. Three months on, we have just now
gotten a glibc+gcc+binutils set that's free of RC bugs, as one RC bugfix led
to another. And while I certainly can't prove it, my own suspicion is that
without the impetus of the freeze, we would be even farther from release
than we are today. So where in the above three-stage freeze process would
you put this sequence of discouragingly-hard-to-fix sequence of RC bugs, and
what would their impact be on the actual freeze timeline (both its starting
point and its duration)?
--
Steve Langasek
postmodern programmer
Attachment:
signature.asc
Description: Digital signature