= phenomenon = The FAS user hguemar has been abusing his provenpackager status, and is trying to override me (the package owner) by pushing out a majorly backwards-incompatible change to EPEL 6, EPEL 7, F22, and F23. I cannot stop him as I will be gone for the weekend. It is very important that he not be allowed to override me again, but there is little I can do about it. Here are links that show what he's been doing:
https://bodhi.fedoraproject.org/updates/FEDORA-2015-3e4043f088 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-925e9374c9 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2015-68a2c2db36 https://bodhi.fedoraproject.org/updates/FEDORA-2015-dd52a54fa1
= reason = The Fedora update policy clearly states that updates should be bug fixes and security fixes only, and not contain major changes. The Pymongo update contains significant backwards incompatible changes:
http://api.mongodb.org/python/current/changelog.html#changes-in-version-3-0
It is inappropriate to assume that only packages in Fedora should be considered when making a backwards incompatible change, this is what Rawhide is for.
= recommendation = I recommend removing hguemar's provenpackager status.
There appears to be some misunderstanding between two groups within Red Hat here. Let's see if we can work this out internally.
I'm strongly opposed to doing any sort of package ACL actions on this ticket or it's counter-part at this time.
We ended up having an IRC discussion about this in #fedora-devel:
{{{ number80 [07:24:46] can someone tell pulp maintainers not to fuck up w/ fedora updates? number80 [07:25:59] if they revoke again another update without providing a good reason, I'm gonna get even more pissed off as I am right now rdieter [07:36:54] plfiorini: ok, I'd be interested in swapping reviews, which one(s) would you like me to do? pcreech [08:01:53] number80: i don't want to get into an argument here. PyMongo 3 breaks backwards compatibility with 2.x. That's our biggest concern. It may not break any packages in fedora, but it will break software that runs on fedora and relies on python-pymongo number80 [08:02:23] pcreech: too late, you had 3 months pcreech [08:02:44] number80: I'm also not a fan of your comments here https://bodhi.fedoraproject.org/updates/FEDORA-2015-dd52a54fa1 number80 [08:02:45] (sorry for the away message, not using my usual irc client) number80 [08:03:23] pcreech: discover through an irc bot that someone revokes an update without contacting you for no legit reason number80 [08:03:29] you're breaking things for me number80 [08:03:49] then you start to get why I'm pissed off number80 [08:04:03] it will get into F23 and El7 period number80 [08:04:22] the best i can do is help you to review python-pymongo2-compat number80 [08:05:03] note, it still break things for me in F22 but they're not in Fedora number80 [08:06:08] pcreech: ok, rbarlow is revoking ACLs, this is going to fesco number80 [08:06:30] I have been maintaining pymongo for longer, this is hijacking volter [08:11:34] If a sub-package doesn't directly utilize something from the base-package, is it allowable to slacken the version constraints a bit, like %{name}%{?_isa} = x.y instead of %{name}%{?_isa} = x.y.z-%{release}? *** Playback Complete. bowlofeggs is anyone from FESCo available? i've got a problem with a provenpackager and it is time senstive zodbot Ticket notification - fescorss: Ticket #1531 (Revoke rbarlow ACLs to python-pymongo) created https://fedorahosted.org/fesco/ticket/1531 || Ticket #1530 (hguemar has been abusing his provenpackager status with python-pymongo) created https://fedorahosted.org/fesco/ticket/1530 bowlofeggs number80: you are breaking fedora policy bowlofeggs it is very clearly stated that you cannot push backwards incompatible changes number80 bowlofeggs: it was pushed 3 onths ago bowlofeggs there is no exception for it being ok when you check with dnf number80 bowlofeggs: I am part of fesco bowlofeggs number80: that is irrelevant bowlofeggs you are breaking fedora policy number80 you asked for fesco member, here he is number80 moreover, this update was concerted w/ previous maintainer number80 point is; you can't revoke updates unilaterallu bowlofeggs you have not responded with a justification for breaking fedora policy number80 bowlofeggs: I did not break the policy bowlofeggs thus update will break foreman and katello as well bowlofeggs the policy was clearly cited bowlofeggs in bodhi number80 irrelevant, you're speaking about packages not in fedora bowlofeggs the policy makes no exceptions bowlofeggs it just says not to make backwards incompatible changes bowlofeggs there are users of these packages bowlofeggs they do not want to be broken mid-release number80 bowlofeggs: we have packages relying on Gtk+1, so we would have never had Gtk+2 & 3 with your reasonning bowlofeggs this is what rawhide is for number80 bowlofeggs: it was pushed before F23 release bowlofeggs you can do this in rawhide bowlofeggs f24 will have the new version bowlofeggs but not in the middle of a fedora release bowlofeggs that is the policy. bowlofeggs what you are doing is not the policy. number80 bowlofeggs: this is an abusive interpretation jcline number80: https://fedoraproject.org/wiki/Updates_Policy#Stable_Releases number80 it fixes packages that are in fedora number80 jcline: yes, so should I break packages that are in fedora, for packages that are not in Fedora? bowlofeggs you are "materially affecting the user or developer experience" bowlofeggs number80: it doesn't matter if they are in fedora or not number80 bowlofeggs: I can tell the same jcline number80: You cannot release a backwards-incompatible change mid-release. bowlofeggs the policy does not make that exception number80 jcline: that was not mid-release bowlofeggs f23 and f22 and epel 6 and epel 7 are all mid-release number80 I was ok to unpush F22 for that reason bowlofeggs f22 has the same policy that f23 has number80 bowlofeggs: due to EPEL long live shell, it's another thing number80 bowlofeggs: This update was in testing before F23 release number80 so not mid-release number80 moreover, revoking my ACL is abuse jcline Which makes backwards-incompatible changes worse number80 jcline: yes, this is worse, you break packages relying on this update bowlofeggs number80: f23 has shipped without it bowlofeggs that means it is mid-release bowlofeggs number80: you overrode the package owner and violated the update policy bowlofeggs that is why i removed your ACLs number80 bowlofeggs: lol, previous PoC gave me permission for that update, so you did number80 you just got reassigned as PoC bowlofeggs as the owner that is my responsibility, to ensure that the group who edits the package is responsible and follows the policy number80 bowlofeggs: as provenpackager, my responsibility is to ensure that Fedora distribution is consistent bowlofeggs i wouldn't have done that if you hadn't repushed bowlofeggs your responsibility is to follow the policy number80 bowlofeggs: I wouldn't have undo the revoke if you had proper reason number80 bowlofeggs: I did, you didn't bowlofeggs the policy clearly states not to make backwards incompatible changes in bodhi bowlofeggs you made a backwards incompatible change in bodhi number80 bowlofeggs: you broke fedora packages relying on that number80 this is worse number80 revoking without warning is not acceptable bowlofeggs i have not broken any packages bowlofeggs and there was no time for warning jcline number80: those packages broke themselves on old platforms by requiring new features. They should also be developing in rawhide. number80 openstack-zaear bowlofeggs i discovered the problem 2 hours after it happened number80 openstack-ceilometer are broken number80 jcline: F23 is not old pcreech is pymongo 2.9.x not an option? (just curious) It is a bridge release between 2.x and 3.x... jcline number80: it's been released. number80 pcreech: nope bowlofeggs pcreech: unfortunatlely, pymongo 2.7 was also a backwards incompatible release ☹ bowlofeggs (they didn't follow semantic versioning) number80 bowlofeggs: if you contacted me, we could have sorted out a compat package but you never did bowlofeggs number80: i didn't have time - i saw the problem after the push request was already made bowlofeggs i would have, honestly pcreech just trying to think of solutions... bowlofeggs but i needed it unpushed bowlofeggs and time was ticking number80 bowlofeggs: so creating problem to existing packages in fedora is not a solution number80 bowlofeggs: and time is ticking for me too number80 but I never did what you did number80 I always try to contact people bowlofeggs number80: you can't break fedora policy in one package to make up for the problems in other packages number80 bowlofeggs: I did not break policy period bowlofeggs you did bowlofeggs it's very clear pcreech so... the milk is spilled. How do we come to a compromise... make pulp happy and openstack happy... bowlofeggs code written for pymongo 2.6 will not work with 3.0 bowlofeggs the change list is extensive number80 and vice-versa bowlofeggs number80: but F23 shipped with 2.6 bowlofeggs and so it cannot be changed number80 and 3.0 in testing bowlofeggs by policy. bowlofeggs stable fedora users don't use testing, they use stable bowlofeggs and they've been using 2.6 bowlofeggs foreman and katello will also be broken by this number80 bowlofeggs: compromise => leave 3.0 in testing for F23 and EL7 and set a threshold to ensure no push to stable number80 works for you? bowlofeggs number80: how about a counter proposal: i will help you make a compat package, perhaps python-pymongo3? bowlofeggs that way it's clear what it is pingou bowlofeggs: note that there are no longer owners of packages bowlofeggs pingou: ah i didn't realize - so only admins? number80 bowlofeggs: if you let in testing 3.0 meanwhile, ok pingou bowlofeggs: only maintainers and 1 who is the point of contact bowlofeggs pingou: ah interesting - thanks for clarifying that for me! pingou bowlofeggs: sure thing bowlofeggs number80: i am not comfortable with that bowlofeggs number80: but we can do a quick package review for you bowlofeggs jcline: can i volunteer you for that? number80 bowlofeggs: I can't let packages in fedora broken without solution ntil it's done number80 but i'll keep my word if we agree not to push to stable jcline bowlofeggs: I can do a review for a python-pymongo3 jcline what do you think about accepting his offer? bowlofeggs number80: ok, i will accept, but let jcline make the submission to bodhi number80 wfm bowlofeggs i need to go bowlofeggs thank you for workign with us on this compromise pingou good team work folks pingou bowlofeggs++ zodbot pingou: Karma for rbarlow changed to 1 (for the f23 release cycle): https://badges.fedoraproject.org/tags/cookie/any pingou number80++ zodbot pingou: Karma for hguemar changed to 6 (for the f23 release cycle): https://badges.fedoraproject.org/tags/cookie/any pingou jcline++ zodbot pingou: Karma for jcline changed to 1 (for the f23 release cycle): https://badges.fedoraproject.org/tags/cookie/any bowlofeggs thanks pingou bowlofeggs number80: and we will get your a fast package review for a python-pymongo3 bowlofeggs number80: also, fwiw, i also plan to very actively maintain pymongo in rawhide now bowlofeggs so it will get bumped to 3.2 next week some time bowlofeggs i don't want to let that package linger anymore (that was why i asked the previous POC for access) number80 bowlofeggs: wfm, since we never worked together, as provenpackager, I always send an heads-up for minor change or contact maintainer bowlofeggs number80: cool, and i will do the same with you in the future }}}
I am happy that we reached a compromise, but I am disappointed that it came down to such an intense discussion, and I do still believe that a provenpackager should not try to violate Fedora update policy.
I will leave this matter in FESCo's hands, as I am not sure what the best thing is. Again, I am thankful that he was willing to reach a compromise with us.
Ok, I was not abusing my provenpackager rights, and I did contact the previous maintainer and we agreed to do that. And I never received answer to my private mails.
I closed my ticket but I'm still disappointed that I was never reached out nor get answer to private emails.
If pymongo does not provide a stable branch, I'm not sure how Fedora users benefit from staying on an old unsupported release?
Also what concretely does break in Pulp? I see pulp is in f24 and f24 had pymongo 3.0 since Oct 2015.
As I'm involved in this, I kindly ask someone else to close that ticket as invalid.
I have been a packager for a decade, I mentored many packagers as a volunteer for years, you can't even begin to imagine how much hurt I am by such accusation.
As it's proven impossible to deal with such constraints in a sustainable way, I will retire any broken packages from currently supported releases though no other Fedora packages was broken by that update. I won't be commenting further unless asked for it.
Login to comment on this ticket.