Re: Debian development and release: always releasable (essay)
Michael Gilbert <mgilbert@debian.org> writes:
> On Sun, May 12, 2013 at 2:17 PM, Russ Allbery wrote:
>> Right. Which is why we should immediately (for definitions of
>> immediately that involve the release team taking a much-deserved break,
>> but not for definitions of immediately that mean "six months from now")
>> freeze testing again until we're back down under 50-100 RC bugs,
>> whether via fixes and transitions or whether by kicking out a bunch of
>> packages.
> People just spent 10 months fixing issues in packages that were not
> their own. I don't think they want to be pulled away from the fun
> stuff so quickly.
And that's why releases are so painful, at least IMO.
We have to break this cycle at some point or it will just get worse. To
break the cycle, we're going to have to keep doing bug fixing after we're
exhausted of doing bug fixing so that we don't build up a huge backlog.
The good part is that if we actually can break that cycle, the freeze
will be much less painful and we won't be as sick of fixing bugs the next
time around.
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.
>> Because they're not from migrations. They're from transitions.
>> They're all the "this is going to break with a new version of libc6"
>> and the like bugs that were filed before the release at priority
>> important and were mass-upgraded after the release.
> But those shouldn't affect testing yet, right? All of that stuff
> needs staging in unstable first. Are bug filers not tagging their
> reports correctly? If so, that's quite misleading, and actually
> should be quite easy although tedious to fix.
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.
--
Russ Allbery (rra@debian.org) <http://www.eyrie.org/~eagle/>
Reply to: