#1530 hguemar has been abusing his provenpackager status with python-pymongo
Closed None Opened 8 years ago by rbarlow.

= 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.

Metadata