Re: ELN SIG First Meeting

2021-03-15 Thread Kevin Fenzi 
On Mon, Mar 15, 2021 at 09:10:52AM -0400, Stephen John Smoogen wrote:
> On Sun, 14 Mar 2021 at 16:42, Kevin Fenzi  wrote:
> 
> > On Sat, Mar 13, 2021 at 05:09:44PM -0800, Troy Dawson wrote:
> >
> > I'm not sure this is all a super big deal, but I'd really like to make
> > sure we make _very_ clear who is responsible for what. Some maintainers
> > would be happy to maintain for that long cycle (from landing in
> > eln-extra now, to epel 10 next, to epel10... thats what... 13 years?),
> > but some may not, and some might be happy for part of it but not the
> > entire thing.
> >
> >
> I thought we made a change 3-4 years ago. We stopped saying a maintainer
> has to maintain for 10 years. Packages in EPEL are from volunteers and
> volunteers come and go. Volunteers have different ideas of what they want
> to support at different times. In the same way that EPEL has no set of
> packages that is 'EPEL', it also can have no timeline for how long a
> package is going to be in the repository. If a maintainer decides they are
> done, and no one wants to take over the package.. it and everything that
> requires it can go.
> [The reason being that the half-life of a volunteer in Fedora is about 3
> years and we had a lot of dead packages where people thought they were
> being maintained, the maintainer was burnt out and not responding until we
> asked and they said 'they had stopped caring years ago.'.]

Yes, absolutely. I agree that volenteers can and should maintain what
they wish for as long as they wish to do it.

Thats not the part I'm worried about. It's when other groups or people
are maintaining a package. How involved should the Fedora maintainer be?

IMHO they should be as involved as they wish to be, which would range
from: No, I don't want to have anything to do with eln-epel to I
would prefer to maintain it myself. 

But I guess the promise here is just like eln: 
No branches, no changes, Fedora maintainer has control of their rawhide
spec to accept/reject changes to fix eln-epel things?

If ELN sig is willing to do all that more work I suppose we could try
it. Ideally it would be nice to get FMN fixed first, but oh well.

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ELN SIG First Meeting

2021-03-15 Thread Stephen John Smoogen 
On Sun, 14 Mar 2021 at 16:42, Kevin Fenzi  wrote:

> On Sat, Mar 13, 2021 at 05:09:44PM -0800, Troy Dawson wrote:
>
> I'm not sure this is all a super big deal, but I'd really like to make
> sure we make _very_ clear who is responsible for what. Some maintainers
> would be happy to maintain for that long cycle (from landing in
> eln-extra now, to epel 10 next, to epel10... thats what... 13 years?),
> but some may not, and some might be happy for part of it but not the
> entire thing.
>
>
I thought we made a change 3-4 years ago. We stopped saying a maintainer
has to maintain for 10 years. Packages in EPEL are from volunteers and
volunteers come and go. Volunteers have different ideas of what they want
to support at different times. In the same way that EPEL has no set of
packages that is 'EPEL', it also can have no timeline for how long a
package is going to be in the repository. If a maintainer decides they are
done, and no one wants to take over the package.. it and everything that
requires it can go.
[The reason being that the half-life of a volunteer in Fedora is about 3
years and we had a lot of dead packages where people thought they were
being maintained, the maintainer was burnt out and not responding until we
asked and they said 'they had stopped caring years ago.'.]




> Anyhow, I like this proposal much more than early epel10{next}
> branching. :)
>
> kevin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ELN SIG First Meeting

2021-03-14 Thread Kevin Fenzi 
On Sat, Mar 13, 2021 at 05:09:44PM -0800, Troy Dawson wrote:
> 
> Sorry for coming late to the discussion.  I took a week off and all
> sorts of things happened while I was gone.

That fast paced open source development. :) 

> I believe Kevin and Smooge, and possibly even you Davide got this
> backwards.  And I think if we do this right, this can be a thing.
> 
> When we started ELN, one of the major promises was that it wouldn't
> interfere with regular Fedora work.  That your average Fedora packager
> that didn't care about ELN, could continue to not care about ELN and
> nothing would change.
> I believe we (ELN SIG) should extend the same courtesy to EPEL and the
> EPEL community and packagers.

Do note that this isn't really the case currently, although I agree
thats the goal. Due to limitations of our notification system, Fedora
maintainers are getting build notices and such from ELN builds. 
Or course hopefully we can fix that. 

> The email discussion went in the direction of all the work that EPEL
> would need to do to create an ELN EPEL.  But we (ELN SIG) shouldn't
> have expected that.  We should have expected to do all the work.
> 
> So, if we flip this around, where everything is on ELN, how would that work.
> 
> We create a new Fedora target and tag: eln-extra (so people do NOT
> confuse it with real EPEL)
> eln-extra-build inherits from itself and eln-build
> If a package is built against the eln-extra target, and it is
> successful, it gets tagged with the eln-extra tag.
> There is a daily (or some other time period) repo creation.  No
> images, just a repo, like epel.

Could be composed with eln? I think eln composes every 4 hours or
something?

> There is a list of packages, similar to the list of packages used to
> create the ELN list, on some github/gitlab/pagure repo.  If you put a
> package on that list, you associate your name with that package.
> Just like ELN, when a package on the eln-extra list gets built in
> rawhide, it get's built in eln-extra.  In fact, it would be best if we
> just altered the ELN trigger/periodic scripts to look at this list
> along with the regular ELN list.
> 
> What are people's thoughts on this?
> No extra work on EPEL.
> If someone, or some company wants to test ELN and need packages not in
> ELN, they can add the packages to the list, with their name/company
> associated with that package.
> It would get built, put in the repo, and they can then run their ELN
> test with the package they need.
> 
> Thoughts?

My concern is again maintainers/maintainace. 

If there's problems building in eln-extra it either means the Fedora
maintainer(s) have to fix or at least review PR's for rawhide to fix the build
or the eln-extra maintainer(s) have to be co-maintainers or
provenpackagers. 

ok, lets fast forward to when CentOS 10 stream exists. I'm guessing
there's going to be a push to mass branch all the things in eln-extra
for epel10-next? Again, who's maintainer there, the eln-extra maintainer(s),
or the fedora/epel maintainers? 

And then there's when RHEL10 is released, and epel10 can exist. Mass
branch those? who is maintainer? 

I'm not sure this is all a super big deal, but I'd really like to make
sure we make _very_ clear who is responsible for what. Some maintainers
would be happy to maintain for that long cycle (from landing in
eln-extra now, to epel 10 next, to epel10... thats what... 13 years?),
but some may not, and some might be happy for part of it but not the
entire thing. 

Anyhow, I like this proposal much more than early epel10{next}
branching. :) 

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ELN SIG First Meeting

