Michael DeHaan wrote: > >>>> 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@xxxxxxxxxxxxxxxxx about the version and/or file > a bugzilla > (B) have a process to handle things if the owner is MIA > You're looking at it from the opposite angle from what this paragraph does. You're playing the potential co-maintainer. I was playing the potential maintainer. As a maintainer who doesn't know anyone in this community I'd be much more likely to give access to a packager group that Fedora says is made up of people who can teach me a thing or two about packaging than a random contributor who shows up and says they'd like to comaintain. Having a "comaintainer campaign" is going to create more of the latter. The normal process of attaining comaintainers (you submit a patch. You submit another patch. Either you ask for comaintainership or I get tired of being your proxy) is separate from such a campaign and would more or less follow the steps you outline. > 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. > Sure. But how often does this happen? We're pretty wary of stepping on each other's toes. Michael Schwendt's fixups are one example of things that went through a long amount of time and multiple emails before getting to cvs. The FTBS process is another one. Having a higher level packaging group should be populated with people who are careful about things, take time to think things through, are thorough about their announcements of changes. Note, that provenpackager does not meet these criteria IMHO. > 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. > I would argue that that's not true. The people that are well known are the people who are vocal on the mailing lists, on irc, and involved with upstreams. Other people are not. If we have a campaign to get comaintainers for every package we're going to quickly exhaust the supply of known participants. >> 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. > We can block a package from the next release if we know that it is effectively orphaned. Packages that are in released distros need to be maintained until the package goes EOL. Perhaps all we need is to specify that orphaned packages will have their provenpackager ACL opened automatically and then the MIA policy will be sufficient. >> 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? Note that MIA does not address the question of getting a comaintainer on every package which this email was a reply to. I'm arguing that a comaintainer campaign is insufficient as there will always be some packages which are not interesting to more than one packager. That said, MIA policy is a lot of work and effort. Because of that, it is mostly applied by people who want to take over maintainance of a package. People who are taking care of a bug that's widespread throughout the distribution are concentrating on getting the most packages fixed rather than getting a specific package fixed. So packages that should be orphaned and dropped from the distro aren't getting dealt with. Having a streamlined policy for orphaning packages once a release under terms similar to the MIA policy could help. ie: once a release, take candidate bugs/packages for MIA status. Send email to the owners of those packages, file new bugzillas if necessary. For those packages that don't get responses, orphan them and give people an opportunity to take them over before the orphan culling that happens near release time. -Toshio
Attachment:
signature.asc
Description: OpenPGP digital signature
-- fedora-devel-list mailing list fedora-devel-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/fedora-devel-list
