Re: Debian development and release: always releasable (essay)
On Sun, May 12, 2013 at 4:42 PM, Russ Allbery wrote:
> Michael Gilbert writes:
>
>> Or the project could end up in a perpetual freeze. Every time the
>> floodgates are opened, another 1,000 bugs could get reported due to all
>> of the new transitions, and another freeze will need to happen to get
>> those down.
>
> I would like to see us try it and see if that happens. If that does
> happen, I think that's a fascinating data point, and one that would be
> well worth the few months of difficult process in order to confirm.
> Knowing for certain whether or not that would be the outcome would be
> wonderfully clarifying and helpful in narrowing the possible solution
> space.
I personally vote no more freeze, but I have no intent to stand in the
way if that is really the consensus of the rest of the project.
>>> Think of this in software development terms. We're currently following
>>> a development model where, immediately following a release, there's a
>>> nearly complete free-for-all without much enforcement of bugs or
>>> regressions. We do that for a year, and then we try to stabilize the
>>> results. Most free software projects that used to follow this model
>>> (and there have been quite a number of them) have had similar struggles
>>> with the extended stabilization process this requires. That's part of
>>> the shift towards test-driven development, continuous integration, and
>>> constantly-usable master branches.
>
>> Those other distributions have also given up on producing high-quality
>> releases. Only Debian and RHEL remain in that category.
>
> I don't believe that's true; in fact, it's the exact opposite of the
> outcomes I've observed in practice. Most projects that use test-driven
> development, continuous integration, and constantly-usable master branches
> maintain a significantly higher level of quality than the projects that
> use development methodologies like Debian's (at the cost of forcing
> disruptive changes to be done more slowly and with more planning, or to be
> postponed if people aren't available to do them properly).
I wasn't responding to the continuous testing sentence. I'm in
complete agreement on the importance of continuous testing.
I was responding to the comments on the development model. Other
distributions have moved to time-based and given up on quality.
Debian has maintained quality by not compromising on time.
>>> The bug affects the version of the package in testing. I see what
>>> you're saying, but I don't think this is something the BTS can
>>> represent. And those bugs *are* all release-critical: they have to be
>>> fixed before we can release jessie, at least unless we're going to
>>> abort the transition, which seems unlikely.
>
>> There is the "sid" tag, which indicates that the issue only affects
>> unstable. Although I think a "triggered-by" function is needed in the
>> bts. For example, bugs with "triggered-by gcc 4.8-0" would not be
>> marked as affected in suites that have gcc versions prior to 4.8-0
>> (i.e. jessie would not yet be affected by the gcc transition).
>
> If there are no RC bugs affecting the version of a package in testing,
> that should mean that nothing has to be done to that package in order to
> release. If the package has to be fixed due to a transition that will be
> in the next release, that is an RC bug affecting the version in testing
> and should be counted accordingly. The package cannot be left unchanged
> and still go into the release, which is the definition of RC.
>
> In other words, I see no point in doing what you describe. So far as I
> can tell, all it does is artificially lower the RC bug count in the graph,
> while in no way reducing the amount of work that has to happen before
> jessie is releasable. In other words, it just hides a bunch of RC bugs
> from the statistics without actually changing their RC status. That seems
> like an even worse state: we have just as much work to do but now we're
> hiding that work from ourselves.
Unless that information is then used to figure out when its really ok
to let the gcc (or whatever) transition happen, or even to decide to
put an end to a particular buggy transition before it starts affecting
testing.
Right now, there are just large numbers every where, in testing, in
unstable. That lack of information is counter-productive and
misleading, and the large number is discouraging to anyone potentially
interesting in knocking a couple bugs off.
Best wishes,
Mike
Reply to: