Hello.
Just noticed that pexpect is in RHEL (RHEL5 since 5.2 and RHEL4 since 4.7) and should therefore be dropped from EPEL.
Hello David,
On Thu, 22 Jan 2009, David Juran wrote:
Just noticed that pexpect is in RHEL (RHEL5 since 5.2 and RHEL4 since 4.7) and should therefore be dropped from EPEL.
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, 2009-01-22 at 10:41 +0100, Robert Scheck wrote:
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.
Since the version of the packages really is the same in both EPEL and RHEL (pyexpect-2.3-1) I guess the proper thing to do would be to bump the release number in RHEL. Or possibly the other way around, by downgrading the EPEL versions to pyexpect-2.3-0.5...
On Thu, 22 Jan 2009, David Juran wrote:
Since the version of the packages really is the same in both EPEL and RHEL (pyexpect-2.3-1) I guess the proper thing to do would be to bump the release number in RHEL. Or possibly the other way around, by downgrading the EPEL versions to pyexpect-2.3-0.5...
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
Robert Scheck wrote:
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.
It must be fixed because, that is the EPEL policy regardless of the history of the package.
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.
I agree on coordination however re-using a spec cannot be called stealing by any means.
Rahul
On Thu, Jan 22, 2009 at 11:56:35PM +0530, Rahul Sundaram wrote:
I agree on coordination however re-using a spec cannot be called stealing by any means.
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, 22 Jan 2009, Rahul Sundaram wrote:
I agree on coordination however re-using a spec cannot be called stealing by any means.
How else would you call stealing then? A Red Hat employee has grabbed my package and used it for RHEL - so far, so good.
Nobody knows, whether this pexpect package from RHEL really works or whether it maybe is screwed up. And according to the RPM %changelog section, the last guy touching that package was me - that's wrong. So if somebody else touches one of my packages, the %changelog must be updated to reflect this. And if the pexpect package in RHEL is maybe fscked up, it indirectly blames me when somebody is then looking to %changelog while the Red Hat pexpect downstream package maintainer is responsible for that problem.
As long as %changelog is not updated accordingly if somebody else is grabbing my package and maybe putting it somewhere else, I will call such actions stealing - independent whether it is our biggest sponsor or not.
Greetings, Robert
On Thu, Jan 22, 2009 at 11:47:27PM +0100, Robert Scheck wrote:
On Thu, 22 Jan 2009, Rahul Sundaram wrote:
I agree on coordination however re-using a spec cannot be called stealing by any means.
How else would you call stealing then? A Red Hat employee has grabbed my package and used it for RHEL - so far, so good.
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 3:47 PM, Robert Scheck robert@fedoraproject.org wrote:
On Thu, 22 Jan 2009, Rahul Sundaram wrote:
I agree on coordination however re-using a spec cannot be called stealing by any means.
How else would you call stealing then? A Red Hat employee has grabbed my package and used it for RHEL - so far, so good.
I believe Stealing is a criminal term: : to take the property of another wrongfully and especially as a habitual or regular practice. It has definite meanings and should be prosecuted as such. But I am not sure any such case can be made:
1) The package is MIT Licensed. Spec files are usually licensed as the mother package so changes/forks etc would be done via MIT unless specified different in the SPEC file.
2) The Fedora CLA says that you have given Red Hat the right to redistribute your works as they see fit.
3) I don't see anything in the CLA or MIT license that says they have to make %changelog entries.
However, in the end.. this is yet again poor customer relations where the customer is the contributor who is doing a lot of the work for Red Hat. It has made you pissed and will become one of those things that people point to of why Red Hat is a pot calling the kettle black about licenses etc.
While I don't think this raises to the level of the Novell iFolder debacle it is time to see what RH community people (*cough* Greg DeKoenigsberg *cough*) can do within Red Hat to help better make these transitions.
On Thu, Jan 22, 2009 at 04:20:50PM -0700, Stephen John Smoogen wrote:
However, in the end.. this is yet again poor customer relations where the customer is the contributor who is doing a lot of the work for Red Hat. It has made you pissed and will become one of those things that people point to of why Red Hat is a pot calling the kettle black about licenses etc.
While I don't think this raises to the level of the Novell iFolder debacle it is time to see what RH community people (*cough* Greg DeKoenigsberg *cough*) can do within Red Hat to help better make these transitions.
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
Robert Scheck wrote:
On Thu, 22 Jan 2009, Rahul Sundaram wrote:
I agree on coordination however re-using a spec cannot be called stealing by any means.
How else would you call stealing then?
A permissively licensed spec file being reused is not stealing and is a very good thing. It is absolutely the right thing to do instead of wasting time reinventing in a perfectly good package. Nothing to do with software distribution should ever be called stealing. That just plays into the hands of proprietary software companies which deliberately confuse things. This has nothing to do with who sponsors what or the otherwise valuable pressure to coordinate better.
It would be good to document best practises when spec files are reused in RHEL as is going to happen repeatedly so that both sides understand what is to be done. Someone interested in not seeing things like this should volunteer.
Rahul
On Fri, 23 Jan 2009, Rahul Sundaram wrote:
It would be good to document best practises when spec files are reused in RHEL as is going to happen repeatedly so that both sides understand what is to be done. Someone interested in not seeing things like this should volunteer.
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 Fri, 2009-01-23 at 14:55 +0100, Robert Scheck wrote:
On Fri, 23 Jan 2009, Rahul Sundaram wrote:
It would be good to document best practises when spec files are reused in RHEL as is going to happen repeatedly so that both sides understand what is to be done. Someone interested in not seeing things like this should volunteer.
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.
I agree completely.
What should be done now is an increase of the release version in RHEL ( / CentOS), in order to get all installations from EPEL to update to the Red Hat version.
What is a completely different question, however, is what to do with the packages in EPEL. If the release in RHEL is incremented, and the package is updated in EPEL afterwards to a higher EVR, the RHEL version will be replaced with the EPEL version.
As a EPEL package maintainer, branching versions for different RHEL releases (Updates) would be a humongous task, as some components need special tweaks to work. Also, running an old release poses a security threat.
Overlapping packages should be removed from EPEL, once a higher EVR is available in RHEL. We shouldn't even think about people who don't want to update to the newest RHEL release; if they need something from EPEL, they can compile the srpms theirself.
On Thu, 22 Jan 2009, Robert Scheck wrote:
On Thu, 22 Jan 2009, David Juran wrote:
Since the version of the packages really is the same in both EPEL and RHEL (pyexpect-2.3-1) I guess the proper thing to do would be to bump the release number in RHEL. Or possibly the other way around, by downgrading the EPEL versions to pyexpect-2.3-0.5...
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.
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
On Thu, 22 Jan 2009, Mike McGrath 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.
I am not willing to see e.g. duplicity on RHEL < 5.2 broken.
In fact, duplicity is used by RHEL 4 and 5 customers and in the past there have been several e-mails from Red Hat supporters (or whoever these guys working at Red Hat are) claiming if something has broken at their customers machines. I don't want to see breakage again as we can avoid it here by not dropping the package.
And I ever thought, EPEL is meant to be stable and reliable to Enterprise customers (even if it isn't supported by Red Hat). If we now really go and break things, we're getting just another fscked up repository out there...
I'm not questioning, that Red Hat decides what goes into RHEL, but if they steal packages silently, that must be communicated and it has to be ensured that upgrading from older versions doesn't break something everywhere (and it is surely known to Red Hat, that e.g. duplicity from EPEL repository is in use by RHEL customers).
What happend for pexpect is a lack of quality assurance at Red Hat and a lack of quality caused by the pexpect downstream package maintainer on Red Hat side, too.
Greetings, Robert
Robert Scheck wrote:
On Thu, 22 Jan 2009, Mike McGrath 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.
I am not willing to see e.g. duplicity on RHEL < 5.2 broken.
In fact, duplicity is used by RHEL 4 and 5 customers and in the past there have been several e-mails from Red Hat supporters (or whoever these guys working at Red Hat are) claiming if something has broken at their customers machines. I don't want to see breakage again as we can avoid it here by not dropping the package.
And I ever thought, EPEL is meant to be stable and reliable to Enterprise customers (even if it isn't supported by Red Hat). If we now really go and break things, we're getting just another fscked up repository out there...
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
On Fri, 23 Jan 2009, Jeroen van Meeuwen 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.
Yes, I've gotten this and can understand that as well.
But my question, I handed out to Mike before as well, didn't get still not answered until now: Why do we _explicitly_ want to _break_ in EPEL what is working and good enough since RHEL 5.0? Please show me the reason why we actually really need to remove it.
Maybe we can't support each z-series of RHEL, but do we really have because of that to explicitly break something then which would go smoothly by its own? It thought until now, we're contributors and try to enhance RHEL with EPEL if and wherever it is possible, but somehow I'm (nearly?) alone with this opinion on the list...
EPEL is Extra Packages for Enterprise Linux, right? There are the words and phrases "Extra Packages" and "Enterprise". Enterprise implicits IMHO, that nothing breaks, everything goes smoothly; "Extra Packages" makes expection to users of additional packages. Our current plan with removing packages in EPEL that got obsoleted due imports into RHEL (instead of just freezing the obsoleted EPEL packagesthem) has for me just less relationship with Extra Packages for Enterprise Linux.
Greetings, Robert
2009/1/23 Robert Scheck robert@fedoraproject.org:
On Fri, 23 Jan 2009, Jeroen van Meeuwen 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.
Yes, I've gotten this and can understand that as well.
But my question, I handed out to Mike before as well, didn't get still not answered until now: Why do we _explicitly_ want to _break_ in EPEL what is working and good enough since RHEL 5.0? Please show me the reason why we actually really need to remove it.
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.
Maybe we can't support each z-series of RHEL, but do we really have because of that to explicitly break something then which would go smoothly by its own? It thought until now, we're contributors and try to enhance RHEL with EPEL if and wherever it is possible, but somehow I'm (nearly?) alone with this opinion on the list...
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.
EPEL is Extra Packages for Enterprise Linux, right? There are the words and phrases "Extra Packages" and "Enterprise". Enterprise implicits IMHO, that nothing breaks, everything goes smoothly; "Extra Packages" makes expection to users of additional packages. Our current plan with removing packages in EPEL that got obsoleted due imports into RHEL (instead of just freezing the obsoleted EPEL packagesthem) has for me just less relationship with Extra Packages for Enterprise Linux.
Greetings, Robert
epel-devel-list mailing list epel-devel-list@redhat.com https://www.redhat.com/mailman/listinfo/epel-devel-list
On Fri, 23 Jan 2009, Stephen John Smoogen wrote:
Maybe we can't support each z-series of RHEL, but do we really have because of that to explicitly break something then which would go smoothly by its own? It thought until now, we're contributors and try to enhance RHEL with EPEL if and wherever it is possible, but somehow I'm (nearly?) alone with this opinion on the list...
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.
Now I don't care what happens with pexpect in EPEL any longer - drop it when you're dropping the other packages that went into RHEL. If EPEL does not want to keep the pexpect RPM package, then simply don't do it.
The EPEL package which a lot of RHEL users care about, is duplicity. That was depending in the past on pexpect. In the future this will be no longer case (thanks to duplicity upstream changing that - independent on the stuff happened on this list), so there is and will be no broken dependency for RHEL < 5.2 users when using duplicity.
Maybe Karsten is really doing something and stuff is not simply the same for RHEL 5.4. Regarding the insane packaging of pexpect in RHEL 4.7+ and RHEL 5.2+ I've made two bug reports which Karsten is also on Cc. Unluckily I'm not expecting, that the insane Red Hat packaging of pexpect will ever change - from Fedora view, we would consider the maintainer simply AWOL.
Greetings, Robert
Mike McGrath 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.
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
Hello Jeroen,
On Fri, 23 Jan 2009, Jeroen van Meeuwen 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).
thank you. You're somehow the first guy on this thread being knowledged in basic things of packaging. I'm also a bit shocked, that such basics are not known to other packagers (aren't some of the people that have shown up here in the thread even provenpackagers? *shrug*).
There's a usual scenario: Customer is using RHEL 5.0, was installing the duplicity package from EPEL, thus pexpect from EPEL popped onto the system; then he updated to RHEL 5.1, everything fine. Then he updated to RHEL 5.2; pexpect from EPEL still remains and the pexpect from RHEL is ignored, as they've both the same (!) ENVRA. So the customer using EPEL before RHEL 5.2 in this case is simply disadvantaged/aggrieved, because he never will get the pexpect package from RHEL without manual interaction.
This is, why I said, Red Hat broke it, Red Hat has to fix it. EPEL cannot solve this in a perfect way. And if the customer is still on a RHEL 5.x.y (where x < 2) tree, he even can't install duplicity because of the missing dependency to pexpect; so lowering release from -1 to -0 is not all.
If such things are not checked by the Red Hat downstream package maintainer this is real lack of quality assurance and also absence of absolutely basic RPM packaging knowledge.
Greetings, Robert
Robert Scheck wrote:
Hello Jeroen,
On Fri, 23 Jan 2009, Jeroen van Meeuwen 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).
thank you. You're somehow the first guy on this thread being knowledged in basic things of packaging. I'm also a bit shocked, that such basics are not known to other packagers (aren't some of the people that have shown up here in the thread even provenpackagers? *shrug*).
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>-owner@fedoraproject.org, saying "this package is now in the following branches/channels".
There's a usual scenario: Customer is using RHEL 5.0, was installing the duplicity package from EPEL, thus pexpect from EPEL popped onto the system; then he updated to RHEL 5.1, everything fine. Then he updated to RHEL 5.2; pexpect from EPEL still remains and the pexpect from RHEL is ignored, as they've both the same (!) ENVRA. So the customer using EPEL before RHEL 5.2 in this case is simply disadvantaged/aggrieved, because he never will get the pexpect package from RHEL without manual interaction.
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.
This is, why I said, Red Hat broke it, Red Hat has to fix it. EPEL cannot solve this in a perfect way. And if the customer is still on a RHEL 5.x.y (where x < 2) tree, he even can't install duplicity because of the missing dependency to pexpect; so lowering release from -1 to -0 is not all.
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
Jeroen van Meeuwen wrote:
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).
You are blaming the wrong people. GSS is just support people. They don't involve themselves with maintaining packages or QA.
Rahul
Rahul Sundaram wrote:
Jeroen van Meeuwen wrote:
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).
You are blaming the wrong people. GSS is just support people. They don't involve themselves with maintaining packages or QA.
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
Jeroen van Meeuwen wrote:
Whoever it is or
whatever the department is called, it's @redhat.com.
I don't think blaming the wrong department is a good idea however.
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.
If this is the goal, it would be very useful to add the information on how to differentiate between EPEL and RHEL to the EPEL wiki pages.
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.
Perhaps it is but it is important to correct it for the record. If you don't want it directed at specific departments, just don't use the acronyms. GSS stands for Global Support Services.
Rahul
2009/1/23 Robert Scheck robert@fedoraproject.org:
Hello Jeroen,
On Fri, 23 Jan 2009, Jeroen van Meeuwen 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).
thank you. You're somehow the first guy on this thread being knowledged in basic things of packaging. I'm also a bit shocked, that such basics are not known to other packagers (aren't some of the people that have shown up here in the thread even provenpackagers? *shrug*).
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.
On Fri, Jan 23, 2009 at 11:56:52AM +0100, Jeroen van Meeuwen wrote:
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?
After this happened in 5.1, I worked on something, but obviously what was put in place then didn't stick. After it happened again in 5.2, I failed to wield the cluestick widely enough to make sure it wouldn't happen again.
The idea was generally approved, afaik -- no one in the RHEL organization is deliberately keeping information from EPEL or the maintainers. There is no communication procedure in place for migrating packages from EPEL. Similarly, the opposite is true -- if a RHEL point release drops a package, EPEL is not informed so that someone has the option to pick up the orphaned pacakge.
I'll do my best from here to get a procedure in place soonest so we have lots of advance notice next time ...
- Karsten
On Thu, 22 Jan 2009, David Juran wrote:
the release number in RHEL. Or possibly the other way around, by downgrading the EPEL versions topyexpect-2.3-0.5...
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
Robert Scheck wrote:
Hello David,
On Thu, 22 Jan 2009, David Juran wrote:
Just noticed that pexpect is in RHEL (RHEL5 since 5.2 and RHEL4 since 4.7) and should therefore be dropped from EPEL.
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
I thought EPEL only really supports the latest RHEL flavors anyway. At least that was my impression from previous similar converations. Has something changed?
-- Rex
On Thu, Jan 22, 2009 at 1:25 PM, Rex Dieter rdieter@math.unl.edu wrote:
Robert Scheck wrote:
Hello David,
On Thu, 22 Jan 2009, David Juran wrote:
Just noticed that pexpect is in RHEL (RHEL5 since 5.2 and RHEL4 since 4.7) and should therefore be dropped from EPEL.
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
I thought EPEL only really supports the latest RHEL flavors anyway. At least that was my impression from previous similar converations. Has something changed?
Currently that is the case. There is not enough infrastructure to do multiple releases of EPEL for 4.x/5.x series.
Stephen John Smoogen wrote:
On Thu, Jan 22, 2009 at 1:25 PM, Rex Dieter rdieter@math.unl.edu wrote:
I thought EPEL only really supports the latest RHEL flavors anyway. At least that was my impression from previous similar converations. Has something changed?
Currently that is the case. There is not enough infrastructure to do multiple releases of EPEL for 4.x/5.x series.
I did not know there was infrastructure constraints to running 4.x/5.x specific versions of EPEL... What limitations do we hit?
Kind regards,
Jeroen van Meeuwen -kanarip
On Thu, 22 Jan 2009, Rex Dieter wrote:
I thought EPEL only really supports the latest RHEL flavors anyway. At least that was my impression from previous similar converations. Has something changed?
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
epel-devel@lists.fedoraproject.org
-
David Juran -
Jeroen van Meeuwen -
Jussi Lehtola -
Karsten Wade -
Mike McGrath -
Patrice Dumas -
Rahul Sundaram -
Ray Van Dolson -
Rex Dieter -
Robert Scheck -
Stephen John Smoogen