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 07-15-2008, 12:43 PM
"Jon Ciesla"
 
Default Stupid question

FC3 -> RHEL4.

FC6 -> RHEL5.

Presumably, F9 -> RHEL6.

With me so far?

How is maintainership handled when RHEL is based on a Merged (WRT
Core/Extras) Fedora? Pre-merge, Core->RHEL and is maintained by RH folk,
and Extras->EPEL, and is maintained by the community. Post-merge, there
are lots of packages maintained or co-maintained by community folks that
are either historically Core or might be considered so in the process of
choosing packages for RHEL6.

Let's say a package was brought into Fedora and is maintained by a non-RH
person, and RH wants to put it in RHEL6. Who maintains it? The current
maintainer or someone in RH? What about EPEL? Presumably not an EPEL
candidate then?

Normally, I couldn't care less whether someone is RH or non-RH from a
maintainer perspective, I'm just curious about how the above will work.
Probably a non-issue.

Thanks,
Jon


--
novus ordo absurdum

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 07-15-2008, 12:53 PM
Rahul Sundaram
 
Default Stupid question

Jon Ciesla wrote:

FC3 -> RHEL4.

FC6 -> RHEL5.

Presumably, F9 -> RHEL6.

With me so far?


[Not speaking for Red Hat here. Just my understanding of the process]

The RHEL 6 time schedule isn't that strict and RHEL release schedules
are not public information and probably won't be till close to release.



How is maintainership handled when RHEL is based on a Merged (WRT
Core/Extras) Fedora? Pre-merge, Core->RHEL and is maintained by RH folk,
and Extras->EPEL, and is maintained by the community. Post-merge, there
are lots of packages maintained or co-maintained by community folks that
are either historically Core or might be considered so in the process of
choosing packages for RHEL6.

Let's say a package was brought into Fedora and is maintained by a non-RH
person, and RH wants to put it in RHEL6. Who maintains it? The current
maintainer or someone in RH?


Anything in RHEL has to be maintained by a Red Hat employee. Usually,
the same maintainer who will maintain it for RHEL will also
maintain/co-maintain the Fedora branch too to get continous visibility
into the development. When Red Hat branches off from Fedora to RHEL,
product management will find someone to own the RHEL branch regardless
of how it is managed in Fedora.


What about EPEL? Presumably not an EPEL

candidate then?


If it is pulled into RHEL, it is not a EPEL candidate.

Rahul

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 07-15-2008, 01:17 PM
"Jon Ciesla"
 
Default Stupid question

> Jon Ciesla wrote:
>> FC3 -> RHEL4.
>>
>> FC6 -> RHEL5.
>>
>> Presumably, F9 -> RHEL6.
>>
>> With me so far?
>
> [Not speaking for Red Hat here. Just my understanding of the process]
>
> The RHEL 6 time schedule isn't that strict and RHEL release schedules
> are not public information and probably won't be till close to release.

So I assumed.

>> How is maintainership handled when RHEL is based on a Merged (WRT
>> Core/Extras) Fedora? Pre-merge, Core->RHEL and is maintained by RH
>> folk,
>> and Extras->EPEL, and is maintained by the community. Post-merge, there
>> are lots of packages maintained or co-maintained by community folks that
>> are either historically Core or might be considered so in the process of
>> choosing packages for RHEL6.
>>
>> Let's say a package was brought into Fedora and is maintained by a
>> non-RH
>> person, and RH wants to put it in RHEL6. Who maintains it? The current
>> maintainer or someone in RH?
>
> Anything in RHEL has to be maintained by a Red Hat employee. Usually,
> the same maintainer who will maintain it for RHEL will also
> maintain/co-maintain the Fedora branch too to get continous visibility
> into the development. When Red Hat branches off from Fedora to RHEL,
> product management will find someone to own the RHEL branch regardless
> of how it is managed in Fedora.

So if, say, I maintain a package that goes into RHEL, I can expect a new
co-maintainer?

> What about EPEL? Presumably not an EPEL
>> candidate then?
>
> If it is pulled into RHEL, it is not a EPEL candidate.

Perfectly logical. So if it's already in EL-4 and EL-5, we just don't
branch for EL-6. I get it.