2021-03-14 Thread Davide Cavalca via devel 
On Sat, 2021-03-13 at 17:09 -0800, Troy Dawson wrote:
> Sorry for coming late to the discussion.  I took a week off and all
> sorts of things happened while I was gone.
> 
> I believe Kevin and Smooge, and possibly even you Davide got this
> backwards.  And I think if we do this right, this can be a thing.
> 
> When we started ELN, one of the major promises was that it wouldn't
> interfere with regular Fedora work.  That your average Fedora
> packager
> that didn't care about ELN, could continue to not care about ELN and
> nothing would change.
> I believe we (ELN SIG) should extend the same courtesy to EPEL and
> the
> EPEL community and packagers.
> 
> The email discussion went in the direction of all the work that EPEL
> would need to do to create an ELN EPEL.  But we (ELN SIG) shouldn't
> have expected that.  We should have expected to do all the work.
> 
> So, if we flip this around, where everything is on ELN, how would
> that work.
> 
> We create a new Fedora target and tag: eln-extra (so people do NOT
> confuse it with real EPEL)
> eln-extra-build inherits from itself and eln-build
> If a package is built against the eln-extra target, and it is
> successful, it gets tagged with the eln-extra tag.
> There is a daily (or some other time period) repo creation.  No
> images, just a repo, like epel.
> There is a list of packages, similar to the list of packages used to
> create the ELN list, on some github/gitlab/pagure repo.  If you put a
> package on that list, you associate your name with that package.
> Just like ELN, when a package on the eln-extra list gets built in
> rawhide, it get's built in eln-extra.  In fact, it would be best if
> we
> just altered the ELN trigger/periodic scripts to look at this list
> along with the regular ELN list.
> 
> What are people's thoughts on this?
> No extra work on EPEL.
> If someone, or some company wants to test ELN and need packages not
> in
> ELN, they can add the packages to the list, with their name/company
> associated with that package.
> It would get built, put in the repo, and they can then run their ELN
> test with the package they need.
> 
> Thoughts?

Thanks Troy for taking time to put this together. I like this plan: it
solves my usecase and it doesn't put undue burden onto EPEL or the
individual packagers, while also leaving open the possibility of
leveraging eln-extra to seed the next EPEL release if a packager so
desires.

How would be manage in practice the maintainership of packages in eln-
extra? Would it be recorded in dist-git (coupled with the relevant ACLs
to allow pushing fixes if needed), or somewhere else?

Cheers
Davide
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ELN SIG First Meeting

2021-03-14 Thread James Cassell 


On Sat, Mar 13, 2021, at 8:09 PM, Troy Dawson wrote:
> On Mon, Mar 1, 2021 at 11:49 AM Davide Cavalca via devel
>  wrote:
> >
> > On Mon, 2021-03-01 at 09:26 -0500, Stephen Gallagher wrote:
> > > I'd like to encourage anyone interested in this meeting to submit
> > > agenda topics by replying to this email. Currently the agenda
> >
> > One thing I'd be interested in exploring is the feasibility of
> > extending ELN to cover EPEL as well. This would make it easier to keep
> > EPEL consistent between major releases (as packages would get branched
> > automatically). It would also make it possible to test the combined ELN
> > + EPEL snapshot and find potential issues early on in the process.
> >
> 
> Sorry for coming late to the discussion.  I took a week off and all
> sorts of things happened while I was gone.
> 
> I believe Kevin and Smooge, and possibly even you Davide got this
> backwards.  And I think if we do this right, this can be a thing.
> 
> When we started ELN, one of the major promises was that it wouldn't
> interfere with regular Fedora work.  That your average Fedora packager
> that didn't care about ELN, could continue to not care about ELN and
> nothing would change.
> I believe we (ELN SIG) should extend the same courtesy to EPEL and the
> EPEL community and packagers.
> 
> The email discussion went in the direction of all the work that EPEL
> would need to do to create an ELN EPEL.  But we (ELN SIG) shouldn't
> have expected that.  We should have expected to do all the work.
> 
> So, if we flip this around, where everything is on ELN, how would that work.
> 
> We create a new Fedora target and tag: eln-extra (so people do NOT
> confuse it with real EPEL)
> eln-extra-build inherits from itself and eln-build
> If a package is built against the eln-extra target, and it is
> successful, it gets tagged with the eln-extra tag.
> There is a daily (or some other time period) repo creation.  No
> images, just a repo, like epel.
> There is a list of packages, similar to the list of packages used to
> create the ELN list, on some github/gitlab/pagure repo.  If you put a
> package on that list, you associate your name with that package.
> Just like ELN, when a package on the eln-extra list gets built in
> rawhide, it get's built in eln-extra.  In fact, it would be best if we
> just altered the ELN trigger/periodic scripts to look at this list
> along with the regular ELN list.
> 
> What are people's thoughts on this?
> No extra work on EPEL.
> If someone, or some company wants to test ELN and need packages not in
> ELN, they can add the packages to the list, with their name/company
> associated with that package.
> It would get built, put in the repo, and they can then run their ELN
> test with the package they need.
> 

This is exactly how it should be done! Otherwise, have a list of packages to 
exclude and include everything else.

V/r,
James Cassell
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ELN SIG First Meeting

2021-03-13 Thread Troy Dawson 
On Mon, Mar 1, 2021 at 11:49 AM Davide Cavalca via devel
 wrote:
>
> On Mon, 2021-03-01 at 09:26 -0500, Stephen Gallagher wrote:
> > I'd like to encourage anyone interested in this meeting to submit
> > agenda topics by replying to this email. Currently the agenda
>
> One thing I'd be interested in exploring is the feasibility of
> extending ELN to cover EPEL as well. This would make it easier to keep
> EPEL consistent between major releases (as packages would get branched
> automatically). It would also make it possible to test the combined ELN
> + EPEL snapshot and find potential issues early on in the process.
>

Sorry for coming late to the discussion.  I took a week off and all
sorts of things happened while I was gone.

I believe Kevin and Smooge, and possibly even you Davide got this
backwards.  And I think if we do this right, this can be a thing.

When we started ELN, one of the major promises was that it wouldn't
interfere with regular Fedora work.  That your average Fedora packager
that didn't care about ELN, could continue to not care about ELN and
nothing would change.
I believe we (ELN SIG) should extend the same courtesy to EPEL and the
EPEL community and packagers.

The email discussion went in the direction of all the work that EPEL
would need to do to create an ELN EPEL.  But we (ELN SIG) shouldn't
have expected that.  We should have expected to do all the work.

So, if we flip this around, where everything is on ELN, how would that work.

We create a new Fedora target and tag: eln-extra (so people do NOT
confuse it with real EPEL)
eln-extra-build inherits from itself and eln-build
If a package is built against the eln-extra target, and it is
successful, it gets tagged with the eln-extra tag.
There is a daily (or some other time period) repo creation.  No
images, just a repo, like epel.
There is a list of packages, similar to the list of packages used to
create the ELN list, on some github/gitlab/pagure repo.  If you put a
package on that list, you associate your name with that package.
Just like ELN, when a package on the eln-extra list gets built in
rawhide, it get's built in eln-extra.  In fact, it would be best if we
just altered the ELN trigger/periodic scripts to look at this list
along with the regular ELN list.

What are people's thoughts on this?
No extra work on EPEL.
If someone, or some company wants to test ELN and need packages not in
ELN, they can add the packages to the list, with their name/company
associated with that package.
It would get built, put in the repo, and they can then run their ELN
test with the package they need.

Thoughts?
Troy
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ELN SIG First Meeting

2021-03-12 Thread Stephen Gallagher 
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

=
#fedora-meeting: ELN (2021-03-12)
=


Meeting started by sgallagh at 17:07:34 UTC. The full logs are available
at
https://meetbot.fedoraproject.org/fedora-meeting/2021-03-12/eln.2021-03-12-17.07.log.html
.



Meeting summary
- ---
* Welcome to the inaugural meeting of the ELN Special Interest Group!
  (sgallagh, 17:07:35)
* Init Process  (sgallagh, 17:07:35)

* Populate the initial SIG membership  (sgallagh, 17:08:56)
  * tstellard is also a member of the SIG, though he cannot be in
attendance today  (sgallagh, 17:09:52)

