= phenomenon = The libvirt related packages in Fedora are maintained by a team of people, who are also the upstream maintainers of the packages. The size & global distribution of the libvirt maintainers team is such that there is nearly always someone online 24 hours who can respond to Fedora issues in a reasonable timeframe. The maintainers can be easily reached via multiple avenues, BZ tickets/comments against Fedora, upstream mailing lists, #virt IRC channel, libvirt-maint@fedoraproject.org mailing alias, or mailing alias for individual Fedora packages. In order to maintain quality control, the policy for making changes to libvirt related packages in Fedora, is quite strict
On numerous occasions Fedora 'provenpackager' maintainers have made changes to libvirt packages which violate one or more of our process steps outlined above. In addition some changes have been just plain wrong/broken. The Fedora guidelines for provenpackages indicate that they should attempt to contact the official maintainers before making changes, but this has never been done. They make changes to packages without any prior attempt at communication whatsoever, nor giving sufficient time for response to BZ tickets.
Given this neglect of proper processes, I request that provenpackager commit privileges be revoked from
libvirt libvirt-sandbox libvirt-glib perl-Sys-Virt perl-Sys-Virt-TCK
Would you please cite some specific examples of the misuse of provenpackager (specifically the cases where pp updates have broken things?)
I didn't really want to pick on specific people, since I've already resolved the most recent issue offline, but this is the recent example which triggered this mail
https://bugzilla.redhat.com/show_bug.cgi?id=802475
There are numerous other cases in GIT history where secondary arch maintainers have changed the RPM specs without any prior attempt at communication with the package maintainers.
Let me say again I'm sorry I bypassed your process. I understand where you are coming from, and in a perfect world I think it would be fine for the libvirt team to be the only ones to every touch their Fedora packages. Sadly, we don't live in a perfect world, so adjustments need to be made.
The change above I made in an attempt to prevent a 1 week slip in our Beta. It's possible there were libvirt folks awake and ready to look at it, but we were not sure where to find them and didn't expect that. Initial testing showed this 1 line patch might fix the issue we were hitting, so I did a build. After that we tested more and determined that it wasn't a good fix. I'm hard pressed to see where this one line change would "break" the package, but it should be easy to revert and unpush (which was done).
Secondary arch folks make changes to try and build things on their arch. They are outside the provenpackager area. When they have done this to packages I maintain they have opened bugs and been happy to discuss fixes. Is this not the case for you? If we move to a setup where secondary arch folks have no commit and must wait for a maintainer to act on a bug, I fear it will in some cases slow them down to a stop.
I think dealing with occasional small patches for good enough reasons until they can be upstreamed doesn't seem like a undue burden.
This request was denied on FESCo's 2012-04-2 meeting (http://meetbot.fedoraproject.org/fedora-meeting/2012-04-02/fesco.2012-04-02-17.00.txt).
Marcela has volunteered to draft provenpackager policy changes.
The current policy is https://fedoraproject.org/wiki/Provenpackager_policy Imho it's obvious that provenpackagers who are not familiar with a package shouldn't commit without communication with a maintainer. But we could add to the paragraph:
Provenpackagers should try to communicate with owners of a package in bugzilla, irc or email especially if they are not familiar with the package.
I think that addition should be
"Provenpackagers should try to communicate with owners of a package in bugzilla, irc or email prior to making changes."
Your statement was added to the wiki page.
Login to comment on this ticket.