Re: Debian development and release: always releasable (essay)
On Fri, May 10, 2013 at 11:24 PM, Russ Allbery wrote:
> The point isn't what individual developers do, particularly developers who
> are extremely well-engaged with the project. The point is to find ways to
> do this at another level up. Obviously, given the number of RC bugs that
> we had to fix *after* the freeze, this isn't already being done at the
> level required for a timely release process. I don't think we can solve
> that problem by saying "well, developers really *should*."
The problem this thread is trying to solve essentially comes down to
"people don't do enough work and we want them to do more". There are
various factors at play here; time, motivation, demotivation,
knowledge, confidence and probably more.
> Care to expand the thought?
The diversity of software in Debian is an advantage, I would prefer
that we strongly care about all packages for the release. I expect
that very few people in Debian and none/few of the QA or release team
members in recent years who share my opinion here though, I accept
that and avoid expressing this opinion in general. I also acknowledge
that we just don't have enough people to properly maintain all the
packages in Debian which means that my opinion is also unrealistic.
> But by and large they only do this on a large scale during the freeze, at
> which point, in a way, it's too late. We've already built a huge backlog
> of work, and everyone is anxious to release. I think we should be doing
> this continuously during the release and much more aggressively than we've
> been willing to do in the past.
Agreed, I've been poking various RT folks about this over the years,
mainly I suggested completely automated removals for all packages.
That was a bit extreme though since core packages like
apt/toolchain/etc can have RC bugs open for a long time.
> I suspect, though, that mini-freezes whenever the RC bug count rises above
> a certain level will be as effective or more so, since I know that package
> removal very quickly involves deeply tangled dependencies, and one has to
> sometimes remove vast swathes of packages to remove a particular RC-buggy
> package.
I think this is a much better idea than removals.
> That's certainly a good start, although I think it's worth asking the
> blends maintainers whether all of the packages they include are
> release-critical. I don't think it captures all of the interesting use
> cases, though; there are common patterns that we want Debian to support
> that aren't captured in a task or a blend.
Agreed. Do you have any example use-cases that should block releases
but aren't in blends or tasks? Perhaps we need to start some new
blends or add new tasks.
> I would limit it to just no RC bugs (and therefore no test failures where
> we're pretty sure that test failure would indicate an RC bug). If we feel
> that piuparts is testing things that should be RC, that would certainly
> include piuparts.
piuparts folks generally already file RC bugs as they are able.
> Bear in mind, however, that the core problem is that we don't keep testing
> sufficiently free of RC bugs to be able to release in a timely fashion
> after a freeze. That means we're not dealing well with the bugs we
> already have, so I would be a bit hestitant to create new classes of RC
> bugs until we have that situation under control. While looking for new
> classes of bugs is something that we should always be open to, I think the
> most important step is to try to catch the bugs we were already catching
> earlier in the process and to be more aggressive about dealing with them.
Ack.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: