Concerns about 'provenpackager' and why I didn't mass ACL open

[Michael DeHaan]

>>> Rather than
>>> having a large group of people with commit to (nearly) everything for
>>> fixing minor issues, the focus should be on significantly increasing our
>>> levels of co-maintainership. The ideal should be for every package in
>>> the distro to have at least 1 extra co-maintainer, or preferrably 3 or 4.
>>> People with a little domain knowledge for the package who can handle
>>> both the low-hanging fruit the main maintainer misses, with less risk
>>> of making mistakes due to lack of package specific knowledge. Sure it'd
>>> take more people resources than 'provenpackager' solution, and likely
>>> require a big community publicity campaign to kick it off, but long
>>> term it'd be more helpful & safer - particularly for 'infrastruture'
>>> packages (python, perl, etc runtimes & important addon modules) and
>>> security sensitive packages (openssl, gnutls, func, koan, etc).
>>>       
>
> This makes a lot of theoretical sense but has had mixed results in
> practice.  I can recall at least two drives to get comaintainers for
> packages in the past.  This has had some more people sign up for
> comaintainership for some packages but it hasn't gotten us near to 100%
> coverage.  Some of the things it doesn't address:
>
> Trust: If I'm a new contributor who just needed to get X.Y.Z in because
> I just started using it on my shiny Fedora Desktop, I may not have any
> contact with any other Fedora Contributor.  If I don't trust the
> provenpackager group with this software, I'm not likely to trust an
> unknown packager who asks to be a comaintainer either.  In fact, if
> there was an over-all group of people who seldom make a mistake and know
> packaging and software backward and forward, I'm more likely to entrust
> that group with the ability to modify my package than the random packager.
>   

I would hope the process here is to:

(A) email package-owner at fedoraproject.org about the version and/or file 
a bugzilla
(B) have a process to handle things if the owner is MIA

Let's take the "I need X.Y.Z" case.   If someone can't make a change in 
a week --- that in itself may not be a problem -- provenpackager may be 
trying to be helpful, but may not have the domain knowledge about the 
app -- say version X.Y.Z is not ready for prime time.  I would say "I 
need version X.Y.Z" now is not a strong enough reason to require an 
override by a provenpackager if a maintainer is not immediately 
reachable (say, on vacation).  If the package maintainer is orphaned by 
our definitions, it needs a maintainer.   I certaintly would not want 
someone updating the package and being suprised by that -- and then 
having to revert those changes because they were wrong for the package.

And yes, I'm not likely to trust someone I don't know to co-maintain a 
package, but likely are people that we /do/ know in many cases. 

provenpackagers seems to imply a whole new need for a level of oversight 
-- especially if any provenpackager can make more.

> Non-Responsiveness: If the package in question is getting bug reports
> from people about the low-hanging packaging bugs but the bug reports are
>  not being answered even if there are two or more maintainers, there
> still needs to be a way for the changes to be applied to the packages.
> We also need to have a means of adding comaintainers when the maintainer
> does not answer the requests to add a comaintainer.
>
> A non-responsive, forced comaintenance policy would help deal with the
> second part of this problem.
>
> Interest in fixing an error that is easily checked for:  Contributors
> like Michael Schwendt have written and run checks for specific packaging
> errors and then opened bugs for them against many packages.  When the
> bug is not replied to, they have written patches.  When those aren't
> acknoledged they have applied them where the acls are open.  When the
> acls are closed the process breaks.
>
>   


This /seems/ to be why we have the "MIA maintainer" policy.  If the 
maintainer is unresponsive we have a larger issue and a temporary fix to 
the package will still leave the package out of date, and it starts to 
be maintained ad-hoc and is likely to grow more out of date.

> A non-responsive: forced acl opening policy would work for this.
>
> Interest in a package:  If the packager is the only one interested in
> doing work on a package, then there won't be a comaintainer.  That
> doesn't mean that the package won't have common problems so that someone
> looking for common problems won't need to get changes applied to it later.
>   

I think it's covered by the above too, isn't it?

>   
>> Minor issues that don't require an immediate fix /should/ be addressed
>> with the project (i.e. permissions look wrong in spec file, etc) rather
>> than being changed in CVS by someone and issuing their own builds. That
>> seems to be the responsible thing to do.
>>
>> I assume Fedora release engineering folks already have
>> something-other-than-provenpackager access for emergency use anyway?
>>
>>     
> At the moment, the cvsadmin group has the ability to make commits
> despite what acls are in place.  I don't think we're often called on to
> make changes to a package due to non-responsive maintainers, though.
> Instead, we have opened the acls and orphaned packages for
> non-responsiveness and people who are more interested in the package
> have then taken over and done the work.
>   

Yeah, the orphan policy seems to solve most of the problems that I can see.

> -Toshio
>
>