1:02 p.m.
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-apach...
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.
5:15 p.m.
New subject: EPEL and SCL
On 20 March 2014 12:02, Remi Collet <Fedora(a)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-apach...
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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
--
Stephen J Smoogen.
5:34 p.m.
New subject: EPEL and SCL
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.
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
6:13 p.m.
New subject: EPEL and SCL
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 )
--
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
6:26 p.m.
New subject: EPEL and SCL
On 20 March 2014 17:13, Jim Perrin <jperrin(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
--
Stephen J Smoogen.
7:30 p.m.
New subject: EPEL and SCL
On 20.03.2014 23:15, Stephen John Smoogen wrote:
On 20 March 2014 12:02, Remi Collet <Fedora(a)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-apach...
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
8:35 p.m.
New subject: EPEL and SCL
-----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
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/
iEYEARECAAYFAlMrl2oACgkQ2ZIOBq0ODEH7kQCggq4gnXeYjG5xich1BLbkRwZh
KT4An2qmT0p6XO99pMXuFCeQCgsnj/r7
=X822
-----END PGP SIGNATURE-----
7:07 a.m.
New subject: EPEL EPIC! [was Re: and SCL]
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?
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
7:25 a.m.
New subject: EPEL EPIC! [was Re: and SCL]
2014-03-21 16:07 GMT+04:00 Matthew Miller <mattdm(a)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.
--
With best regards, Peter Lemenkov.
11:49 a.m.
New subject: EPEL EPIC! [was Re: and SCL]
----- Original Message -----
From: "Peter Lemenkov" <lemenkov(a)gmail.com>
To: "EPEL Development List" <epel-devel(a)lists.fedoraproject.org>
Cc: rbergero(a)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(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
5:58 p.m.
New subject: EPEL EPIC! [was Re: and SCL]
On 03/21/2014 11:49 AM, Sam Kottler wrote:
----- Original Message -----
> From: "Peter Lemenkov" <lemenkov(a)gmail.com>
> To: "EPEL Development List" <epel-devel(a)lists.fedoraproject.org>
> Cc: rbergero(a)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(a)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?
--
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
7:43 p.m.
New subject: EPEL EPIC! [was Re: and SCL]
On 21 March 2014 16:58, Jim Perrin <jperrin(a)centos.org> wrote:
On 03/21/2014 11:49 AM, Sam Kottler wrote:
>
>
> ----- Original Message -----
>> From: "Peter Lemenkov" <lemenkov(a)gmail.com>
>> To: "EPEL Development List"
<epel-devel(a)lists.fedoraproject.org>
>> Cc: rbergero(a)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(a)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>>
--
Stephen J Smoogen.
11:41 a.m.
New subject: EPEL EPIC! [was Re: and SCL]
*bump*
On 03/21/2014 07:43 PM, Stephen John Smoogen wrote:
On 21 March 2014 16:58, Jim Perrin <jperrin(a)centos.org> wrote:
>
>
> On 03/21/2014 11:49 AM, Sam Kottler wrote:
>>
>>
>> ----- Original Message -----
>>> From: "Peter Lemenkov" <lemenkov(a)gmail.com>
>>> To: "EPEL Development List"
<epel-devel(a)lists.fedoraproject.org>
>>> Cc: rbergero(a)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(a)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(a)lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/epel-devel
--
Jim Perrin
The CentOS Project | http://www.centos.org
twitter: @BitIntegrity | GPG Key: FA09AD77
5:49 p.m.
New subject: EPEL EPIC! [was Re: and SCL]
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!
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
"Tepid change for the somewhat better!"
1:06 p.m.
New subject: EPEL EPIC! [was Re: and SCL]
On Fri, Mar 21, 2014 at 6:25 AM, Peter Lemenkov <lemenkov(a)gmail.com> wrote:
2014-03-21 16:07 GMT+04:00 Matthew Miller
<mattdm(a)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
5:33 p.m.
New subject: EPEL EPIC! [was Re: and SCL]
On 03/21/2014 12:06 PM, Ken Dreyer wrote:
On Fri, Mar 21, 2014 at 6:25 AM, Peter Lemenkov
<lemenkov(a)gmail.com> wrote:
> 2014-03-21 16:07 GMT+04:00 Matthew Miller <mattdm(a)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.
--
Orion Poplawski
Technical Manager 303-415-9701 x222
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 http://www.nwra.com
11:51 a.m.
New subject: EPEL EPIC! [was Re: and SCL]
On Fri, 21 Mar 2014 16:25:50 +0400
Peter Lemenkov <lemenkov(a)gmail.com> wrote:
2014-03-21 16:07 GMT+04:00 Matthew Miller
<mattdm(a)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
3669
days inactive
3690
days old
epel-devel@lists.fedoraproject.org
16 comments
11 participants
participants (11)
-
Dennis Jacobfeuerborn -
Jim Perrin -
Karsten Wade -
Ken Dreyer -
Kevin Fenzi -
Matthew Miller -
Orion Poplawski -
Peter Lemenkov -
Remi Collet -
Sam Kottler -
Stephen John Smoogen