FAQ Search Today's Posts Mark Forums Read
» Video Reviews

» Linux Archive

Linux-archive is a website aiming to archive linux email lists and to make them easily accessible for linux users/developers.


» Sponsor

» Partners

» Sponsor

Go Back   Linux Archive > Redhat > EPEL Development

 
 
LinkBack Thread Tools
 
Old 01-22-2009, 09:47 PM
Robert Scheck
 
Default pexepct is in RHEL and should be dropped from EPEL

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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-22-2009, 09:50 PM
Ray Van Dolson
 
Default pexepct is in RHEL and should be dropped from EPEL

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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-22-2009, 09:53 PM
Robert Scheck
 
Default pexepct is in RHEL and should be dropped from EPEL

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-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-22-2009, 10:20 PM
Stephen John Smoogen
 
Default pexepct is in RHEL and should be dropped from EPEL

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.


--
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"

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-23-2009, 08:48 AM
Rahul Sundaram
 
Default pexepct is in RHEL and should be dropped from EPEL

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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-23-2009, 09:56 AM
Jeroen van Meeuwen
 
Default pexepct is in RHEL and should be dropped from EPEL

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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-23-2009, 09:59 AM
Jeroen van Meeuwen
 
Default pexepct is in RHEL and should be dropped from EPEL

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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-23-2009, 10:00 AM
Jeroen van Meeuwen
 
Default pexepct is in RHEL and should be dropped from EPEL

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

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-23-2009, 12:35 PM
Robert Scheck
 
Default pexepct is in RHEL and should be dropped from EPEL

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
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 01-23-2009, 12:55 PM
Robert Scheck
 
Default pexepct is in RHEL and should be dropped from EPEL

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
_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 

Thread Tools




All times are GMT. The time now is 12:52 PM.

VBulletin, Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Content Relevant URLs by vBSEO ©2007, Crawlability, Inc.
Copyright 2007 - 2008, www.linux-archive.org