* Agenda  (sgallagh, 17:10:31)
  * Agenda Item: Membership Rules  (sgallagh, 17:10:52)
  * Agenda Item: Future Meeting Plans  (sgallagh, 17:11:04)
  * Agenda Item: Identify a Documentation Czar  (sgallagh, 17:11:22)
  * Agenda Item: Relationship of ELN and EPEL  (sgallagh, 17:11:41)
  * Agenda Item: ELN mirroring and distribution  (sgallagh, 17:12:35)

* Membership Rules  (sgallagh, 17:13:31)
  * Proposal: Anyone may join the SIG by asking to become a member. If
no existing SIG member *opposes* that request within a week, they're
in. If an existing SIG member opposes, we hold a regular vote at the
next scheduled meeting as described above.  (sgallagh, 17:15:14)
  * AGREED: Anyone may join the SIG by asking to become a member. If no
existing SIG member *opposes* that request within a week, they're
in. If an existing SIG member opposes, we hold a regular vote at the
next scheduled meeting as described above. (+7, 0, -0)  (sgallagh,
17:17:51)
  * The first vote of the ELN SIG involved unanimous consent. This is a
good beginning!  (sgallagh, 17:18:16)

* Future Meeting Plans  (sgallagh, 17:26:03)
  * Proposal: ELN SIG Meeting will be held biweekly on Fridays at noon
Eastern Time  (sgallagh, 17:31:56)
  * AGREED: ELN SIG Meeting will be held biweekly on Fridays at noon
Eastern Time (+7, 0, -0)  (sgallagh, 17:32:10)

* Landing Page, Documentation and Ownership Thereof  (sgallagh,
  17:33:31)
  * LINK: https://docs.fedoraproject.org/en-US/eln/   (bookwar,
17:34:22)
  * Meetings are scheduled for one hour  (sgallagh, 17:34:32)
  * LINK: https://github.com/fedora-eln/   (sgallagh, 17:35:11)
  * LINK: https://github.com/fedora-eln/eln is specifically the issue
tracker. I propose using tags there to establish the agenda.
(sgallagh, 17:35:35)
  * Proposal: ELN SIG will continue to use
https://github.com/fedora-eln/eln for issue tracking and agenda
tagging.  (sgallagh, 17:38:25)
  * Proposal: ELN SIG will continue to use
https://github.com/fedora-eln/eln for issue tracking and agenda
tagging. SIG members will be added to the Github organization.
(sgallagh, 17:40:38)
  * AGREED: ELN SIG will continue to use
https://github.com/fedora-eln/eln for issue tracking and agenda
tagging. SIG members will be added to the Github organization. (+7,
0, -0)  (sgallagh, 17:41:55)
  * Proposal: The ELN SIG landing page will continue to be at
https://docs.fedoraproject.org/en-US/eln/.  (sgallagh, 17:43:35)
  * AGREED: The ELN SIG landing page will continue to be at
https://docs.fedoraproject.org/en-US/eln/ (+7, 0, -0)  (sgallagh,
17:45:48)
  * The sources to that page are located at
https://github.com/fedora-eln/eln-docs  (sgallagh, 17:45:48)

* Relationship between ELN and EPEL  (sgallagh, 17:55:55)
  * ACTION: dcavalca to create a first-pass at a starter set of EPELN
packages.  (sgallagh, 18:18:14)
  * ACTION: Everyone on the SIG to email sgallagh their Github IDs over
the next few days.  (sgallagh, 18:25:34)
  * ACTION: sgallagh will update the landing page and github org with
the new members  (sgallagh, 18:25:48)

Meeting ended at 18:27:32 UTC.




Action Items
- 
* dcavalca to create a first-pass at a starter set of EPELN packages.
* Everyone on the SIG to email sgallagh their Github IDs over the next
  few days.
* sgallagh will update the landing page and github org with the new
  members




Action Items, by person
- ---
* dcavalca
  * dcavalca to create a first-pass at a starter set of EPELN packages.
* sgallagh
  * Everyone on the SIG to email sgallagh their Github IDs over the next
few days.
  * sgallagh will update the landing page and github org with the new
members
* **UNASSIGNED**
  * (none)




People Present (lines said)
- ---
* sgallagh (146)
* Eighth_Doctor (72)
* bookwar (56)
* dcavalca (40)
* michel_slm (30)
* zodbot (22)
* cyberpear (14)
* jforbes (13)
* carlwgeorge (3)
* Conan_Kudo (1)
* Southern_Gentlem (1)




Generated by `MeetBot`_ 0.1.4

.. _`MeetBot`: http://wiki.debian.org/MeetBot
-BEGIN PGP SIGNATURE-

iQGzBAEBCAAdFiEEhQqd0dvyrMxvxJSRRduFpWgobREFAmBLstcACgkQRduFpWgo
bREvjwwAniiuQ3PCNL554+98pa/88y4tvyZcZNAEUvb+7G7dgsr4z8CjkUnkjdF7
rcegGDl0xI6QHZaRcpP5nZuV9BsopwI2sDKc04sQtIVrcnHIEIw

Re: getting EPEL 9 started [was Re: ELN SIG First Meeting]

2021-03-05 Thread Kevin Fenzi 
On Thu, Mar 04, 2021 at 02:31:14PM -0800, Michel Alexandre Salim wrote:
> Sorry for jumping in late, I'm sporadically online while on parental
> leave (haven't been able to touch my laptop for the past few days!)

No need to be sorry. :) Congrats!

> Mass-branching does seem too different from what we currently do (EPEL
> branches are opt-in for a package); building in COPR sounds more
> workable (Miro does mass-rebuilds of Python packages to test for
> compatibility with upcoming Python releases that way).
> 
> Selecting which packages to build is tricky though - we wouldn't
> necessarily want to mass build packages that will never be packaged in
> EPEL, as that will just be wasted cycles.
> 
> And we have packages that are in EPEL for various reasons:
> - the package itself is useful to end users (e.g. tools as Matthew
> mentioned, but also libraries that might be dependencies for some
> software that is itself not in EL/EPEL
> - the package is a dependency of a package that is useful
>   -> in this case, automatically branching might not be a good idea
>   if e.g. this is a parallel installable new version of a library
>   already in EL, and for ELN said library is not needed
> 
> How about this approach, though?
> - create epel(N+1) (and epel(N+1)-next, now that we're doing Stream
> first) as soon as ELN starts targeting EL (N+1) - so in this case, we
> want to create epel10 / epel10-next now
> - if said branch exists for a package:
>   - if a spec is found, use it for building against ELN
>   - if a spec is not found, build the Rawhide branch against ELN

What makes the list of packages there?
Everything in epel8? Everything in fedora?

The build ordering there would be difficult to know and definitely
require people work. 

> Maintainers interested in EPEL can thus get early notification as to if
> they need to make any change (or if they need to chase missing
> dependencies and get those branched)
> 
> This will tie in nicely with what the EPEL Packagers SIG is working on
> - we want to have the SIG eventually be added as collaborators (on
> epel* branches) to packages where we identify a need for EL use, but
> where the primary maintainer is not interested: having the branch
> available earlier will reduce the need to scramble at the last minute
> to chase packages' dependencies.

Well, perhaps. But also it means they have to maintain another branch
(epel10) for like 3 or so more years, no? Deps in eln will change,
things will be added, etc. I think avoiding a last minue scramble might
be nice, but making it a 3 extra years of maint is... a bit much. 

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: getting EPEL 9 started [was Re: ELN SIG First Meeting]

2021-03-04 Thread Matthew Miller 
On Fri, Mar 05, 2021 at 12:55:44AM +0100, Kevin Kofler via devel wrote:
> That would be more or less what Ubuntu universe is doing: branch every 
> package in Fedora, build it once for EPEL, and then just let it rot unless a 
> maintainer volunteers to actually maintain it. It might be better than not 
> having the packages at all, but it also means that there would no longer be 
> any guarantee that a package in EPEL actually works and that bugs and 
> security issues ever get fixed.

Oh, to be clear, I do think about it when I update the package for Fedora
Linux. I just generally don't do an EPEL update for small bugfixes -- or for
big feature changes unless someone requests. If there is a security update,
I do it.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: getting EPEL 9 started [was Re: ELN SIG First Meeting]

2021-03-04 Thread Kevin Kofler via devel 
Matthew Miller wrote:
> I have a couple of packages which I find handy to have in EPEL -- little
> command line utilities, mostly -- and which have very little change over
> time and which I'm 99.9% will just build on EPEL 9. My EPEL maintenance
> policy is basically "build once when there is a new EPEL, plus also in the
> rare chance of an update which seems significant, or if someone asks".
> 
> So for me, having these automatically branched and auto-built (once)
> whenever there's a new EPEL would be ideal.

That would be more or less what Ubuntu universe is doing: branch every 
package in Fedora, build it once for EPEL, and then just let it rot unless a 
maintainer volunteers to actually maintain it. It might be better than not 
having the packages at all, but it also means that there would no longer be 
any guarantee that a package in EPEL actually works and that bugs and 
security issues ever get fixed.

Kevin Kofler
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: getting EPEL 9 started [was Re: ELN SIG First Meeting]

2021-03-04 Thread Michel Alexandre Salim 
On Thu, 2021-03-04 at 16:24 -0500, Matthew Miller wrote:
> On Thu, Mar 04, 2021 at 01:11:55PM -0800, Kevin Fenzi wrote:
> > In any case, I'm not convinced mass branching is ever going to work
> > for
> > epel. Although I suppose as more packages have the epel packager
> > sig
> > group on them, that group could work on faster adding piles of
> > packages. 
> > Perhaps we should try and identify all the 'please branch for epel'
> > requests in bugzilla and have some way for the epel packager sig to
> > step
> > in and get those added?
> 
> I have a couple of packages which I find handy to have in EPEL --
> little
> command line utilities, mostly -- and which have very little change
> over
> time and which I'm 99.9% will just build on EPEL 9. My EPEL
> maintenance
> policy is basically "build once when there is a new EPEL, plus also
> in the
> rare chance of an update which seems significant, or if someone
> asks".
> 
> 
> So for me, having these automatically branched and auto-built (once)
> whenever there's a new EPEL would be ideal.
> 
Sorry for jumping in late, I'm sporadically online while on parental
leave (haven't been able to touch my laptop for the past few days!)

Mass-branching does seem too different from what we currently do (EPEL
branches are opt-in for a package); building in COPR sounds more
workable (Miro does mass-rebuilds of Python packages to test for
compatibility with upcoming Python releases that way).

Selecting which packages to build is tricky though - we wouldn't
necessarily want to mass build packages that will never be packaged in
EPEL, as that will just be wasted cycles.

And we have packages that are in EPEL for various reasons:
- the package itself is useful to end users (e.g. tools as Matthew
mentioned, but also libraries that might be dependencies for some
software that is itself not in EL/EPEL
- the package is a dependency of a package that is useful
  -> in this case, automatically branching might not be a good idea
  if e.g. this is a parallel installable new version of a library
  already in EL, and for ELN said library is not needed

How about this approach, though?
- create epel(N+1) (and epel(N+1)-next, now that we're doing Stream
first) as soon as ELN starts targeting EL (N+1) - so in this case, we
want to create epel10 / epel10-next now
- if said branch exists for a package:
  - if a spec is found, use it for building against ELN
  - if a spec is not found, build the Rawhide branch against ELN

Maintainers interested in EPEL can thus get early notification as to if
they need to make any change (or if they need to chase missing
dependencies and get those branched)

This will tie in nicely with what the EPEL Packagers SIG is working on
- we want to have the SIG eventually be added as collaborators (on
epel* branches) to packages where we identify a need for EL use, but
where the primary maintainer is not interested: having the branch
available earlier will reduce the need to scramble at the last minute
to chase packages' dependencies.

Best regards,

-- 
Michel Alexandre Salim
profile: https://keyoxide.org/mic...@michel-slm.name


signature.asc
Description: This is a digitally signed message part
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ELN SIG First Meeting

2021-03-04 Thread Stephen John Smoogen 
On Thu, 4 Mar 2021 at 16:21, Kevin Fenzi  wrote:

> On Thu, Mar 04, 2021 at 06:56:24AM -0500, Stephen John Smoogen wrote:
> > I think we are all using different short hand definitions of what we want
> > to happen and are seeing each other skip steps because of that. I am very
> > guilty of this when saying what could happen in this scenario. The
> > following is more detailed but still skips steps
> >
> > 1. Get a list of all packages which are branched for past EPEL releases.
> > 2. Get a list of all 'active' packages in the latest Fedora active
> release
> > (aka F33 if I were doing this today) versus prerelease where packages may
> > still get orphaned dropped before final.
> > 3. Compare the lists and filter out the ones remaining
>
> So this list would be the overlap of 'was in past EPEL' and 'is in
> current Fedora'? But that still doesn't cover all the cases. Take
> 'Terminal' (The Xfce terminal back in the day). It finally got renamed
> 'xfce4-terminal' upstream. This wouldn't show up in these lists. It
> would take someone who knew that it was renamed/replaced to add it, no?
>
>
I think you kind of ate what was my context for writing all this which was
Petr's going from a shorter list and thinking that the forks would need to
be from the already EL8 packages. It would actually need to be a much
larger list and I wanted to cover all the steps I could think of to see
what would be needed. [Whether or not mass-branching makes sense.]



> > 4. Fork all those packages to a 'project' space so we don't pollute
> > mainline.
> > 5. Use a script on all the spec files to see what buildrequires/requires
> > are needed on those packages.
> > 6. Compare to existing pool of packages in ELN+already forked packages
> > 7. Add forks of all the extra packages.
> > 8. I would then probably rebuild all these in Copr or private system to
> get
> > build order and find yet more 'missing' packages.
> > 9. Put in fixes to spec files into the forks to make it work.
> > 10. Put in a list for packages to be branched for 'ELN'
> > 11. Keep up with 'active' package so your fork work is kept in line.
> > 12. Do proper branch requests for the packages for 'ELN'
> > 13. Merge Request Madness time
> > 14. Start building in the real build system and find/fix problems missed
> in
> > COPR private builds.
> > 15. ...
> > 16. Profit
>
> You are describing... package maintainers. :)
>
> In any case, I'm not convinced mass branching is ever going to work for
> epel. Although I suppose as more packages have the epel packager sig
>

After looking at the steps above, I agree. There are already too few active
maintainers in Fedora who are having to handle way too many packages just
for rawhide, F-N+1, F-N, and F-N-1. Adding in a burden of
reports/messages/failed-builds to active maintainers for branches they
don't care about will likely make the number of active maintainers 'less'.



> group on them, that group could work on faster adding piles of packages.
> Perhaps we should try and identify all the 'please branch for epel'
> requests in bugzilla and have some way for the epel packager sig to step
> in and get those added?
>
> kevin
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

getting EPEL 9 started [was Re: ELN SIG First Meeting]

2021-03-04 Thread Matthew Miller 
On Thu, Mar 04, 2021 at 01:11:55PM -0800, Kevin Fenzi wrote:
> In any case, I'm not convinced mass branching is ever going to work for
> epel. Although I suppose as more packages have the epel packager sig
> group on them, that group could work on faster adding piles of packages. 
> Perhaps we should try and identify all the 'please branch for epel'
> requests in bugzilla and have some way for the epel packager sig to step
> in and get those added?

I have a couple of packages which I find handy to have in EPEL -- little
command line utilities, mostly -- and which have very little change over
time and which I'm 99.9% will just build on EPEL 9. My EPEL maintenance
policy is basically "build once when there is a new EPEL, plus also in the
rare chance of an update which seems significant, or if someone asks".


So for me, having these automatically branched and auto-built (once)
whenever there's a new EPEL would be ideal.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ELN SIG First Meeting

2021-03-04 Thread Kevin Fenzi 
On Thu, Mar 04, 2021 at 06:56:24AM -0500, Stephen John Smoogen wrote:
> I think we are all using different short hand definitions of what we want
> to happen and are seeing each other skip steps because of that. I am very
> guilty of this when saying what could happen in this scenario. The
> following is more detailed but still skips steps
> 
> 1. Get a list of all packages which are branched for past EPEL releases.
> 2. Get a list of all 'active' packages in the latest Fedora active release
> (aka F33 if I were doing this today) versus prerelease where packages may
> still get orphaned dropped before final.
> 3. Compare the lists and filter out the ones remaining

So this list would be the overlap of 'was in past EPEL' and 'is in
current Fedora'? But that still doesn't cover all the cases. Take
'Terminal' (The Xfce terminal back in the day). It finally got renamed
'xfce4-terminal' upstream. This wouldn't show up in these lists. It
would take someone who knew that it was renamed/replaced to add it, no?

> 4. Fork all those packages to a 'project' space so we don't pollute
> mainline.
> 5. Use a script on all the spec files to see what buildrequires/requires
> are needed on those packages.
> 6. Compare to existing pool of packages in ELN+already forked packages
> 7. Add forks of all the extra packages.
> 8. I would then probably rebuild all these in Copr or private system to get
> build order and find yet more 'missing' packages.
> 9. Put in fixes to spec files into the forks to make it work.
> 10. Put in a list for packages to be branched for 'ELN'
> 11. Keep up with 'active' package so your fork work is kept in line.
> 12. Do proper branch requests for the packages for 'ELN'
> 13. Merge Request Madness time
> 14. Start building in the real build system and find/fix problems missed in
> COPR private builds.
> 15. ...
> 16. Profit

You are describing... package maintainers. :)

In any case, I'm not convinced mass branching is ever going to work for
epel. Although I suppose as more packages have the epel packager sig
group on them, that group could work on faster adding piles of packages. 
Perhaps we should try and identify all the 'please branch for epel'
requests in bugzilla and have some way for the epel packager sig to step
in and get those added?

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ELN SIG First Meeting

2021-03-04 Thread Davide Cavalca via devel 
On Tue, 2021-03-02 at 08:38 -0500, Stephen John Smoogen wrote:
> So mainly a package maintainer only worries about what is deployed at
> their workplace. And I would guess from the size of unanswered bugs
> and other things, some of these maintainers did a one-time build to
> get what they wanted and went onto other things. Others would update
> things until it could no longer build with older RHEL-6 or 7 code and
> stop maintaining it.  This is where i get most of my answers..
> someone asks 'why is it not in EL-?' and I go ask the maintainers.
> Usually the Fedora maintainer is like 'I don't use EL and don't want
> to unless paid to' and then I find on the list of co-maintainers who
> might be an EPEL maintainer. This usually gets the answer of 'look we
> are a EL-6 or EL-7 shop and I can only really do it for that. Can you
> find someone else?' Then someone eventually volunteers, we find out
> they aren't a packager and have to go look again. Eventually we get
> someone who is a packager who gets added to the packaging list for
> that package and takes over that branch.
> 
> Since EPEL was not really a major thing the Fedora maintainers or the
> base community have wanted to invest in, there has been no drive to
> do more book-keeping than what is needed to keep the system going. We
> could track EPEL/non-EPEL maintainers in the package database system
> and now we can track some level of control in pagure I believe but it
> has been pretty much 'is it there? good.'

Thanks for the clarification, this is helpful. I think if we could
better track who maintains which release that would definitely help
down the road, both for this effort and in general. Another thing to
consider is allowing maintainers to say "I don't care about EPEL"
outright, and then streamlining the process of branching those packages
for EPEL if someone interested does show up (e.g. via the EPEL
Packagers SIG).

> up to 8  full time people for basic packaging, builds, dealing with
> bugs, etc. [This is going on a decision that packages being
> 'maintained' are only at 'it built, ship it' quality. If we need
> higher levels then you will need more staff.]
> 4 people to do documentation, upkeep and other management duties of
> keeping things on track
> 4 people to work through QA items and actually figure out tests
> relevant to EPEL.
> 6-8 people to design and work with the koji upstream to fix the
> fedora build system to work with two different modularities.
> Currently MBS can only build a limited type of modules which is what
> is breaking PHP and I think perl apps. 

Are these MBS limitations documented somewhere? I'm not terribly
familiar with this part of the infra (nor with modularity in general).

> The work plan would be that most of the first 6-8 months would be
> that last group working on getting a build system which works for
> EPEL. Because EPEL uses a koji 'hack' to get to the RHEL binaries it
> does not 'know' really what those packages are in the same way it
> does for packages it built itself. The same goes with MBS. This means
> that you have to come up with a way to fool them into using the
> proper modules when they are needed etc. HOWEVER you also have to not
> break the Fedora build system at the same time so that fedora
> packages can continue to build. At the middle of the initial period
> it would be either done or found to be outside of easily possible and
> some other system would be needed. At that point it is either finish
> it up or build a new system.
> 
> The package branching/building/qa can go on for a subset of packages
> but some will be impossible because of the modularity problem. 
> 
> After either of the systems are in place, a planning period goes into
> place on how to build out modules and for what. There are some things
> which make sense (PHP, python, ruby) and then there are specific
> complicated apps which make sense. However there need to be
> consistent rules, documentation on how to do it, and training to make
> them. Also a consistent testing process would need to be done.
> 
> By the time this is done then it will be time to work on the next set
> of EL branching
> 
> [I had an older proposal which went over the above but undercut the
> number of people needed.. when we tried this with EPEL-8 it was
> overwhelming at 1/2 the staff numbers so I am hoping I am getting
> this right at this level.]

Ok, this would definitely be a major effort, both in terms of manpower
and of disruption to the infrastructure. It seems unfeasible to go down
this road without resourcing and wide buy-in that this is the way to
go.

> I do see the need for this, but I really think this might be the
> straw which broke the camel's back. ELN is already getting a lot of
> pushback because the tools send regular failure notices to
> maintainers who have nothing to do with ELN. Adding in 10,000 more
> packages would basically push a lot of maintainers past the breaking
> point. There is also the fact that ELN-E

Re: ELN SIG First Meeting

2021-03-04 Thread Davide Cavalca via devel 
On Thu, 2021-03-04 at 08:54 +0100, Petr Pisar wrote:
> V Wed, Mar 03, 2021 at 09:46:52AM -0800, Kevin Fenzi napsal(a):
> > All that said, we could change this and just mass branch everything
> > and
> > leave it to maintainers to clean up/dead.package/retire things they
> > no
> > longer wish to maintain. That pushes more work on them tho (as well
> > as
> > more releng work to mass branch, build everything, etc). 
> > 
> It would be great to notify EPEL maintainers that there is a new EPEL
> 9 and
> that they could try packaging previous EPEL 8 packages for EPEL 9.
> Either as
> an e-mail message or a bug in Bugzilla.
> 
> But branching EPEL 9 from EPEL 8 is not helpful. At least for me as
> a packager. The reason is, as Kevin wrote, that you want to base EPEL
> 9 on
> the latest (or very recent) Fedora sources. In my opinion the
> maintainers
> would end up with merging rahide to epel9 branch overrideding all
> epel8
> commits with the risk of creaping unwanted epel8 tweaks there. I
> ground this
> claim on the fact the RHEL 9 is based on Fedora 34 where you have
> different
> packaging standards and package set than in RHEL 8.

Yeah, if we were to mass branch, I think that branching from Rawhide
would be more useful than branching from the previous EPEL.

Davide
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ELN SIG First Meeting

2021-03-04 Thread Stephen John Smoogen 
On Thu, 4 Mar 2021 at 03:01, Petr Pisar  wrote:

> V Wed, Mar 03, 2021 at 09:46:52AM -0800, Kevin Fenzi napsal(a):
> > On Tue, Mar 02, 2021 at 01:04:56AM +, Davide Cavalca via devel wrote:
> > > Yes, the idea I had in mind was that each package that currenty has an
> > > "epel8" branch would also get an "epeln" branch that would be built
> > > against ELN. Then when ELN branches into CentOS Stream, the epeln
> > > branches could be used as the starting point for the corresponding EPEL
> > > release.
> >
> > So, the problem here is that it doesn't map to well to the rhel
> > timeframes. In Fedora, you just keep maintaining a package until you
> > need to retire/replace/rename it. In EPEL, there's 3 years between major
> > versions. A lot can happen in 3 years. For example, epel7 has Xfce 4.12
> > in it, epel8 has Xfce 4.14, Fedora has Xfce 4.16. In each of those, some
> > components changed. There's some 4.12 packages that were dropped
> > entirely by 4.14, sometimes there's new ones. I wouldn't want to
> > maintain 4.14 in epel9, I would want it to be the latest one.
> >
> > All that said, we could change this and just mass branch everything and
> > leave it to maintainers to clean up/dead.package/retire things they no
> > longer wish to maintain. That pushes more work on them tho (as well as
> > more releng work to mass branch, build everything, etc).
> >
> It would be great to notify EPEL maintainers that there is a new EPEL 9 and
> that they could try packaging previous EPEL 8 packages for EPEL 9. Either
> as
> an e-mail message or a bug in Bugzilla.
>
> But branching EPEL 9 from EPEL 8 is not helpful. At least for me as
> a packager. The reason is, as Kevin wrote, that you want to base EPEL 9 on
> the latest (or very recent) Fedora sources. In my opinion the maintainers
> would end up with merging rahide to epel9 branch overrideding all epel8
> commits with the risk of creaping unwanted epel8 tweaks there. I ground
> this
> claim on the fact the RHEL 9 is based on Fedora 34 where you have different
> packaging standards and package set than in RHEL 8.
>
> If relengs want to decrease a load of dist-git requests for epel9 branch,
> I would go with a compromise: Precreate epel9 branches with only the
> initial
> commit and enabling the package in Koji tag.
>
>
I think we are all using different short hand definitions of what we want
to happen and are seeing each other skip steps because of that. I am very
guilty of this when saying what could happen in this scenario. The
following is more detailed but still skips steps

1. Get a list of all packages which are branched for past EPEL releases.
2. Get a list of all 'active' packages in the latest Fedora active release
(aka F33 if I were doing this today) versus prerelease where packages may
still get orphaned dropped before final.
3. Compare the lists and filter out the ones remaining
4. Fork all those packages to a 'project' space so we don't pollute
mainline.
5. Use a script on all the spec files to see what buildrequires/requires
are needed on those packages.
6. Compare to existing pool of packages in ELN+already forked packages
7. Add forks of all the extra packages.
8. I would then probably rebuild all these in Copr or private system to get
build order and find yet more 'missing' packages.
9. Put in fixes to spec files into the forks to make it work.
10. Put in a list for packages to be branched for 'ELN'
11. Keep up with 'active' package so your fork work is kept in line.
12. Do proper branch requests for the packages for 'ELN'
13. Merge Request Madness time
14. Start building in the real build system and find/fix problems missed in
COPR private builds.
15. ...
16. Profit


-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ELN SIG First Meeting

2021-03-03 Thread Petr Pisar 
V Wed, Mar 03, 2021 at 09:46:52AM -0800, Kevin Fenzi napsal(a):
> On Tue, Mar 02, 2021 at 01:04:56AM +, Davide Cavalca via devel wrote:
> > Yes, the idea I had in mind was that each package that currenty has an
> > "epel8" branch would also get an "epeln" branch that would be built
> > against ELN. Then when ELN branches into CentOS Stream, the epeln
> > branches could be used as the starting point for the corresponding EPEL
> > release.
> 
> So, the problem here is that it doesn't map to well to the rhel
> timeframes. In Fedora, you just keep maintaining a package until you
> need to retire/replace/rename it. In EPEL, there's 3 years between major
> versions. A lot can happen in 3 years. For example, epel7 has Xfce 4.12
> in it, epel8 has Xfce 4.14, Fedora has Xfce 4.16. In each of those, some
> components changed. There's some 4.12 packages that were dropped
> entirely by 4.14, sometimes there's new ones. I wouldn't want to
> maintain 4.14 in epel9, I would want it to be the latest one. 
> 
> All that said, we could change this and just mass branch everything and
> leave it to maintainers to clean up/dead.package/retire things they no
> longer wish to maintain. That pushes more work on them tho (as well as
> more releng work to mass branch, build everything, etc). 
> 
It would be great to notify EPEL maintainers that there is a new EPEL 9 and
that they could try packaging previous EPEL 8 packages for EPEL 9. Either as
an e-mail message or a bug in Bugzilla.

But branching EPEL 9 from EPEL 8 is not helpful. At least for me as
a packager. The reason is, as Kevin wrote, that you want to base EPEL 9 on
the latest (or very recent) Fedora sources. In my opinion the maintainers
would end up with merging rahide to epel9 branch overrideding all epel8
commits with the risk of creaping unwanted epel8 tweaks there. I ground this
claim on the fact the RHEL 9 is based on Fedora 34 where you have different
packaging standards and package set than in RHEL 8.

If relengs want to decrease a load of dist-git requests for epel9 branch,
I would go with a compromise: Precreate epel9 branches with only the initial
commit and enabling the package in Koji tag.

-- Petr


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ELN SIG First Meeting

2021-03-03 Thread Kevin Fenzi 
On Tue, Mar 02, 2021 at 01:04:56AM +, Davide Cavalca via devel wrote:
> On Mon, 2021-03-01 at 12:47 -0800, Kevin Fenzi wrote:
> > I'm not sure exactly what you mean here... 
> > 
> > I think (please correct me if I'm wrong) you are wanting "all EPEL
> > packages" to also be built as part of ELN and shipped as some sort of
> > 'EPEL-ELN' ?
> 
> Yes, the idea I had in mind was that each package that currenty has an
> "epel8" branch would also get an "epeln" branch that would be built
> against ELN. Then when ELN branches into CentOS Stream, the epeln
> branches could be used as the starting point for the corresponding EPEL
> release.

So, the problem here is that it doesn't map to well to the rhel
timeframes. In Fedora, you just keep maintaining a package until you
need to retire/replace/rename it. In EPEL, there's 3 years between major
versions. A lot can happen in 3 years. For example, epel7 has Xfce 4.12
in it, epel8 has Xfce 4.14, Fedora has Xfce 4.16. In each of those, some
components changed. There's some 4.12 packages that were dropped
entirely by 4.14, sometimes there's new ones. I wouldn't want to
maintain 4.14 in epel9, I would want it to be the latest one. 

All that said, we could change this and just mass branch everything and
leave it to maintainers to clean up/dead.package/retire things they no
longer wish to maintain. That pushes more work on them tho (as well as
more releng work to mass branch, build everything, etc). 

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ELN SIG First Meeting

2021-03-02 Thread Matthew Miller 
On Tue, Mar 02, 2021 at 01:17:31AM +, Davide Cavalca via devel wrote:
> I should probably expand on why I'm thinking about this in the first
> place. I want to use ELN as a proxy for the next CentOS Stream release
> to streamline its qualification on our infrastructure. The idea being
> that if we can continously test ELN on a small subset of production,
> that will detect potential issues early on, allow us to get ahead of
> policy changes that might require internal work, and hopefully surface
> bugs that we can report and fix upstream long before branch time.

This really does seem like a good idea, and it would be nice to see more
attention and resources for EPEL overall -- it is, after all, one of the
most popular ways to enjoy the efforts of the Fedora community.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ELN SIG First Meeting

2021-03-02 Thread Stephen John Smoogen 
On Mon, 1 Mar 2021 at 20:18, Davide Cavalca via devel <
devel@lists.fedoraproject.org> wrote:

> On Mon, 2021-03-01 at 15:49 -0500, Stephen John Smoogen wrote:
> > That would require a lot of changes in both EPEL and in Fedora. In
> > Fedora there is a general expectation that if a 'branch' is active
> > then it is maintained by someone.. usually the primary maintainer.
> > Many Fedora maintainers are only interested in maintaining packages
> > in the latest release. THis is why the ELN packages are being
> > 'watched/maintained' by the ELN team and sig. Maintainership usually
> > means dealing with bug reports, build failures, etc which can take up
> > a good amount of time.
>
> That's a fair point. To be clear, I would not expect this to happen by
> itself -- it this idea turns out to be feasible, I would be happy to
> pitch in and/or try and find resources to help with this from my end.
>
> > This is part of the reason why EPEL packages are not auto-forked for
> > each EL release. Most maintainers are only interested in supporting
> > maybe EL-6 or EL7 and we need to find someone new to do the EL-8
> > branch.
>
> Interesting, I had not realized this was the case. My (likely naive)
> assumption was that if there's an epelX branch for a given package,
> there would likey be an epelX+1 too, and when that wasn't the case it
> was mostly because the maintainer hasn't gotten around it yet or nobody
> had asked. My assumption was that by providing a readily updated
> "epeln" branch we would save the maintainer some of this work.
>
> Are you saying that for some packages it is expected that the
> maintainer would only care about say epel7 and not epel8? In that case,
> do we / would we track the maintainer for epel8 specifically somewhere,
> if one were to volunteer?
>
>
So mainly a package maintainer only worries about what is deployed at their
workplace. And I would guess from the size of unanswered bugs and other
things, some of these maintainers did a one-time build to get what they
wanted and went onto other things. Others would update things until it
could no longer build with older RHEL-6 or 7 code and stop maintaining it.
This is where i get most of my answers.. someone asks 'why is it not in
EL-?' and I go ask the maintainers. Usually the Fedora maintainer is like
'I don't use EL and don't want to unless paid to' and then I find on the
list of co-maintainers who might be an EPEL maintainer. This usually gets
the answer of 'look we are a EL-6 or EL-7 shop and I can only really do it
for that. Can you find someone else?' Then someone eventually volunteers,
we find out they aren't a packager and have to go look again. Eventually we
get someone who is a packager who gets added to the packaging list for that
package and takes over that branch.

Since EPEL was not really a major thing the Fedora maintainers or the base
community have wanted to invest in, there has been no drive to do more
book-keeping than what is needed to keep the system going. We could track
EPEL/non-EPEL maintainers in the package database system and now we can
track some level of control in pagure I believe but it has been pretty much
'is it there? good.'


> We would need to have a dedicated team of people to do this with ELN
> > related items. We would also need to have additional build and
> > storage resources to deal with these artifacts, not alone the growth
> > of 'just need this' packages.
>
> Is there an easy way to ballpark estimate the resource demand that an
> effort like this would require?
>
>
up to 8  full time people for basic packaging, builds, dealing with bugs,
etc. [This is going on a decision that packages being 'maintained' are only
at 'it built, ship it' quality. If we need higher levels then you will need
more staff.]
4 people to do documentation, upkeep and other management duties of keeping
things on track
4 people to work through QA items and actually figure out tests relevant to
EPEL.
6-8 people to design and work with the koji upstream to fix the fedora
build system to work with two different modularities. Currently MBS can
only build a limited type of modules which is what is breaking PHP and I
think perl apps.

The work plan would be that most of the first 6-8 months would be that last
group working on getting a build system which works for EPEL. Because EPEL
uses a koji 'hack' to get to the RHEL binaries it does not 'know' really
what those packages are in the same way it does for packages it built
itself. The same goes with MBS. This means that you have to come up with a
way to fool them into using the proper modules when they are needed etc.
HOWEVER you also have to not break the Fedora build system at the same time
so that fedora packages can continue to build. At the middle of the initial
period it would be either done or found to be outside of easily possible
and some other system would be needed. At that point it is either finish it
up or build a new system.

The package branching/building/qa can g

Re: ELN SIG First Meeting

2021-03-01 Thread Davide Cavalca via devel 
On Mon, 2021-03-01 at 15:49 -0500, Stephen John Smoogen wrote:
> That would require a lot of changes in both EPEL and in Fedora. In
> Fedora there is a general expectation that if a 'branch' is active
> then it is maintained by someone.. usually the primary maintainer. 
> Many Fedora maintainers are only interested in maintaining packages
> in the latest release. THis is why the ELN packages are being
> 'watched/maintained' by the ELN team and sig. Maintainership usually
> means dealing with bug reports, build failures, etc which can take up
> a good amount of time.

That's a fair point. To be clear, I would not expect this to happen by
itself -- it this idea turns out to be feasible, I would be happy to
pitch in and/or try and find resources to help with this from my end.

> This is part of the reason why EPEL packages are not auto-forked for
> each EL release. Most maintainers are only interested in supporting
> maybe EL-6 or EL7 and we need to find someone new to do the EL-8
> branch.

Interesting, I had not realized this was the case. My (likely naive)
assumption was that if there's an epelX branch for a given package,
there would likey be an epelX+1 too, and when that wasn't the case it
was mostly because the maintainer hasn't gotten around it yet or nobody
had asked. My assumption was that by providing a readily updated
"epeln" branch we would save the maintainer some of this work.

Are you saying that for some packages it is expected that the
maintainer would only care about say epel7 and not epel8? In that case,
do we / would we track the maintainer for epel8 specifically somewhere,
if one were to volunteer?

> We would need to have a dedicated team of people to do this with ELN
> related items. We would also need to have additional build and
> storage resources to deal with these artifacts, not alone the growth
> of 'just need this' packages. 

Is there an easy way to ballpark estimate the resource demand that an
effort like this would require?

> When I was trying to make EPEL-8 1:1 with EPEL-7 I found I was having
> to add more and more packages just to get the new build 'requires:'
> done. I stopped around a thousand 'new' packages to the tree when I
> was reminded that we don't do automatic branching for EPEL. I really
> don't know how many packages would be needed to make it work, but do
> know it is a full time job to get set up and keep going. While ELN is
> probably 4000 src.rpms we would be looking at needing to
> build/rebuild double that for EPEL.

Ah, that's fair. I hadn't thought about potentially neededing to branch
extra packages to meet new build dependencies, but you're absolutely
right, that would be a major issue here.

I should probably expand on why I'm thinking about this in the first
place. I want to use ELN as a proxy for the next CentOS Stream release
to streamline its qualification on our infrastructure. The idea being
that if we can continously test ELN on a small subset of production,
that will detect potential issues early on, allow us to get ahead of
policy changes that might require internal work, and hopefully surface
bugs that we can report and fix upstream long before branch time.

However, we use EPEL a lot in our infrastructure, to the point that I
suspect it would be difficult to do a meaningful prod-like deployment
with ELN alone. I could probably hack something around this, but I
figured it'd be worth to see if we can build a generic solution instead
that could benefit Fedora and CentOS upstream, rather than something
Facebook specific. To be clear, I'm aware that this would require work
and resources within Fedora, and I'd be happy to help with both as
needed if this is deemed feasible.

Cheers
Davide
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ELN SIG First Meeting

2021-03-01 Thread Davide Cavalca via devel 
On Mon, 2021-03-01 at 12:47 -0800, Kevin Fenzi wrote:
> I'm not sure exactly what you mean here... 
> 
> I think (please correct me if I'm wrong) you are wanting "all EPEL
> packages" to also be built as part of ELN and shipped as some sort of
> 'EPEL-ELN' ?

Yes, the idea I had in mind was that each package that currenty has an
"epel8" branch would also get an "epeln" branch that would be built
against ELN. Then when ELN branches into CentOS Stream, the epeln
branches could be used as the starting point for the corresponding EPEL
release.

> The main problem with this is that "all EPEL packages" is not a
> defined
> set like ELN is. EPEL is not a specific collection of packages. It's
> packages which have maintainers that wish to maintain them. For this
> (and other) reasons we have never mass branched epel, we have always
> let
> maintainers branch when they wish to support that branch. 
> 
> I'm not sure if there's a way around this... I suppose we could try
> and
> collect a list of packages where maintainer(s) always want to branch
> them, but that would need to be a living document/list and would
> probibly be hard to keep up to date. 

Yeah, that's a good point. To be clear, I was not proposing to do this
for all Fedora packages, just for the ones that were already present in
the current EPEL.

Cheers
Davide
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ELN SIG First Meeting

2021-03-01 Thread Stephen John Smoogen 
On Mon, 1 Mar 2021 at 14:46, Davide Cavalca via devel <
devel@lists.fedoraproject.org> wrote:

> On Mon, 2021-03-01 at 09:26 -0500, Stephen Gallagher wrote:
> > I'd like to encourage anyone interested in this meeting to submit
> > agenda topics by replying to this email. Currently the agenda
>
> One thing I'd be interested in exploring is the feasibility of
> extending ELN to cover EPEL as well. This would make it easier to keep
> EPEL consistent between major releases (as packages would get branched
> automatically). It would also make it possible to test the combined ELN
> + EPEL snapshot and find potential issues early on in the process.
>
>
That would require a lot of changes in both EPEL and in Fedora. In Fedora
there is a general expectation that if a 'branch' is active then it is
maintained by someone.. usually the primary maintainer.  Many Fedora
maintainers are only interested in maintaining packages in the latest
release. THis is why the ELN packages are being 'watched/maintained' by the
ELN team and sig. Maintainership usually means dealing with bug reports,
build failures, etc which can take up a good amount of time.

This is part of the reason why EPEL packages are not auto-forked for each
EL release. Most maintainers are only interested in supporting maybe EL-6
or EL7 and we need to find someone new to do the EL-8 branch. We would need
to have a dedicated team of people to do this with ELN related items. We
would also need to have additional build and storage resources to deal with
these artifacts, not alone the growth of 'just need this' packages. When I
was trying to make EPEL-8 1:1 with EPEL-7 I found I was having to add more
and more packages just to get the new build 'requires:' done. I stopped
around a thousand 'new' packages to the tree when I was reminded that we
don't do automatic branching for EPEL. I really don't know how many
packages would be needed to make it work, but do know it is a full time job
to get set up and keep going. While ELN is probably 4000 src.rpms we would
be looking at needing to build/rebuild double that for EPEL.




> Cheers
> Davide
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
> Do not reply to spam on the list, report it:
> https://pagure.io/fedora-infrastructure
>


-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ELN SIG First Meeting

2021-03-01 Thread Kevin Fenzi 
On Mon, Mar 01, 2021 at 07:45:09PM +, Davide Cavalca via devel wrote:
> On Mon, 2021-03-01 at 09:26 -0500, Stephen Gallagher wrote:
> > I'd like to encourage anyone interested in this meeting to submit
> > agenda topics by replying to this email. Currently the agenda
> 
> One thing I'd be interested in exploring is the feasibility of
> extending ELN to cover EPEL as well. This would make it easier to keep
> EPEL consistent between major releases (as packages would get branched
> automatically). It would also make it possible to test the combined ELN
> + EPEL snapshot and find potential issues early on in the process.

I'm not sure exactly what you mean here... 

I think (please correct me if I'm wrong) you are wanting "all EPEL
packages" to also be built as part of ELN and shipped as some sort of
'EPEL-ELN' ?

The main problem with this is that "all EPEL packages" is not a defined
set like ELN is. EPEL is not a specific collection of packages. It's
packages which have maintainers that wish to maintain them. For this
(and other) reasons we have never mass branched epel, we have always let
maintainers branch when they wish to support that branch. 

I'm not sure if there's a way around this... I suppose we could try and
collect a list of packages where maintainer(s) always want to branch
them, but that would need to be a living document/list and would
probibly be hard to keep up to date. 

kevin


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

Re: ELN SIG First Meeting

2021-03-01 Thread Davide Cavalca via devel 
On Mon, 2021-03-01 at 09:26 -0500, Stephen Gallagher wrote:
> I'd like to encourage anyone interested in this meeting to submit
> agenda topics by replying to this email. Currently the agenda

One thing I'd be interested in exploring is the feasibility of
extending ELN to cover EPEL as well. This would make it easier to keep
EPEL consistent between major releases (as packages would get branched
automatically). It would also make it possible to test the combined ELN
+ EPEL snapshot and find potential issues early on in the process.

Cheers
Davide
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure

ELN SIG First Meeting

2021-03-01 Thread Stephen Gallagher 
Thank you to everyone who responded to the WhenIsGood. While no time
was available for all respondents, I selected the time with the
greatest availability. We will hold the inaugural ELN SIG meeting on
Friday, March 12th at noon EST (1700 UTC). We will hold this meeting
on Freenode IRC in #fedora-meeting (or via matrix.org at
https://matrix.to/#/#fedora-meeting:matrix.org ). We can decide at
this meeting whether we want to hold meetings via videochat or
IRC/matrix.org in the future.

I'd like to encourage anyone interested in this meeting to submit
agenda topics by replying to this email. Currently the agenda consists
of:

* Populate the initial SIG membership
* Agree on rules for expanding SIG membership
* Form a group to maintain the SIG documentation

If you want to add a meeting reminder to your calendar, here is an iCal link:
https://apps.fedoraproject.org/calendar/ical/calendar/meeting/9920/?reminder_delta=5
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org
Do not reply to spam on the list, report it: 
https://pagure.io/fedora-infrastructure