closing out old bugs of unmaintained releases

[David Woodhouse]

On Wed, 2008-01-09 at 09:51 +0100, Thorsten Leemhuis wrote:
> On 09.01.2008 09:32, Christian Iseli wrote:
> >> We have a lot of non-hackers that maintain packages in Fedora and it
> >> worked well so far and that in parts made Fedora what it is today.
> >> What IMHO would be good instead of what you outline: groups of people
> >> (SIGs) a package-monkey can contact if he needs help to fix or improve
> >> something needs programming skills.
> > What I'd like to see is:
> > - emergence of a group of able programmers willing to help squashing
> > bugs in other maintainers' packages, and an easy way to alert this
> > group of people to a list of bugs to squash
> > - education of the non-programmers packagers that they can and *should*
> > seek help from the above group when needed, and how to go about this
> > process
> 
> That's what I meant in better words ;)

So do we have a nebulous group of 'programmers with free time' and call
upon them as an when they're needed, or do we have a programmer sign up
to 'own' a package in conjunction with the 'packager'?

I favour the latter, for much the same reason as we have specific
package owners in the first place rather than a free-for-all¹:

 - it sets the _expectation_ that this is the person who will step up
   when action is necessary (although we aren't going to turn up on
   your doorstep and promote an attitude of violence if you don't).

 - it gives some primitive level of workload control. If the programmer
   is and unable to keep up with the packages he/she has signed up to
   work on, he/she can stop taking on new packages and/or try to find
   others to take over some of them.

 - it would give the non-programmer packager a first point of contact
   when he/she needs help, rather than a general appeal to a mailing
   list where nobody feels 'ownership' of the problem at hand.

 - it gives the programmer 'community' the opportunity to throw their
   hands up in horror and say "No! This code is a steaming pile of crap
   and should not ever be shipped with the Fedora name on it", rather
   than being stuck with supporting it after the fact.

I think that as part of the review process, a non-programmer packager
should identify a programmer who has agreed to help look after the
package. This might often be the packager's sponsor, or it could be the
owner of the upstream code (some are more helpful than others), or it
could be someone else who believes themselves capable of working on the
code to the extent that it's likely to be necessary.

But they should be identified in advance, rather than letting packagers
just add arbitrary packages to the pool and expecting a 'programmer SIG'
to cope with whatever's thrown at them. Or letting packagers add
packages to the pool and then refuse to support them, which is sometimes
happening at the moment.

-- 
dwmw2

¹ Although I do feel that the old Red Hat internal process benefited a
  lot by being a bit _more_ of a free-for-all than we have in Fedora.
  Fedora seems to have largely lost the teamwork mentality. But that's
  a separate issue.