Hi,
RHSCL 1.0 is GA since September.
RHSCL 1.1 Beta is released today: http://developerblog.redhat.com/2014/03/20/rhscl-1-1-beta-available-apache-m...
As EPEL is the common repository to find additional packages for RHEL, I really think it should also be possible to provide additional packages for RHSCL.
For now the Fedora Guidelines are still under discussion.
Most of the discussion is about the tree layout (/var, /etc/, ...). This Guidelines will probably need more work/time before approval :(
Of course, if some "new" SCL (new, as not in upstream product) will come to EPEL, it will have to follow the same Guidelines.
But, for additional packages for existing collections (I mean extending RHSCL), thinks can be simpler. We only have to use the tree as defined in the RHSCL collection (in the meta-package).
I really hope we can find some solution.
Of course, we need to ensure, with rel-eng, that we are able to build those packages.
So, time to raise the discussion.
Remi.
P.S. you will notice that whatever we decide, things will happen (and have already start), we just need to know if we want to see this in EPEL or outside.
On 20 March 2014 12:02, Remi Collet Fedora@famillecollet.com wrote:
Hi,
RHSCL 1.0 is GA since September.
RHSCL 1.1 Beta is released today:
http://developerblog.redhat.com/2014/03/20/rhscl-1-1-beta-available-apache-m...
As EPEL is the common repository to find additional packages for RHEL, I really think it should also be possible to provide additional packages for RHSCL.
I have been thinking about this and wondering if SCL's might be better under Robyn's "EPIC" (Extra Packages for Infrastructure and Clouds) which would be something that could have less rigid rules for keeping going for 12 years that would be more in line with SCL's 2-3 year lifetimes. I was going to bring it up as a FLOCK talk to get the ball running with possible interaction with the CentOS group (maybe joining with their SCL operations). Does that make sense?
For now the Fedora Guidelines are still under discussion.
Most of the discussion is about the tree layout (/var, /etc/, ...). This Guidelines will probably need more work/time before approval :(
Of course, if some "new" SCL (new, as not in upstream product) will come to EPEL, it will have to follow the same Guidelines.
But, for additional packages for existing collections (I mean extending RHSCL), thinks can be simpler. We only have to use the tree as defined in the RHSCL collection (in the meta-package).
I really hope we can find some solution.
Of course, we need to ensure, with rel-eng, that we are able to build those packages.
So, time to raise the discussion.
Remi.
P.S. you will notice that whatever we decide, things will happen (and have already start), we just need to know if we want to see this in EPEL or outside. _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
On Thu, Mar 20, 2014 at 04:15:18PM -0600, Stephen John Smoogen wrote:
I have been thinking about this and wondering if SCL's might be better under Robyn's "EPIC" (Extra Packages for Infrastructure and Clouds) which would be something that could have less rigid rules for keeping going for 12 years that would be more in line with SCL's 2-3 year lifetimes. I was going to bring it up as a FLOCK talk to get the ball running with possible interaction with the CentOS group (maybe joining with their SCL operations). Does that make sense?
It makes a ton of sense to me, at least.
On 03/20/2014 05:15 PM, Stephen John Smoogen wrote:
I have been thinking about this and wondering if SCL's might be better under Robyn's "EPIC" (Extra Packages for Infrastructure and Clouds)
I hate that name, but the idea behind the repo is sound.
would be something that could have less rigid rules for keeping going for 12 years that would be more in line with SCL's 2-3 year lifetimes. I was going to bring it up as a FLOCK talk to get the ball running with possible interaction with the CentOS group (maybe joining with their SCL operations). Does that make sense?
It makes sense to me as well. Could you elaborate a bit on how you envision this working? What role do you see CentOS playing? (yes I'm impatient and don't want to wait for FLOCK :-P )
On 20 March 2014 17:13, Jim Perrin jperrin@centos.org wrote:
On 03/20/2014 05:15 PM, Stephen John Smoogen wrote:
I have been thinking about this and wondering if SCL's might be better under Robyn's "EPIC" (Extra Packages for Infrastructure and Clouds)
I hate that name, but the idea behind the repo is sound.
Well its like EPEL. If someone can come up with a better name before we start using it... we can go with that. If no one comes up with a good name by then it stays with the bad name.
would be something that could have less rigid rules for keeping going for 12 years that would be more in line with SCL's 2-3 year lifetimes. I was going to bring it up as a FLOCK talk to get the ball running with
possible
interaction with the CentOS group (maybe joining with their SCL operations). Does that make sense?
It makes sense to me as well. Could you elaborate a bit on how you envision this working? What role do you see CentOS playing? (yes I'm impatient and don't want to wait for FLOCK :-P )
Well at the moment it is mostly ganga smoke. The role would be where things like the Alternative Desktops would go as having a desktop which might not be backwards compatible and not living longer than 4 years doesn't fit into how EPEL has packaged things in the past. After that it is a bit hazy.. the main reason for using CentOS is that this would be something outside of the core precepts of Fedora and working with CentOS would enable a better community grouping.
Oh I have one rule. Repotags will be enabled.
-- Jim Perrin The CentOS Project | http://www.centos.org twitter: @BitIntegrity | GPG Key: FA09AD77 _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
On 20.03.2014 23:15, Stephen John Smoogen wrote:
On 20 March 2014 12:02, Remi Collet <Fedora@famillecollet.com mailto:Fedora@famillecollet.com> wrote:
Hi, RHSCL 1.0 is GA since September. RHSCL 1.1 Beta is released today: http://developerblog.redhat.com/2014/03/20/rhscl-1-1-beta-available-apache-mongodb/ As EPEL is the common repository to find additional packages for RHEL, I really think it should also be possible to provide additional packages for RHSCL.I have been thinking about this and wondering if SCL's might be better under Robyn's "EPIC" (Extra Packages for Infrastructure and Clouds) which would be something that could have less rigid rules for keeping going for 12 years that would be more in line with SCL's 2-3 year lifetimes. I was going to bring it up as a FLOCK talk to get the ball running with possible interaction with the CentOS group (maybe joining with their SCL operations). Does that make sense?
I've never heard of this EPIC repository and google doesn't seem to know it either. Where can this be found?
Regards, Dennis
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 03/20/2014 05:30 PM, Dennis Jacobfeuerborn wrote:
I've never heard of this EPIC repository and google doesn't seem to know it either. Where can this be found?
It doesn't exist, it's an idea that Robyn has floated semi-seriously as a way to provide a repo that moves faster than EPEL. Rather than try to jam fast-moving stuff in to EPEL, the idea was to do an Extra Packages for Infrastructure and Cloud (EPIC) that had a different, faster-moving charter. EPIC would target the *EL platform just as EPEL does.
For the record, *I* think EPIC is an epic name.
- - Karsten - -- Karsten 'quaid' Wade .^\ CentOS Doer of Stuff http://TheOpenSourceWay.org \ http://community.redhat.com @quaid (identi.ca/twitter/IRC) \v' gpg: AD0E0C41
On Thu, Mar 20, 2014 at 06:35:38PM -0700, Karsten Wade wrote:
I've never heard of this EPIC repository and google doesn't seem to know it either. Where can this be found?
It doesn't exist, it's an idea that Robyn has floated semi-seriously as a way to provide a repo that moves faster than EPEL. Rather than try to jam fast-moving stuff in to EPEL, the idea was to do an Extra Packages for Infrastructure and Cloud (EPIC) that had a different, faster-moving charter. EPIC would target the *EL platform just as EPEL does.
I think this is a great place to try out what we can do with CentOS collaboration, since they're officially "in the family" now. Anyone have ideas on how best to proceed with that? New SIGs in both projects? A single new SIG spanning both? (CentOS's new SIGs seem to be a lot more heavyweight in terms of process than the concept we have for them in Fedora, for better or worse.) Some new joint upstream to be the meeting point?
Robyn, you around? Want to lay out the idea in more depth?
2014-03-21 16:07 GMT+04:00 Matthew Miller mattdm@fedoraproject.org:
It doesn't exist, it's an idea that Robyn has floated semi-seriously as a way to provide a repo that moves faster than EPEL. Rather than try to jam fast-moving stuff in to EPEL, the idea was to do an Extra Packages for Infrastructure and Cloud (EPIC) that had a different, faster-moving charter. EPIC would target the *EL platform just as EPEL does.
Faster moving rate is great indeed. But adding more than on version of software (no matter of how many repos it takes) means only one - we have to impose additional support requiremetns on a packagers.
The "social contract" requiremens for EPEL "support" (which of souce isn't a "real" support) is way too high for the average maintainer. That's the reason I believe the entire EPEL idea was a huge mistake and waste of time - unfortunately I failed to discuss this with other fellow fedora members during FOSDEM Fedora.NEXT related talks.
I think this is a great place to try out what we can do with CentOS collaboration, since they're officially "in the family" now. Anyone have ideas on how best to proceed with that? New SIGs in both projects? A single new SIG spanning both? (CentOS's new SIGs seem to be a lot more heavyweight in terms of process than the concept we have for them in Fedora, for better or worse.) Some new joint upstream to be the meeting point?
No matter of the current situation I'd love to discuss possible ways to improve it. So count me in as well.
----- Original Message -----
From: "Peter Lemenkov" lemenkov@gmail.com To: "EPEL Development List" epel-devel@lists.fedoraproject.org Cc: rbergero@fedoraproject.org Sent: Friday, March 21, 2014 6:25:50 PM Subject: Re: EPEL EPIC! [was Re: and SCL]
2014-03-21 16:07 GMT+04:00 Matthew Miller mattdm@fedoraproject.org:
It doesn't exist, it's an idea that Robyn has floated semi-seriously as a way to provide a repo that moves faster than EPEL. Rather than try to jam fast-moving stuff in to EPEL, the idea was to do an Extra Packages for Infrastructure and Cloud (EPIC) that had a different, faster-moving charter. EPIC would target the *EL platform just as EPEL does.
Faster moving rate is great indeed. But adding more than on version of software (no matter of how many repos it takes) means only one - we have to impose additional support requiremetns on a packagers.
The "social contract" requiremens for EPEL "support" (which of souce isn't a "real" support) is way too high for the average maintainer. That's the reason I believe the entire EPEL idea was a huge mistake and waste of time - unfortunately I failed to discuss this with other fellow fedora members during FOSDEM Fedora.NEXT related talks.
Completely agreed about the issues surrounding maintenance and security backporting. Even upstreams that are supportive of packaging in distros just *can't* support a basically randomly supported of their software for 10 years. EPEL 5 is so neglected at this point, and EPEL 6 is heading that direction because the upstreams simply don't have the manpower to be able to work with the software is packaging a (4|8) year old version of their software. Additionally, most people who run enterprise linux expect ABI/API and upgrade stability so maintainers resort to changing their packages as little as possible. That manifests itself as neglect.
I'd love to see EPIC happen, as I've been telling robyn for the past year and a half :-)
I think this is a great place to try out what we can do with CentOS collaboration, since they're officially "in the family" now. Anyone have ideas on how best to proceed with that? New SIGs in both projects? A single new SIG spanning both? (CentOS's new SIGs seem to be a lot more heavyweight in terms of process than the concept we have for them in Fedora, for better or worse.) Some new joint upstream to be the meeting point?
No matter of the current situation I'd love to discuss possible ways to improve it. So count me in as well.
-- With best regards, Peter Lemenkov. _______________________________________________ epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
On 03/21/2014 11:49 AM, Sam Kottler wrote:
----- Original Message -----
From: "Peter Lemenkov" lemenkov@gmail.com To: "EPEL Development List" epel-devel@lists.fedoraproject.org Cc: rbergero@fedoraproject.org Sent: Friday, March 21, 2014 6:25:50 PM Subject: Re: EPEL EPIC! [was Re: and SCL]
2014-03-21 16:07 GMT+04:00 Matthew Miller mattdm@fedoraproject.org:
It doesn't exist, it's an idea that Robyn has floated semi-seriously as a way to provide a repo that moves faster than EPEL. Rather than try to jam fast-moving stuff in to EPEL, the idea was to do an Extra Packages for Infrastructure and Cloud (EPIC) that had a different, faster-moving charter. EPIC would target the *EL platform just as EPEL does.
Faster moving rate is great indeed. But adding more than on version of software (no matter of how many repos it takes) means only one - we have to impose additional support requiremetns on a packagers.
The "social contract" requiremens for EPEL "support" (which of souce isn't a "real" support) is way too high for the average maintainer. That's the reason I believe the entire EPEL idea was a huge mistake and waste of time - unfortunately I failed to discuss this with other fellow fedora members during FOSDEM Fedora.NEXT related talks.
Completely agreed about the issues surrounding maintenance and security backporting. Even upstreams that are supportive of packaging in distros just *can't* support a basically randomly supported of their software for 10 years. EPEL 5 is so neglected at this point, and EPEL 6 is heading that direction because the upstreams simply don't have the manpower to be able to work with the software is packaging a (4|8) year old version of their software. Additionally, most people who run enterprise linux expect ABI/API and upgrade stability so maintainers resort to changing their packages as little as possible. That manifests itself as neglect.
I'd love to see EPIC happen, as I've been telling robyn for the past year and a half :-)
So, lets lay out a couple assumptions and improvements and see where we end up.
What are the needs and wants for both packagers and users? What are the lessons to learn from EPEL when creating EPIC? Does one repository solve this, or would this need to be a project structure with multiple repositories underneath?
On 21 March 2014 16:58, Jim Perrin jperrin@centos.org wrote:
On 03/21/2014 11:49 AM, Sam Kottler wrote:
----- Original Message -----
From: "Peter Lemenkov" lemenkov@gmail.com To: "EPEL Development List" epel-devel@lists.fedoraproject.org Cc: rbergero@fedoraproject.org Sent: Friday, March 21, 2014 6:25:50 PM Subject: Re: EPEL EPIC! [was Re: and SCL]
2014-03-21 16:07 GMT+04:00 Matthew Miller mattdm@fedoraproject.org:
It doesn't exist, it's an idea that Robyn has floated semi-seriously as a way to provide a repo that moves faster than EPEL. Rather than try to jam fast-moving stuff in to EPEL, the idea was to do an Extra Packages for Infrastructure and Cloud (EPIC) that had a different, faster-moving charter. EPIC would target the *EL platform just as EPEL does.
Faster moving rate is great indeed. But adding more than on version of software (no matter of how many repos it takes) means only one - we have to impose additional support requiremetns on a packagers.
The "social contract" requiremens for EPEL "support" (which of souce isn't a "real" support) is way too high for the average maintainer. That's the reason I believe the entire EPEL idea was a huge mistake and waste of time - unfortunately I failed to discuss this with other fellow fedora members during FOSDEM Fedora.NEXT related talks.
Completely agreed about the issues surrounding maintenance and security
backporting. Even upstreams that are supportive of packaging in distros just *can't* support a basically randomly supported of their software for 10 years. EPEL 5 is so neglected at this point, and EPEL 6 is heading that direction because the upstreams simply don't have the manpower to be able to work with the software is packaging a (4|8) year old version of their software. Additionally, most people who run enterprise linux expect ABI/API and upgrade stability so maintainers resort to changing their packages as little as possible. That manifests itself as neglect.
I'd love to see EPIC happen, as I've been telling robyn for the past
year and a half :-)
So, lets lay out a couple assumptions and improvements and see where we end up.
What are the needs and wants for both packagers and users? What are the lessons to learn from EPEL when creating EPIC? Does one repository solve this, or would this need to be a project structure with multiple repositories underneath?
I have a project proposal in my head and need about 48 hours to type it up and such. However this weekend is booked solid. If people can wait til Wodin's day next week, I should have it done and ready to post. Otherwise I can pepper answers to my ideas on Monday/Tuesday.
<<repotags>>
*bump*
On 03/21/2014 07:43 PM, Stephen John Smoogen wrote:
On 21 March 2014 16:58, Jim Perrin jperrin@centos.org wrote:
On 03/21/2014 11:49 AM, Sam Kottler wrote:
----- Original Message -----
From: "Peter Lemenkov" lemenkov@gmail.com To: "EPEL Development List" epel-devel@lists.fedoraproject.org Cc: rbergero@fedoraproject.org Sent: Friday, March 21, 2014 6:25:50 PM Subject: Re: EPEL EPIC! [was Re: and SCL]
2014-03-21 16:07 GMT+04:00 Matthew Miller mattdm@fedoraproject.org:
It doesn't exist, it's an idea that Robyn has floated semi-seriously as a way to provide a repo that moves faster than EPEL. Rather than try to jam fast-moving stuff in to EPEL, the idea was to do an Extra Packages for Infrastructure and Cloud (EPIC) that had a different, faster-moving charter. EPIC would target the *EL platform just as EPEL does.
Faster moving rate is great indeed. But adding more than on version of software (no matter of how many repos it takes) means only one - we have to impose additional support requiremetns on a packagers.
The "social contract" requiremens for EPEL "support" (which of souce isn't a "real" support) is way too high for the average maintainer. That's the reason I believe the entire EPEL idea was a huge mistake and waste of time - unfortunately I failed to discuss this with other fellow fedora members during FOSDEM Fedora.NEXT related talks.
Completely agreed about the issues surrounding maintenance and security
backporting. Even upstreams that are supportive of packaging in distros just *can't* support a basically randomly supported of their software for 10 years. EPEL 5 is so neglected at this point, and EPEL 6 is heading that direction because the upstreams simply don't have the manpower to be able to work with the software is packaging a (4|8) year old version of their software. Additionally, most people who run enterprise linux expect ABI/API and upgrade stability so maintainers resort to changing their packages as little as possible. That manifests itself as neglect.
I'd love to see EPIC happen, as I've been telling robyn for the past
year and a half :-)
So, lets lay out a couple assumptions and improvements and see where we end up.
What are the needs and wants for both packagers and users? What are the lessons to learn from EPEL when creating EPIC? Does one repository solve this, or would this need to be a project structure with multiple repositories underneath?
I have a project proposal in my head and need about 48 hours to type it up and such. However this weekend is booked solid. If people can wait til Wodin's day next week, I should have it done and ready to post. Otherwise I can pepper answers to my ideas on Monday/Tuesday.
<<repotags>>
epel-devel mailing list epel-devel@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/epel-devel
Hey all. I don't know if you noticed, but Smooge has a talk proposal at Flock about this. Go to
https://admin.fedoraproject.org/voting/vote_range/flock-2014
and put "128" for "EPEL.next". (It's a slightly confusing range-voting scheme -- you can put any value for any talk including reusing numbers, and high means very interested and 0 means not at all.)
Obviously you should also vote for other interesting talks as well at the same time. And I hope to see a bunch of the interested people there!
On Fri, Mar 21, 2014 at 6:25 AM, Peter Lemenkov lemenkov@gmail.com wrote:
2014-03-21 16:07 GMT+04:00 Matthew Miller mattdm@fedoraproject.org:
It doesn't exist, it's an idea that Robyn has floated semi-seriously as a way to provide a repo that moves faster than EPEL. Rather than try to jam fast-moving stuff in to EPEL, the idea was to do an Extra Packages for Infrastructure and Cloud (EPIC) that had a different, faster-moving charter. EPIC would target the *EL platform just as EPEL does.
Faster moving rate is great indeed. But adding more than on version of software (no matter of how many repos it takes) means only one - we have to impose additional support requiremetns on a packagers.
The "social contract" requiremens for EPEL "support" (which of souce isn't a "real" support) is way too high for the average maintainer. That's the reason I believe the entire EPEL idea was a huge mistake and waste of time - unfortunately I failed to discuss this with other fellow fedora members during FOSDEM Fedora.NEXT related talks.
I think everyone speaks from their own corner of EPEL and the packages they care about. I know EPEL feels like a mistake and a waste of time to you in the context of your past discussions about the Erlang packages (and maybe you're thinking of others as well). From my own perspective, there are a ton of packages in EPEL that I rely on which are quite stable (for example the Perl ones).
When I imagine a world without EPEL, individual users and sites would still need to address the problems of remediating CVEs, dealing with unstable upstreams, etc., but they wouldn't have the benefit of sharing the infrastructure and testing with other sites.
There are certainly areas for improvement, like any open-source project, but I wanted to share my perspective that I think EPEL still does more good than harm, even in its current form.
- Ken
On 03/21/2014 12:06 PM, Ken Dreyer wrote:
On Fri, Mar 21, 2014 at 6:25 AM, Peter Lemenkov lemenkov@gmail.com wrote:
2014-03-21 16:07 GMT+04:00 Matthew Miller mattdm@fedoraproject.org:
It doesn't exist, it's an idea that Robyn has floated semi-seriously as a way to provide a repo that moves faster than EPEL. Rather than try to jam fast-moving stuff in to EPEL, the idea was to do an Extra Packages for Infrastructure and Cloud (EPIC) that had a different, faster-moving charter. EPIC would target the *EL platform just as EPEL does.
Faster moving rate is great indeed. But adding more than on version of software (no matter of how many repos it takes) means only one - we have to impose additional support requiremetns on a packagers.
The "social contract" requiremens for EPEL "support" (which of souce isn't a "real" support) is way too high for the average maintainer. That's the reason I believe the entire EPEL idea was a huge mistake and waste of time - unfortunately I failed to discuss this with other fellow fedora members during FOSDEM Fedora.NEXT related talks.
I think everyone speaks from their own corner of EPEL and the packages they care about. I know EPEL feels like a mistake and a waste of time to you in the context of your past discussions about the Erlang packages (and maybe you're thinking of others as well). From my own perspective, there are a ton of packages in EPEL that I rely on which are quite stable (for example the Perl ones).
When I imagine a world without EPEL, individual users and sites would still need to address the problems of remediating CVEs, dealing with unstable upstreams, etc., but they wouldn't have the benefit of sharing the infrastructure and testing with other sites.
There are certainly areas for improvement, like any open-source project, but I wanted to share my perspective that I think EPEL still does more good than harm, even in its current form.
- Ken
Seconded. There are problems (<cough>puppet<cough>), but overall it has been a big boon.
On Fri, 21 Mar 2014 16:25:50 +0400 Peter Lemenkov lemenkov@gmail.com wrote:
2014-03-21 16:07 GMT+04:00 Matthew Miller mattdm@fedoraproject.org:
It doesn't exist, it's an idea that Robyn has floated semi-seriously as a way to provide a repo that moves faster than EPEL. Rather than try to jam fast-moving stuff in to EPEL, the idea was to do an Extra Packages for Infrastructure and Cloud (EPIC) that had a different, faster-moving charter. EPIC would target the *EL platform just as EPEL does.
Faster moving rate is great indeed. But adding more than on version of software (no matter of how many repos it takes) means only one - we have to impose additional support requiremetns on a packagers.
The "social contract" requiremens for EPEL "support" (which of souce isn't a "real" support) is way too high for the average maintainer. That's the reason I believe the entire EPEL idea was a huge mistake and waste of time - unfortunately I failed to discuss this with other fellow fedora members during FOSDEM Fedora.NEXT related talks.
I'm sorry you feel that way, but I happen to disagree. I think EPEL has been a very big success and very helpfull for many people.
It can't be everything for everyone... the expectation for it is slow and stable. If you need faster and more updatable, that should be something else (or at least another repo) with different (clear) expectations.
No matter of the current situation I'd love to discuss possible ways to improve it. So count me in as well.
Yeah, I think we can definitely always improve.
kevin
epel-devel@lists.fedoraproject.org
-
Dennis Jacobfeuerborn -
Jim Perrin -
Karsten Wade -
Ken Dreyer -
Kevin Fenzi -
Matthew Miller -
Orion Poplawski -
Peter Lemenkov -
Remi Collet -
Sam Kottler -
Stephen John Smoogen