Re: Debian development and release: always releasable (essay)
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 may be
users who use the software every day, have some spare time but do not
have the skills to develop or package software. There may be
developers who have a low amount of time they can commit to the
package.
> So drop more packages, get down to a realistic set.
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.
> 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.
That would be nice.
--
bye,
pabs
http://wiki.debian.org/PaulWise
Reply to: