On 08. 09. 20 17:52, Troy Dawson wrote:
Note1: Not everything has been implemented yet. package.cfg is still
in the epel repos. fedpkg has not been updated. This documentation
will go out when those changes are implemented.
Note2: This is a proposal. It can be changed. If there is something
On Tue, Sep 08, 2020 at 08:52:39AM -0700, Troy Dawson wrote:
> Note1: Not everything has been implemented yet. package.cfg is still
> in the epel repos. fedpkg has not been updated. This documentation
> will go out when those changes are implemented.
>
> Note2: This is a proposal. It can be ch
On Wednesday, September 9, 2020 5:56:43 PM WEST Patrick Riehecky wrote:
> From a mulit-language perspective, I prefer not to use '4' in place of
> the English word 'for'. It makes the translation work a bit wonky.
Not only that, do not forget the meaning/association of 4 in different
cultures. :
On Wed, Sep 09, 2020 at 01:15:29PM -0500, Carl George wrote:
> > So, maintainers would need to be careful to make sure epel8-next or
> > whatever packages are rpm 'newer' at all times to make this work right?
> > Or I guess if they were fixing soname issues like above, dnf might be
> > smart enough
> So, maintainers would need to be careful to make sure epel8-next or
> whatever packages are rpm 'newer' at all times to make this work right?
> Or I guess if they were fixing soname issues like above, dnf might be
> smart enough to pull in the next version anyhow even if it was lower
> than the e
> It's too early to do this now, but I think there's a compelling case
> to be made for shifting EPEL from Fedora to Stream at some point.
One of the biggest benefits to EPEL being in Fedora is the ability to do
fast forward merges from Fedora branches to EPEL branches. Unless CentOS
Stream and F
> I do not like it being part of epel-release, because it is (possibly)
> not compatible with a regular RHEL/CentOS release.
My thinking there is that shipping it as a disabled repository in
epel-release makes it easier to consume in that gap between a RHEL minor
release and the corresponding Cent
Matthew Miller wrote:
> This all leads me to think that actually what we want is not "EPEL Stream"
> but "EPEL for Stream".
That seems to be true.
> (epel-for-stream? epel-4-stream? epel4s? no not that last one for sure.)
Please, no "4"! It looks like a version number.
Björn Persson
pgp5SSPQP
Holy name bikeshedding Batman! To adddress all the naming comments
collectively, I am also of the opinion that "stream" is an overloaded term.
Can you tell someone with a straight face to install a package from a module
stream from the AppStream repo on CentOS Stream? Not to be confused with
the
On Wed, Sep 9, 2020 at 12:59 PM Kevin Fenzi wrote:
>
> I'm a bit confused here... you seem to be conflating epel and this
> epel-stream/epel-next. Do you mean both of them?
Yeah, I'm thinking both. From a high level, I don't see them as being
distinct, just different targets for the same idea. Of
On Wed, Sep 09, 2020 at 12:36:44PM -0400, Ben Cotton wrote:
...snip...
> Warning: heresy and rampant speculation ahead!
> It's too early to do this now, but I think there's a compelling case
> to be made for shifting EPEL from Fedora to Stream at some point. This
> would be dependent on getting a
On Wed, 2020-09-09 at 12:27 -0400, Matthew Miller wrote:
> This all leads me to think that actually what we want is not "EPEL
> Stream" but "EPEL for Stream". (epel-for-stream? epel-4-stream?
> epel4s? no not that last one for sure.)
From a mulit-language perspective, I prefer not to use '4' in pl
On Tue, Sep 08, 2020 at 11:00:42PM -0500, Carl George wrote:
> Howdy folks,
>
> A large part of my day job is working on CentOS Stream. Naturally I would
> like it to be successful and have wide adoption. I know that EPEL will play
> a big role in this success. EPEL is extremely popular. Many
On Wed, Sep 9, 2020 at 10:34 AM Stephen John Smoogen wrote:
>
> I can see two big reasons for not using Stream in the name as the starting
> point of a proposal:
> 1. There is always a complaint that Red Hat related projects jump onto a
> single name to the point of overuse. Atomic, -Shift, -Sta
On Wed, Sep 09, 2020 at 10:25:50AM -0400, Stephen John Smoogen wrote:
> 1. There is always a complaint that Red Hat related projects jump onto a
> single name to the point of overuse. Atomic, -Shift, -Stack, and a couple
> others have been ones in just recent memory. Participants in the various
> c
On Wed, Sep 09, 2020 at 06:30:08AM -0700, Troy Dawson wrote:
> Very good question, one I asked in the meeting.
> If I got the argument right, then the amount of red-tape / legal work
> it would take to call it epel-stream would be much higher than we want
> to pay.
> Many of us didn't like the name
On Wed, 9 Sep 2020 at 09:58, Ken Dreyer wrote:
>
>
> On Wed, Sep 9, 2020, 6:50 AM Petr Pisar wrote:
>
>> On Tue, Sep 08, 2020 at 11:00:42PM -0500, Carl George wrote:
>> > To solve this problem, I am proposing that we create a new repository
>> called
>> > EPEL 8 Next.
>> >
>> > - built against C
On Wed, Sep 9, 2020, 6:50 AM Petr Pisar wrote:
> On Tue, Sep 08, 2020 at 11:00:42PM -0500, Carl George wrote:
> > To solve this problem, I am proposing that we create a new repository
> called
> > EPEL 8 Next.
> >
> > - built against CentOS 8 Stream
> > - opt-in for packagers (must request epel8-
From: Troy Dawson
Sent: Wednesday, September 9, 2020 16:30
To: EPEL Development List
Subject: [EPEL-devel] Re: proposal: EPEL 8 Next
On Wed, Sep 9, 2020 at 5:51 AM Petr Pisar wrote:
>
> On Tue, Sep 08, 2020 at 11:00:42PM -0500, Carl George wrote:
>> I agree with all of that. I only don't like t
On Wed, Sep 9, 2020 at 5:51 AM Petr Pisar wrote:
>
> On Tue, Sep 08, 2020 at 11:00:42PM -0500, Carl George wrote:
> > To solve this problem, I am proposing that we create a new repository called
> > EPEL 8 Next.
> >
> > - built against CentOS 8 Stream
> > - opt-in for packagers (must request epel8
On Tue, Sep 08, 2020 at 11:00:42PM -0500, Carl George wrote:
> To solve this problem, I am proposing that we create a new repository called
> EPEL 8 Next.
>
> - built against CentOS 8 Stream
> - opt-in for packagers (must request epel8-next dist-git branch)
> - opt-in for users (part of epel-relea
21 matches
Mail list logo
