Hello David, On Thu, 22 Jan 2009, David Juran wrote: nice, that somebody from the Red Hat fraction has been woken up, is Jim Parsons alive? See: https://bugzilla.redhat.com/show_bug.cgi?id=452762 How do you expect that we perform the dropping? We can't remove branches that already exist - spoken for CVS. And the pexpect package *has* to remain in EPEL for users that did not upgrade to RHEL 5.2 (5.0.x, 5.1.x); otherwise e.g. duplicity will get immediately unusable on such systems. Of course I will avoid touching the pexpect that way, that maybe pexpect from RHEL 5.2+/4.7+ gets obsoleted or older. So, pexpect package MUST NOT removed ever from EPEL 4 and 5 as of legacy support mentioned above - period! Greetings, Robert

On Thu, 22 Jan 2009, David Juran wrote: Well, I think the way how the package was stolen in EPEL and imported into RHEL was done a way too silent and thus wrong. If Jim would have come up to me as pexpect maintainer, we could have clarified that before and thus we could have avoid the equivalent release number thing we now have. But does Jim really exist? He didn't yet show up at this e-mails and didn't show any reaction to the bug report... Currently, it is not really possible to push an older version into the EPEL repositiories without manual work, as the scripts allow only newer things - Dennis, am I correct? I don't know, whether it's more easy for Red Hat to cause a release number bump for pexpect. As this mistake was caused by Red Hat, I don't see a good reason, why EPEL shall fix this and take care of it. IMHO a good package maintainer does such things and has a careful look around before acting, especially if the package is stolen (IIRC even the %changelog wasn't changed) - the Red Hat guy didn't do that until now. Greetings, Robert

On Thu, Jan 22, 2009 at 11:56:35PM +0530, Rahul Sundaram wrote: I'd even say that if RHEL stole EPEL package each time when putting it in RHEL there would be less upgrade issue. Of course, the least would be to warn the EPEL maintainer. -- Pat

On Thu, Jan 22, 2009 at 11:47:27PM +0100, Robert Scheck wrote: I'd call it... forking? :) It would be nice courtesy for RH to notify maintainers when this happens, but by no means a requirement. They certainly do themselves a disservice however by pissing off contributors through this sort of behavior (where at least they don't even reply to queries -- I know someone has had a ticket open in bz assigned to whoever took their EPEL package and it's never been touched once). A little PR would go a long way I think. Probably preaching to the crowd here... Ray

On Thu, Jan 22, 2009 at 04:20:50PM -0700, Stephen John Smoogen wrote: Actually, that's me. After this happened for 5.1, I was the one who said I'd find someone to make sure it didn't happen again. I thought I did. Then it happened again in 5.2, and I said the same thing. I thought it was taken care of that time. Now it happened again in 5.3. Folks, I'm really sorry we're still in this state. It is truly not due to incompetence or malice; it's simply a lack of policy and procedure, mostly on the RHEL side. The repeated mistake is disrespectful of the hard work happening in EPEL. I'd appreciate another chance to make this right so it doesn't happen again. I'm glad that those affected made more noise this time, it should help make it clear there really is a problem. - Karsten -- Karsten 'quaid' Wade, Community Gardener http://quaid.fedorapeople.org AD0E0C41

On Fri, 23 Jan 2009, Rahul Sundaram wrote: Best practise is, if packagers would know, how packaging and ENVRA works - which seems not known to all packagers (independent whether Fedora or Red Hat at this case). My previous e-mail explains correct, why not bumping release of ENVRA is broken in such a case (which also would automagically cause %changelog to get silent rpmlint) and why it has to be fixed by Red Hat and why we at EPEL can't fix or solve it completely. So if somebody does not understand that, he/she shouldn't be a RPM packager at all, sorry. Greetings, Robert

On Thu, 22 Jan 2009, Robert Scheck wrote: This is nice and all but EPEL is compatable with RHEL, not the other way around. We, unfortunately, have a one way relationship with RHEL. They decide what goes into RHEL, not us. It would be nice to have more open communcation about these things (I hope that is coming in the future) but still, they can decide whatever they want to. -Mike

Robert Scheck wrote: Does this go to branching for minor RHEL releases? If so, I think the topic was raised before and considered to be way too much work for the small group of people that make up EPEL's core-maintenance team. Regardless, I'd volunteer to help out with branching, maintaining, checking EPEL package lists against RHEL X.Y package lists, and so forth. All I do now is maintain a few packages. Kind regards, Jeroen van Meeuwen -kanarip

2009/1/23 Robert Scheck <robert(a)fedoraproject.org&gt;: EPEL is only meant to work with the latest RHEL tree (eg the latest Y branch... ). This is a liability in how the system was set up but a boon in how much complexity we could handle when setting it up. I would love to be able to handle 5.x trees but what happens when the newest pexpect comes out now... and you update. The 5.0 person is happy because they got an update.. the 5.2 person has problems because it doesn't match what they are expecting from RHN... eg we have broken their assumption. And yes this sucks... but unless we are not upstream for RHEL. We are a side-stream, and have to deal with the overflows and erosion from the bigger river next to us. My opinion is that its broken, but I do not see a solution that we can 'afford' to make without completely re-engineering the project which I am open to hearing how it can be done. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice"

