Dear Red Hat
Dear Red Hat,
please do not abuse the privileges your employees have on Fedora Project's systems to enable two of your employees to make CVS commits to packages I own without any prior communication whatsoever.
Please consider the possibility that some of us voluntarily put significant amounts of work towards your upstream, and may experience the aforementioned as offensive and degrading.
It would have been just as effective to contact me prior to forcibly giving two of your employees co-maintainance, because frankly I'd feel honoured that Red Hat has a stake in one or the other package I own or co-maintain. It's the fact nobody asked me anything -or even told me- that offends me.
Despite the fact that the employees in question are relatively new to Fedora (their accounts have been registered within the past two months), I don't know where they come from nor what their respective history in Free Software is. For all I know, they may be very experienced and skilled packagers, and they may perfectly well know what stake I hold in my packages -and I primarily have a stake in the packages I own, or I wouldn't be the owner- but I have trouble trusting new users to commit to about 1200 packages all of a sudden.
Kind regards,
Yours sincerely,
Jeroen van Meeuwen
- Login or register to post comments
- 7441 reads
- jmeeuwen's blog
Comments
Erm.
There's no special privileges granted to people purely because they're Red Hat employees. If someone is modifying packages without having gone through the provenpackager process then that's an issue that should be brought up with fesco or the board.
Lovely
You are right in that "no special privileges" are being granted; there's nothing special about co-maintainership. You are also right in saying it isn't "purely because they're Red Hat employees". That wasn't the point I was making either.
I love how the people that work for Red Hat are also the people that keep denying there is any kind of special treatment for Red Hat employees within the Fedora Project.
Whether rightfully so or not, my claim is that normal people get the privileges only after they've done the work, followed normal procedures, obtained the kudos and have made their acquaintance with the appropriate people within the Fedora Project, while it seems way easier to obtain such privileges merely by having obtained an @redhat.com email address. I don't think you can deny that claim.
Now, I'm not arguing that it is wrong for Red Hat to chime in and claim some form of responsibility in the projects that have their interest. In fact, I cannot but applaud such involvement. In this particular case, Red Hat may have said "We care about Perl", followed by assigning significant resources to making sure Perl is taken care of. It will, undoubtedly, be loved and cherished in all ways one can imagine.
However, that does not include that Fedora Project is Red Hat's playground and it can do whatever it sees fit, however it sees fit, even though Red Hat maintains majority control over the Fedora Engineering Steering committee as well as the Fedora Project Board. Admittedly, in the interest of full disclosure, I have not run for a position in either governance body, and have not even voted last time around -I was otherwise occupied and I regret.
Confusion and mistakes in the script(?) that actually assigned the privileges in the package database notwithstanding, which merely caused me to take notice, the Fedora Project has proper procedures, and governance bodies put in place to make sure those procedures are followed, or to authorize exceptions to those procedures. None of that was properly taken into account.
Along the way, only one person that has commented is Iain Arnell. It's also the only person outside of Red Hat involved with giving two new users access to over 1200 packages, without authorization from any other body within the project, without asking any of the existing owners for either one of the 1200 packages (Iain Arnell owns about 130 of those, not necessarily all of them overlapping).
Ergo, @redhat.com being the common denominator for the vast majority of people involved, my say or anyone else's for that matter not having been collected, normal procedures being trumped and overruled -all by @redhat.com employees, causes me to raise this stink and point the finger in the direction of Red Hat.
But, now try and realize what I was raising a stink about; I wasn't asked anything, nor was I informed. My privileges have been trumped all over. Apparently I have no say in what happens to my packages. I'm pointing the finger to those in absolute control and those involved. Is that so hard to understand?
It's clear that there was an
It's clear that there was an attempt to contact the maintainers of the relevant packages - perl-devel@ wouldn't have been Cc:ed otherwise (http://lists.fedoraproject.org/pipermail/perl-devel/2010-June/023435.html ). It's also not the case that procedures were ignored. The sponsorship procedures indicate that sponsors should have filed a review request, but it's not a requirement to do so. Someone who was willing to accept the responsibilities associated with sponsorship sponsored two individuals, and after a week for anyone to object (and not doing so) they were added to the ACLs. This *is* procedure. The fact that anyone involved works for Red Hat is entirely irrelevant.
What's unfortunate is that it turns out perl-devel@ isn't the best way to contact the full set of perl package maintainers. That's unfortunate, and we need to figure out how to avoid that kind of situation in the future. But I don't think you can lay direct blame for that on any of the people involved, and certainly not on Red Hat as a whole. No privileges were abused. There was communication. Your assertions are simply incorrect.
One example please
Give me one example within the Fedora Project, where one or more new Fedora Project community members not on Red Hat's payroll;
all within 2 months, and you might get away with stating over and over again that the fact that the people involved all working for Red Hat has nothing to do with any of this.
For what it's worth, I've put in a ticket with FESCo (Toshio's explanation of events is in there) for them to decide on what should happen to prevent this from happening again in the future, right after I blogged about this event.
Like I've mentioned before, I can perfectly well live with any unfortunate effects of simple mistakes. One single response to the CC'ed perl-devel list should have indicated it was the wrong communication channel, but so be it, it happens. Same goes for the assumption that any ACL in the package database including the perl-sig user means the perl-sig has commit access.
You seem to miss my point, again and again, which is apparently I have nothing to say about my own package.
Moreover, you're saying that if one @redhat sponsors two @redhat, and a manager @redhat ACKs an ACL modification request -to be executed by @redhat-, it is entirely correct and justified to have that action result in Approved access rather then Pending Review access (which in fact would have resulted in the appropriate communication cycle with all maintainers), and that it is wrong to point the finger to @redhat. Ironically, it is @redhat arguing right is wrong and wrong is right.
What you are saying is proper procedure equates, to me;
That is, I'm assuming you have a car, you've worked hard in order to be able to afford it and that you are in fact proud to be the owner of that car.
Because that's what happens to me for the parts that I'm involved; I feel proud about it. It doesn't pay the bills, what I get out of it is pride and appreciation (and challenge, and learning curves, and fun).
Regardless, hoping you appreciate my anology even just the tiniest bit, I'd think you are able to relate to the meaning of "ownership" and "proper procedure".
PS. In the interest of full disclosure, I do not have a driver's license, except of course the one I got at the age of 7, from Legoland in Denmark
You had the opportunity to
You had the opportunity to object. It's just unfortunate that that opportunity was the week after an email was posted to a list that you don't read. The proper procedures were followed, but the proper procedures allowed that to happen. That's all that needs fixing.