On Sat, 11 May 2013 10:31:09 +0800 Paul Wise <p...@debian.org> wrote:
> 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. The problem we should be trying to solve is "people are not getting the work done, let's break down the problems and make working on them easier or the solutions more obvious". i.e. 0: Improve detection (more frequent and more varied QA) 1: Improve triage (more data, more criteria / tags / meta data) 2: Improve fixability (more conformance across packages so that understanding / fixing the package is trivial, ensure packages always build twice cleanly, mandate consistent patch handling) 3: Improve automation (remove stalled packages, alert maintainers of reverse dependencies about problems other than wnpp issues.) > The diversity of software in Debian is an advantage, I would prefer > that we strongly care about all packages for the release. Modulo dropping packages from Debian when it is obvious that actually nobody cares sufficiently about those specific packages. Make the archive consist of packages at least someone cares about, then we have an archive which we, collectively, care about releasing. > 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. So drop more packages, get down to a realistic set. > 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. Automated removals of leaf packages (or packages where the only reverse dependencies are themselves leaf / under maintained) still helps the release as a whole. It's easy to implement a check that removals are considered only when the entire dependency chain to be removed is less than N levels deep or involves less than X source packages. > > 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. (Doesn't discount removals where dependencies are less problematic.) Existing transition support could be extended to implement a mini-freeze on a particular chain of packages. The problem, as ever, will be imposing such a mini-freeze and ensuring that it is maintained and respected. Making that "policing" role part of the release team workload is not going to help anyone. > > 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. Helping people sift the number of RC bugs to more easily locate the ones which can be fixed and which ones to ignore will also help bring the RC count, as a whole, under control. New meta data about those bugs will help people get the list itself 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. Ack. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
pgpgf7vOPeyZb.pgp
Description: PGP signature
