On Sun, 12 May 2013 17:43:57 +0800 Paul Wise <pabs@debian.org> wrote: > On Sun, May 12, 2013 at 5:22 PM, Neil Williams wrote: > > > 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". > > Sounds good to me. > > > 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 don't think that is the right conclusion. A better one might be that > the intersection between people who have time, care about the software > and have the skills to maintain the software is low. There remain packages where that is not just low but absent. Those packages are candidates for removal, subject to the dependency checks below which we appear to agree upon. Where removals are concerned, there is always the check of N levels deep and X packages involved. `rm *` doesn't actually make for a good release. > I don't think that is the right conclusion either. A better one might > be to spend time recruiting more developers or pinging existing > developers who have expressed interest in the past and folks involved > in upstream projects. I've learned over the years that removals > usually happen without the latter two and that Debian isn't > particularly good at the former. > > > 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. > > That would be good, I think Neils has been working on this. > > > 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. > > The release team already does "policing"; they complain when people > start uncoordinated transitions or upload unsuitable changes during > release freezes. Exactly, the release team is at full capacity doing that, therefore we cannot expect the release team to do more of it. They rightly complain about uncoordinated transitions because that makes their work harder and slower. Although the transition mechanism could help with mini-freezes, policing those freezes needs to be done by someone else or the mini-freeze will be chaotic. The release team have enough to do already, but learn from their methods if we are to create another area where a "police" role is required. This is the weakpoint of a mini-freeze idea, I don't think a mini-freeze will be observed and we don't have a team with sufficient time to take the "policing" role. Saying "no" in a volunteer project is never an easy thing to do, even when it is absolutely the right thing to do for the benefit of the project as a whole. -- Neil Williams ============= http://www.linux.codehelp.co.uk/
Attachment:
pgpUkoWGx1uYx.pgp
Description: PGP signature