> Rahul
>


--
novus ordo absurdum

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 07-15-2008, 01:27 PM
Rahul Sundaram
 
Default Stupid question

Jon Ciesla wrote:

So if, say, I maintain a package that goes into RHEL, I can expect a new
co-maintainer?


I don't know if there is any rule that there should be. I doubt we have
any process to force that or past experience to count on but I expect
any maintainer in RHEL to want to participate in the maintenance of the
branches in Fedora too. Otherwise between a few years of jump between
RHEL releases, they would not have much insight into the changes that go
upstream and resulting feedback from end users which would be a critical
thing when they get to own it for a particular RHEL release for 7 years
or so.



Perfectly logical. So if it's already in EL-4 and EL-5, we just don't
branch for EL-6. I get it.


Usually yes, sometimes packages are added/dropped in between releases
and if someone finds those important they can continue to maintain it
for Fedora and EPEL.


Rahul

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 07-15-2008, 07:30 PM
"Stephen John Smoogen"
 
Default Stupid question

On Tue, Jul 15, 2008 at 6:43 AM, Jon Ciesla <limb@jcomserv.net> wrote:
> FC3 -> RHEL4.
>
> FC6 -> RHEL5.
>
> Presumably, F9 -> RHEL6.
>
> With me so far?
>

It was more coincidence than planning that put the 3 release schedule
difference there. The releases have gotten shorter in time so it might
be 10 or 11 before EL-6 is split.


> How is maintainership handled when RHEL is based on a Merged (WRT
> Core/Extras) Fedora? Pre-merge, Core->RHEL and is maintained by RH folk,
> and Extras->EPEL, and is maintained by the community. Post-merge, there
> are lots of packages maintained or co-maintained by community folks that
> are either historically Core or might be considered so in the process of
> choosing packages for RHEL6.
>

Normally packages are just split off and pulled into RH's internal
VCS. What packages those are etc are not known until about release
time as the Fedora and EL release systems have to meet different
'rules'.


> Let's say a package was brought into Fedora and is maintained by a non-RH
> person, and RH wants to put it in RHEL6. Who maintains it? The current
> maintainer or someone in RH? What about EPEL? Presumably not an EPEL
> candidate then?
>

The package is maintained for EL by a Red Hat engineer and would not
be available in EPEL anymore. The Fedora side would be maintained by
the original person.


> Normally, I couldn't care less whether someone is RH or non-RH from a
> maintainer perspective, I'm just curious about how the above will work.
> Probably a non-issue.
>
> Thanks,
> Jon
>
>
> --
> novus ordo absurdum
>
> _______________________________________________
> epel-devel-list mailing list
> epel-devel-list@redhat.com
> https://www.redhat.com/mailman/listinfo/epel-devel-list
>



--
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 07-16-2008, 08:17 PM
"Tom "spot" Callaway"
 
Default Stupid question

On Tue, 2008-07-15 at 13:30 -0600, Stephen John Smoogen wrote:
> It was more coincidence than planning that put the 3 release schedule
> difference there. The releases have gotten shorter in time so it might
> be 10 or 11 before EL-6 is split.

If I was a betting man, I would put money on this.

*cough*

~spot

_______________________________________________
epel-devel-list mailing list
epel-devel-list@redhat.com
https://www.redhat.com/mailman/listinfo/epel-devel-list
 
Old 02-02-2009, 05:11 AM
Jeroen van Meeuwen
 
Default Stupid question

Hey there,

I've taken over the ruby package, which basically is the first
core-component piece of software on my relatively small list of packages.


Attached is a patch that was in ruby-1.8.6, and that I rebased to
ruby-1.8.7. Since it's a really simple patch, I wonder why it's not
upstream.


I'm not sure what this fixes, in that ruby will build without the patch
as well. I've searched through the logs to see if there's some kind of
warning related to socket.c, but there is none from what I can tell.


I'd love to learn what this patch does and then try and get upstream to
accept it (so that I have less work to do). Can someone on this list
help me with this?


Thanks in advance,

Kind regards,

Jeroen van Meeuwen
-kanarip
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 02-02-2009, 05:30 AM
Jeffrey Ollie
 
Default Stupid question