Mike McGrath wrote: I would definitely say that since they're in the business of making customers happy, not us, part of that responsibility is bumping release numbers, searching for higher nevra and communication with the EPEL maintainers, so that their customers remain happy (rather then confused between RHEL and EPEL packages). It doesn't seem like it's all that much effort... I'm not sure what the retiring-a-package policy is on EPEL, but all I'd need is a notification in the line of "don't touch that package anymore". It happened for perl-Net-Telnet, I'm sure it'll happen again for other packages I maintain. It doesn't seem like much effort, either, to give us a list of binary package names they will support, as soon as they hit freezes for RHEL 5.X or Y.Z, or whenever it is they freeze the package list in a cycle. I also think it's a reasonable request to make, but I'm sure this has been raised before... Have we ever actually ask them? If yes, what did they respond? Kind regards, Jeroen van Meeuwen -kanarip

Robert Scheck wrote: Not saying you are right or wrong or whether I agree or disagree with what you just said here, I really want to emphasize that EPEL seems to be "on it's own"; Red Hat GSS does not seem to concern itself with anything in or surrounding EPEL. While this is somewhat to be expected (we are just another third party repo), I'm sure we'll hear about it if and when we do override their packages. And, rather then playing the guilt-question, I'd like to explore opportunities to get this resolved. Red Hat GSS obviously takes advantage with EPEL, as they can often just grab a package from EPEL X to be included in RHEL X.Y+1 whenever they feel like it. I'm pretty sure they put enough QA effort in on such package, but meanwhile they do not even bother to notify the current EPEL maintainer(s). I think making this a standard checklist item in their procedures should help. Even if just sending an (automated?) mail to <package&gt;-owner(a)fedoraproject.org, saying "this package is now in the following branches/channels". On the other end is the issue of EL "customers" still running 4.X or 5.Y and not upgrading. To maintain package foo in EPEL for 4.X or 5.Y (but not 4.X+1 or 5.Y+1), we'd need 4.X/5.Y specific branches. However, the amount of work involved, the infrastructure, the number of volunteers (or their time), and what-have-you, seems to not add up / be in balance in order for us to be able to do so. Personally, I regret that, but I'm not complaining -complaining in my opinion doesn't help. Since I'd love to see these things resolved, I can only wait for us to start doing whatever it is we need to do in a manner that we all think is great and brings peace to the world and then put in some work to get it done. I'm sorta curious how many EPEL users out there run into these kind of situations, and whether it's a real problem for them (or whether it's just annoying). Can we reach out to the EPEL users somehow? Kind regards, Jeroen van Meeuwen -kanarip

Rahul Sundaram wrote: Again, you only point out the wrong, not the right. Whoever it is or whatever the department is called, it's @redhat.com. GSS has the most benefit from getting it right, because they answer the phone when a customer is confused having packages from EPEL that are in RHEL. I think the message I wanted to send out was clear enough on it's own, regardless of getting all the acronyms and departments right. -Jeroen

2009/1/23 Robert Scheck <robert(a)fedoraproject.org&gt;: Thankyou for your insults and innuendo. If this is how you regularly express yourself to humans I can see why you are not getting very far in your end of the discussion. I think everyone who has responded is quite versed in packages. However, your argument was not about that.. your phrasing was about stealing your intellectual property. Did Red Hat not do what is proper packaging, yes clearly. Did they have to? I do not see anything in the MIT or Fedora CLA that says they needed to do so. And so the breakdown is that there are not clearly documented processes on that part of the transaction into the black-box. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice"

On Thu, 22 Jan 2009, David Juran wrote: I've unluckily overlooked that idea a bit - sorry. Dennis, can we downgrade pexpect in EPEL 4 and 5 in order to get this issue on the packaging level sane solved? We would avoid breakage and could be a bit more happy, couldn't we? Dennis, please let me know whether we could drive this, so that I can build a corresponding pexpect package for EPEL 4 and 5 - thank you. I remember a long time EPEL contributor telling, that downgrades on EPEL are just hard and shouldn't be performed (same as unpulling packages) - and this seems to be the perfect case for an exception. Greetings, Robert

On Thu, Jan 22, 2009 at 1:25 PM, Rex Dieter <rdieter(a)math.unl.edu&gt; wrote: Currently that is the case. There is not enough infrastructure to do multiple releases of EPEL for 4.x/5.x series. -- Stephen J Smoogen. -- BSD/GNU/Linux How far that little candle throws his beams! So shines a good deed in a naughty world. = Shakespeare. "The Merchant of Venice"

On Thu, 22 Jan 2009, Rex Dieter wrote: And? Why should we break dependencies in EPEL for something which is working? I still did not get a good reason for that, "just because it is Red Hat" is none. When taking you, I now could say "well, it is just Red Hat, they broke it themself" - that's absolutely identical IMHO. Greetings, Robert