For a long time, Red Hat engineers have dropped public RPMs onto people.redhat.com. Now that CentOS is a more official part of the family, it seems like an obvious idea to me, but why not create a "centos7-devel" branch that is public work that is intended to go into the next upstream update?
Several of the existing repos like virt7-testing and atomic7-testing could simply be folded into this repo.
As well as these "hand built" RPMs: http://people.redhat.com/lnykryn/systemd/ http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/
And I'm sure others.
(I wouldn't be surprised if this has come up before but I couldn't figure out any keywords that would find previous conversation on this topic from the archives)
On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote:
For a long time, Red Hat engineers have dropped public RPMs onto people.redhat.com. Now that CentOS is a more official part of the family, it seems like an obvious idea to me, but why not create a "centos7-devel" branch that is public work that is intended to go into the next upstream update?
Several of the existing repos like virt7-testing and atomic7-testing could simply be folded into this repo.
+1, given that packages like docker could be relevant to atomic and virt.
As well as these "hand built" RPMs: http://people.redhat.com/lnykryn/systemd/ http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/
And I'm sure others.
I'd love to see epel get combined with this as well, but I'm probably speaking with a docker-tunneled vision.
(I wouldn't be surprised if this has come up before but I couldn't figure out any keywords that would find previous conversation on this topic from the archives)
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On 7 April 2015 at 09:27, Lokesh Mandvekar lsm5@fedoraproject.org wrote:
On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote:
For a long time, Red Hat engineers have dropped public RPMs onto
people.redhat.com. Now that CentOS is a more official part of the family, it seems like an obvious idea to me, but why not create a "centos7-devel" branch that is public work that is intended to go into the next upstream update?
Several of the existing repos like virt7-testing and atomic7-testing
could simply be folded into this repo.
+1, given that packages like docker could be relevant to atomic and virt.
As well as these "hand built" RPMs: http://people.redhat.com/lnykryn/systemd/ http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/
And I'm sure others.
I'd love to see epel get combined with this as well, but I'm probably speaking with a docker-tunneled vision.
I don't think EPEL could fit in here because the audience for EPEL is a lot more conservative in what they want than what people working on anything from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of pushback from users when things get updated (this is the reason openstack and various other tools have had to been pulled from EPEL in the past..)
That said, I had an idea called EPIC which might be a better place for these items.
(I wouldn't be surprised if this has come up before but I couldn't
figure out any keywords that would find previous conversation on this topic from the archives)
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Wed, Apr 8, 2015 at 1:31 PM, Stephen John Smoogen smooge@gmail.com wrote:
On 7 April 2015 at 09:27, Lokesh Mandvekar lsm5@fedoraproject.org wrote:
On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote:
For a long time, Red Hat engineers have dropped public RPMs onto people.redhat.com. Now that CentOS is a more official part of the family, it seems like an obvious idea to me, but why not create a "centos7-devel" branch that is public work that is intended to go into the next upstream update?
Several of the existing repos like virt7-testing and atomic7-testing could simply be folded into this repo.
+1, given that packages like docker could be relevant to atomic and virt.
As well as these "hand built" RPMs: http://people.redhat.com/lnykryn/systemd/ http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/
And I'm sure others.
I'd love to see epel get combined with this as well, but I'm probably speaking with a docker-tunneled vision.
I don't think EPEL could fit in here because the audience for EPEL is a lot more conservative in what they want than what people working on anything from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of pushback from users when things get updated (this is the reason openstack and various other tools have had to been pulled from EPEL in the past..)
That said, I had an idea called EPIC which might be a better place for these items.
I think you are missing the point of conservatism, which is about not breaking things that already work well. If you can containerize stuff with docker or make it co-exist with stable/working versions with scl-type packaging, I think you'd see much faster acceptance and wider testing of new code. Otherwise, rpm's normal concept of only allowing one version to be installed at a time makes it very difficult to keep your business running while testing something new.
On 8 April 2015 at 12:47, Les Mikesell lesmikesell@gmail.com wrote:
On Wed, Apr 8, 2015 at 1:31 PM, Stephen John Smoogen smooge@gmail.com wrote:
On 7 April 2015 at 09:27, Lokesh Mandvekar lsm5@fedoraproject.org
wrote:
On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote:
For a long time, Red Hat engineers have dropped public RPMs onto people.redhat.com. Now that CentOS is a more official part of the
family,
it seems like an obvious idea to me, but why not create a
"centos7-devel"
branch that is public work that is intended to go into the next
upstream
update?
Several of the existing repos like virt7-testing and atomic7-testing could simply be folded into this repo.
+1, given that packages like docker could be relevant to atomic and
virt.
As well as these "hand built" RPMs: http://people.redhat.com/lnykryn/systemd/ http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/
And I'm sure others.
I'd love to see epel get combined with this as well, but I'm probably speaking with a docker-tunneled vision.
I don't think EPEL could fit in here because the audience for EPEL is a
lot
more conservative in what they want than what people working on anything from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5%
are
EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot
of
pushback from users when things get updated (this is the reason openstack and various other tools have had to been pulled from EPEL in the past..)
That said, I had an idea called EPIC which might be a better place for
these
items.
I think you are missing the point of conservatism, which is about not
And I think you are jumping to conclusions about my point. So we are both at a loss to how to communicate.
On Wed, Apr 8, 2015 at 1:59 PM, Stephen John Smoogen smooge@gmail.com wrote:
I think you are missing the point of conservatism, which is about not
And I think you are jumping to conclusions about my point. So we are both at a loss to how to communicate.
Maybe... But there's a need to have wide testing of new code, and there's a need to be able to run multiple versions of packages concurrently (hence docker/scl, etc.). Seems like there should be a fit somewhere...
On Wed, Apr 8, 2015 at 2:31 PM, Stephen John Smoogen smooge@gmail.com wrote:
On 7 April 2015 at 09:27, Lokesh Mandvekar lsm5@fedoraproject.org wrote:
On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote:
For a long time, Red Hat engineers have dropped public RPMs onto people.redhat.com. Now that CentOS is a more official part of the family, it seems like an obvious idea to me, but why not create a "centos7-devel" branch that is public work that is intended to go into the next upstream update?
Several of the existing repos like virt7-testing and atomic7-testing could simply be folded into this repo.
+1, given that packages like docker could be relevant to atomic and virt.
As well as these "hand built" RPMs: http://people.redhat.com/lnykryn/systemd/ http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/
And I'm sure others.
I'd love to see epel get combined with this as well, but I'm probably speaking with a docker-tunneled vision.
I don't think EPEL could fit in here because the audience for EPEL is a lot more conservative in what they want than what people working on anything from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5% are EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot of pushback from users when things get updated (this is the reason openstack and various other tools have had to been pulled from EPEL in the past..)
That's partly because there are a *lot* of components in EPEL 6 than are present in EPEL 7. I ran headlong into this trying to build up RT version 4, the perl dependencies include something like 20 perl module SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are available in EPEL 6.
That said, I had an idea called EPIC which might be a better place for these items.
(I wouldn't be surprised if this has come up before but I couldn't figure out any keywords that would find previous conversation on this topic from the archives)
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-- Lokesh Freenode, OFTC: lsm5 GPG: 0xC7C3A0DD
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-- Stephen J Smoogen.
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
On Wed, Apr 8, 2015 at 7:20 PM, Nico Kadel-Garcia nkadel@gmail.com wrote:
Projects which are aimed at the EL-7 -> EL-8 space will get a lot of pushback from users when things get updated (this is the reason openstack and various other tools have had to been pulled from EPEL in the past..)
That's partly because there are a *lot* of components in EPEL 6 than are present in EPEL 7. I ran headlong into this trying to build up RT version 4, the perl dependencies include something like 20 perl module SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are available in EPEL 6.
Do you know if there is some showstopper reason for this or is is just that it takes a long time to get done? I just noticed the other day that backuppc isn't there either.
On Wed, 8 Apr 2015 20:46:31 -0500 Les Mikesell lesmikesell@gmail.com wrote:
On Wed, Apr 8, 2015 at 7:20 PM, Nico Kadel-Garcia nkadel@gmail.com wrote:
Projects which are aimed at the EL-7 -> EL-8 space will get a lot of pushback from users when things get updated (this is the reason openstack and various other tools have had to been pulled from EPEL in the past..)
That's partly because there are a *lot* of components in EPEL 6 than are present in EPEL 7. I ran headlong into this trying to build up RT version 4, the perl dependencies include something like 20 perl module SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are available in EPEL 6.
Do you know if there is some showstopper reason for this or is is just that it takes a long time to get done? I just noticed the other day that backuppc isn't there either.
http://www.scrye.com/wordpress/nirik/2014/11/26/how-packages-are-added-to-ep...
kevin
On Wed, Apr 08, 2015 at 07:53:59PM -0600, Kevin Fenzi wrote:
Do you know if there is some showstopper reason for this or is is just that it takes a long time to get done? I just noticed the other day that backuppc isn't there either.
http://www.scrye.com/wordpress/nirik/2014/11/26/how-packages-are-added-to-ep...
tl;dr: Maintaining a package in EPEL is a big commitment and can be a lot of work; people aren't automatically commited to new versions. If a package isn't in EPEL 7, talk to the EPEL 6 maintainer and consider helping out.
On 8 April 2015 at 18:20, Nico Kadel-Garcia nkadel@gmail.com wrote:
On Wed, Apr 8, 2015 at 2:31 PM, Stephen John Smoogen smooge@gmail.com wrote:
On 7 April 2015 at 09:27, Lokesh Mandvekar lsm5@fedoraproject.org
wrote:
On Tue, Apr 07, 2015 at 11:10:47AM -0400, Colin Walters wrote:
For a long time, Red Hat engineers have dropped public RPMs onto people.redhat.com. Now that CentOS is a more official part of the
family,
it seems like an obvious idea to me, but why not create a
"centos7-devel"
branch that is public work that is intended to go into the next
upstream
update?
Several of the existing repos like virt7-testing and atomic7-testing could simply be folded into this repo.
+1, given that packages like docker could be relevant to atomic and
virt.
As well as these "hand built" RPMs: http://people.redhat.com/lnykryn/systemd/ http://people.redhat.com/~rjones/libguestfs-RHEL-7.1-preview/
And I'm sure others.
I'd love to see epel get combined with this as well, but I'm probably speaking with a docker-tunneled vision.
I don't think EPEL could fit in here because the audience for EPEL is a
lot
more conservative in what they want than what people working on anything from this decade want. 45% of EPEL users are EL-5, 50% are EL-6 and 5%
are
EL-7. Projects which are aimed at the EL-7 -> EL-8 space will get a lot
of
pushback from users when things get updated (this is the reason openstack and various other tools have had to been pulled from EPEL in the past..)
That's partly because there are a *lot* of components in EPEL 6 than are present in EPEL 7. I ran headlong into this trying to build up RT version 4, the perl dependencies include something like 20 perl module SRPM's that are not in EPEL 7 or in CentOS 7. Many of them are available in EPEL 6.
I wish that were the smoking gun, but the growth graphs show that RHEL-5 and RHEL-6 started to grow only after the .2 release was out. At that point the growth begins.
Most of the components are not in EL-7 because maintainers are expected to actively put them into a particular release. We get way more pushback from developers finding out that their package is in an EL without their knowledge than we do from either consumers of EPEL not finding a particular one. [And yes we get a lot of feedback from consumers saying 'why isn't perl-xyz in there when it is in EL-5 and EL-6.]
On 04/09/2015 10:51 AM, Stephen John Smoogen wrote:
We get way more pushback from developers finding out that their package is in an EL without their knowledge than we do from either consumers of EPEL not finding a particular one.
Bit of a tangent... but would you mind clarifying who "we" is there? If there is pushback to EPEL packagers, I'm not seeing it on the epel-devel list, or in the bugs I'm watching, so it must be happening through other channels?
- Ken
On 9 April 2015 at 11:01, Ken Dreyer kdreyer@redhat.com wrote:
On 04/09/2015 10:51 AM, Stephen John Smoogen wrote:
We get way more pushback from developers finding out that their package is in an EL without their knowledge than we do from either consumers of EPEL not finding a particular one.
Bit of a tangent... but would you mind clarifying who "we" is there? If there is pushback to EPEL packagers, I'm not seeing it on the epel-devel list, or in the bugs I'm watching, so it must be happening through other channels?
My apologies.. 'we' was a royal we meaning the people who are 'running' the EPEL project, EPSCO for no better word. The pushback from developers came when packages were branched into a new EPEL release without the developer knowing about it. [EG if you owned say nethack and were listed in EL-5 but found that you were getting asked about bugs in EL-6 or EL-7 which you had no interest in and no other developer had asked to maintain it in EL-6 or EL-7].
The problem usually are reported in direct emails or IRC. We also see the opposite emails where the developers are wondering why their package wasn't put in EL-6 or EL-7 when they had it in EL-5... but the release group decided it was better to surprise on the side of caution (eg no branch into EL-X)
- Ken
CentOS-devel mailing list CentOS-devel@centos.org http://lists.centos.org/mailman/listinfo/centos-devel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
On 09.04.2015 19:21, Stephen John Smoogen wrote:
The problem usually are reported in direct emails or IRC. We also see the opposite emails where the developers are wondering why their package wasn't put in EL-6 or EL-7 when they had it in EL-5... but the release group decided it was better to surprise on the side of caution (eg no branch into EL-X)
I don't get why either side (user or developer/maintainer) needs to get "surprised"?
Couldn't a simple mechanism exists which asks every package maintainer before a new epel release gets created if his package should be included there (a mail with a link to website with a yes/no button would suffice, or something similar)?
you could also create opt-in or opt-out of such a function if people find it too annoying (after all it's just one email every X years).
this of course assumes you have mail addresses of maintainers at hand. I don't know if this is the case, but I hope so.
And of course someone would have to work out this stuff.
kind regards
Sven
On 04/10/2015 12:02 AM, Sven Kieske wrote:
Couldn't a simple mechanism exists which asks every package maintainer before a new epel release gets created if his package should be included there (a mail with a link to website with a yes/no button would suffice, or something similar)?
By the simple fact of not creating an EL-7 branch, they've already opted for "no". Most businesses still stay away of RHEL7/CentOS 7 and therefore there still is little traction for EPEL7 as well. I am pretty sure that things will change once EL5 becomes [even more] deprecated and people switch to EL 7, but more water needs to flow below the bridges first.
On Wed, Apr 8, 2015, at 02:31 PM, Stephen John Smoogen wrote:
I don't think EPEL could fit in here because the audience for EPEL is a lot more conservative in what they want than what people working on anything from this decade want.
An important point of this "CentOS.devel" repository would be that EPEL would *not* be present in the buildroot - this is only for newer versions of the core packages which should be self-hosting.
(Snip lots of other discussion about EPEL)
On 13/04/15 23:00, Colin Walters wrote:
On Wed, Apr 8, 2015, at 02:31 PM, Stephen John Smoogen wrote:
I don't think EPEL could fit in here because the audience for EPEL is a lot more conservative in what they want than what people working on anything from this decade want.
An important point of this "CentOS.devel" repository would be that EPEL would *not* be present in the buildroot - this is only for newer versions of the core packages which should be self-hosting.
A while back, we spoke about having repos that dont map to SIG's - sort of a common pool that anyone from any SIG might be able to contribute into. The driving problem-space for that, was to setup an idea of upstreams, where people could build + push content that mapped to upstream releases, so users wanting to optionally switch to one or two cherry picked components might be able to do so easily.
We could create something similar for this space you defined, call it something like 'Rawhide' ( or a better word really ) - and allow arbitrary content in there, but it would still need to come via a SIG route, so there is decentralisation of content control. One of the challenges in this model would be that all content would more or less rely on other content in the same repo. I am not sure if that would be more of a problem ?
given that koji tagging is cheap - and there is some work around creating tag's automagically - could we overload that a bit an find a way to build one or more, and only those one or more srpms in a chain that link to other content in the distro ( thereby creating a series of repos, each delivering one or more features, without needing to consume the entire 'devel' stack ).
- KB
-
Colin Walters -
Karanbir Singh -
Ken Dreyer -
Kevin Fenzi -
Les Mikesell -
Lokesh Mandvekar -
Manuel Wolfshant -
Matthew Miller -
Nico Kadel-Garcia -
Stephen John Smoogen -
Sven Kieske