On Mon, Feb 2, 2009 at 12:11 AM, Jeroen van Meeuwen <kanarip@kanarip.com> wrote:
>
> I've taken over the ruby package, which basically is the first
> core-component piece of software on my relatively small list of packages.
>
> Attached is a patch that was in ruby-1.8.6, and that I rebased to
> ruby-1.8.7. Since it's a really simple patch, I wonder why it's not
> upstream.
>
> I'm not sure what this fixes, in that ruby will build without the patch as
> well. I've searched through the logs to see if there's some kind of warning
> related to socket.c, but there is none from what I can tell.
>
> I'd love to learn what this patch does and then try and get upstream to
> accept it (so that I have less work to do). Can someone on this list help me
> with this?

For a while back in February of '08 was some breakage in glibc where
NI_MAXHOST wasn't defined anymore (at least not under the usual
circumstances that Fedora programs are/were compiled), thus breaking
the build of many different packages, Ruby included. From the looks
of that patch the Ruby developers anticipated NI_MAXHOST being
undefined, but flubbed the fixup. Certainly seems like the patch
should be upstream to me...

--
Jeff Ollie

"You know, I used to think it was awful that life was so unfair. Then
I thought, wouldn't it be much worse if life were fair, and all the
terrible things that happen to us come because we actually deserve
them? So, now I take great comfort in the general hostility and
unfairness of the universe."

-- Marcus to Franklin in Babylon 5: "A Late Delivery from Avalon"

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 02-02-2009, 07:33 AM
Uwe Kubosch
 
Default Stupid question

On Mon, 2009-02-02 at 07:11 +0100, Jeroen van Meeuwen wrote:
> I've taken over the ruby package, which basically is the first
> core-component piece of software on my relatively small list of packages.
>
> Attached is a patch that was in ruby-1.8.6, and that I rebased to
> ruby-1.8.7. Since it's a really simple patch, I wonder why it's not
> upstream.

Please do not move the Ruby 1.8 package to 1.8.7. The consensus in the
Ruby community is that 1.8.7 introduces unnecessary incompatibilities
without really adding value. 1.8.7 is meant as a transitional package
to Ruby 1.9, but the majority of Ruby users will want to keep using Ruby
1.8.6 until they switch directly to Ruby 1.9.1. You should focus on
maintaining Ruby 1.8.6 and Ruby 1.9.1 in parallel. Ruby 1.8.7 should be
passed over unless there is a very clear demand from Fedora users to
introduce it.

--
With kind regards,
Uwe Kubosch
Kubosch Consulting
Norway

--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 
Old 02-02-2009, 11:09 AM
Ignacio Vazquez-Abrams
 
Default Stupid question

On Mon, 2009-02-02 at 09:33 +0100, Uwe Kubosch wrote:
> On Mon, 2009-02-02 at 07:11 +0100, Jeroen van Meeuwen wrote:
> > I've taken over the ruby package, which basically is the first
> > core-component piece of software on my relatively small list of packages.
> >
> > Attached is a patch that was in ruby-1.8.6, and that I rebased to
> > ruby-1.8.7. Since it's a really simple patch, I wonder why it's not
> > upstream.
>
> Please do not move the Ruby 1.8 package to 1.8.7. The consensus in the
> Ruby community is that 1.8.7 introduces unnecessary incompatibilities
> without really adding value. 1.8.7 is meant as a transitional package
> to Ruby 1.9, but the majority of Ruby users will want to keep using Ruby
> 1.8.6 until they switch directly to Ruby 1.9.1. You should focus on
> maintaining Ruby 1.8.6 and Ruby 1.9.1 in parallel. Ruby 1.8.7 should be
> passed over unless there is a very clear demand from Fedora users to
> introduce it.

...

I had something witty-yet-acerbic to respond with, but I think my
presence alone in this thread may be enough :P

--
Ignacio Vazquez-Abrams <ivazqueznet@gmail.com>

PLEASE don't CC me; I'm already subscribed
--
Fedora-packaging mailing list
Fedora-packaging@redhat.com
https://www.redhat.com/mailman/listinfo/fedora-packaging
 

Thread Tools




All times are GMT. The time now is 02:27 AM.

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