EPEL 10 status update

[Carl George]

I originally posted this on Fedora Discussion [0], but I'm sharing it
here as well for awareness.

# Executive summary

EPEL 10 is expected to be launched in Q4 of 2024.  You may start
noticing parts of the infrastructure coming online sooner than that.
**Please do not start creating EPEL 10 builds until we announce that
we are ready for packagers to start building.**

# Detailed description

The EPEL Steering Committee has big plans for EPEL 10.  These plans
are covered in detail in the original EPEL 10 proposal [1].  I also
presented an EPEL 10 overview at the Fedora 40 release party [2].  At
a high level, we are bringing minor versions to EPEL.  I encourage you
to read the proposal or watch that video for a deeper explanation.

I'm writing this post to share our planned timeline for EPEL 10, and
to set expectations for the coming months.  Early CentOS Stream 10
composes are already available [3], but it hasn't been officially
launched yet because the content set is still in flux.  We expect to
see the official launch announcement for CentOS Stream 10 later this
year.  We intend to align the EPEL 10 launch with that, which will
give us the following approximate timeline.

- August 2024: EPEL 10 hackfest at Flock [4] (see below for more details)
- Q4 2024: expected launch of CentOS Stream 10 and EPEL 10
- Q2 2025: expected launch of RHEL 10 (three years after RHEL 9)

In the months ahead, you may notice parts of EPEL 10 infrastructure
coming online, such as build targets in Koji and releases in Bodhi.
We will need these infrastructure pieces in place to work out all of
the details of integrating minor versions.  We'll send out an
announcement when EPEL 10 is ready for package maintainers to start
creating their builds.  **Please do not start creating EPEL 10 builds
until we announce that we are ready for packagers to start building.**
 Any builds created before this announcement may need to be discarded
and rebuilt.

I will be running an EPEL 10 Hackfest at Flock [4] in August (next
month).  The plan is to work on various infrastructure pieces related
to EPEL 10.  If we happen to have most of these pieces working prior
to the hackfest, we can pivot our time to adding initial packages to
EPEL 10.  I hope to see you there!

[0] https://discussion.fedoraproject.org/t/epel-10-status-update/124549
[1] https://discussion.fedoraproject.org/t/epel-10-proposal/44304
[2] https://youtu.be/PxWxK5PgUuE
[3] https://lists.centos.org/hyperkitty/list/[e-mail]/thread/QCO73...
[4] https://flocktofedora.org/

[Orion Poplawski]

On 7/4/24 01:45, Carl George wrote:
> I originally posted this on Fedora Discussion [0], but I'm sharing it
> here as well for awareness.
>
> # Executive summary
>
> EPEL 10 is expected to be launched in Q4 of 2024.  You may start
> noticing parts of the infrastructure coming online sooner than that.
> **Please do not start creating EPEL 10 builds until we announce that
> we are ready for packagers to start building.**

I'm seeing some builds and bugzilla requests for branching/builds.  What 
is the current status?

[Carl George]

Hey Orion,

I planned to send a status update following the hackfest, but I didn't
think about the confusion that would be caused for packagers not at
the hackfest who were getting branch requests.  Sorry about that.  I
just posted a summary on the discussion thread.  I'll include it below
as well.

---

The EPEL 10 hackfest at Flock took place yesterday.  We were able to
get enough of the infrastructure working prior to the hackfest to
enable packagers in attendance to do a controlled trial run building
packages.  This also resulted in a few branch request bugzillas for
dependencies, which I realize in hindsight was confusing for packagers
not at the hackfest.  I apologize for not setting that expectation
ahead of time.

Here is a summary of what is and isn't working at this point.

What works:

- creating epel10 branches (`fedpkg request-branch epel10`)
- pushing commits to epel10 branches
- pull requests to epel10 branches
- Fedora CI scratch builds for epel10 pull requests
- creating epel10.0 builds from epel10 branches (`fedpkg build` from
an epel10 branch)
- automatic bodhi updates, similar to rawhide

What has not been completed yet:

- publish the epel/10 repo
- mirror the epel/10 repo
- create epel-release for epel10
- epel10 configs in mock-core-configs
- Fedora CI tasks for epel10 pull requests
- enable the testing period in bodhi

With no published repo, no mirroring, and no testing period (0 days to
stable in bodhi), this is not a good time to start consuming EPEL 10.
However, it is a good time for packagers to start building their
packages.  To be clear, this is the announcement to packagers that
they can start building their packages.  I'm hoping that in the next
week or two we'll be able to get the mock configs done to enable
packagers to do local builds, but in the mean time koji scratch builds
are a solid alternative.

We built about 70 packages during the allotted time of the hackfest,
and as I write this we just passed 100 builds.  Things seem to be
working well.  Please let me know if you notice any issues, aside from
known items on the "not completed yet" list above.

Happy packaging!

On Sat, Aug 10, 2024 at 12:29 AM Orion Poplawski  wrote:
> On 7/4/24 01:45, Carl George wrote:
> > I originally posted this on Fedora Discussion [0], but I'm sharing it
> > here as well for awareness.
> >
> > # Executive summary
> >
> > EPEL 10 is expected to be launched in Q4 of 2024.  You may start
> > noticing parts of the infrastructure coming online sooner than that.
> > **Please do not start creating EPEL 10 builds until we announce that
> > we are ready for packagers to start building.**
>
> I'm seeing some builds and bugzilla requests for branching/builds.  What
> is the current status?
>
> --
> Orion Poplawski
> he/him/his  - surely the least important thing about me
> IT Systems Manager                         720-772-5637
> NWRA, Boulder/CoRA Office             FAX: [phone]
> 3380 Mitchell Lane                       [e-mail]
> Boulder, CO 80301                 https://www.nwra.com/
>
> --
> _______________________________________________
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Orion Poplawski]

Thank you for the update.  Is it time for an epel10 version in bugzilla? 
  Seems like it.

On 8/10/24 16:41, Carl George wrote:
> Hey Orion,
>
> I planned to send a status update following the hackfest, but I didn't
> think about the confusion that would be caused for packagers not at
> the hackfest who were getting branch requests.  Sorry about that.  I
> just posted a summary on the discussion thread.  I'll include it below
> as well.
>
> The EPEL 10 hackfest at Flock took place yesterday.  We were able to
> get enough of the infrastructure working prior to the hackfest to
> enable packagers in attendance to do a controlled trial run building
> packages.  This also resulted in a few branch request bugzillas for
> dependencies, which I realize in hindsight was confusing for packagers
> not at the hackfest.  I apologize for not setting that expectation
> ahead of time.
>
> Here is a summary of what is and isn't working at this point.
>
> What works:
> creating epel10 branches (`fedpkg request-branch epel10`)
> pushing commits to epel10 branches
> pull requests to epel10 branches
> Fedora CI scratch builds for epel10 pull requests
> creating epel10.0 builds from epel10 branches (`fedpkg build` from
>
> an epel10 branch)
> automatic bodhi updates, similar to rawhide
>
> What has not been completed yet:
> publish the epel/10 repo
> mirror the epel/10 repo
> create epel-release for epel10
> epel10 configs in mock-core-configs
> Fedora CI tasks for epel10 pull requests
> enable the testing period in bodhi
>
> With no published repo, no mirroring, and no testing period (0 days to
> stable in bodhi), this is not a good time to start consuming EPEL 10.
> However, it is a good time for packagers to start building their
> packages.  To be clear, this is the announcement to packagers that
> they can start building their packages.  I'm hoping that in the next
> week or two we'll be able to get the mock configs done to enable
> packagers to do local builds, but in the mean time koji scratch builds
> are a solid alternative.
>
> We built about 70 packages during the allotted time of the hackfest,
> and as I write this we just passed 100 builds.  Things seem to be
> working well.  Please let me know if you notice any issues, aside from
> known items on the "not completed yet" list above.
>
> Happy packaging!
>
> On Sat, Aug 10, 2024 at 12:29 AM Orion Poplawski  wrote:
> > On 7/4/24 01:45, Carl George wrote:
> > > I originally posted this on Fedora Discussion [0], but I'm sharing it
> > > here as well for awareness.
> > >
> > > # Executive summary
> > >
> > > EPEL 10 is expected to be launched in Q4 of 2024.  You may start
> > > noticing parts of the infrastructure coming online sooner than that.
> > > **Please do not start creating EPEL 10 builds until we announce that
> > > we are ready for packagers to start building.**
> >
> > I'm seeing some builds and bugzilla requests for branching/builds.  What
> > is the current status?
> >
> > --
> > Orion Poplawski
> > he/him/his  - surely the least important thing about me
> > IT Systems Manager                         720-772-5637
> > NWRA, Boulder/CoRA Office             FAX: [phone]
> > 3380 Mitchell Lane                       [e-mail]
> > Boulder, CO 80301                 https://www.nwra.com/
> >
> > --
> > _______________________________________________
> > epel-devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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/[e-mail]...
> > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Troy Dawson]

Touching on the stability of CentOS Stream 10, which we are building epel10
on.
Most of the major library updates, package removal and additions are done.
Perl is being rebased to 5.40 right now, so if you have perl packages, it
would be good to wait a week.

There will be some amount of package updates, additions and removals until
RHEL 10.0 is released.  That's just the nature of this.

We feel it is stable enough to be building EPEL10 at this time.
But know that you might need to rebuild, remove, and/or add packages, based
on what happens upstream.

Troy

On Sat, Aug 10, 2024 at 3:46 PM Orion Poplawski  wrote:
> Thank you for the update.  Is it time for an epel10 version in bugzilla?
>   Seems like it.
>
> On 8/10/24 16:41, Carl George wrote:
> > Hey Orion,
> >
> > I planned to send a status update following the hackfest, but I didn't
> > think about the confusion that would be caused for packagers not at
> > the hackfest who were getting branch requests.  Sorry about that.  I
> > just posted a summary on the discussion thread.  I'll include it below
> > as well.
> >
> > The EPEL 10 hackfest at Flock took place yesterday.  We were able to
> > get enough of the infrastructure working prior to the hackfest to
> > enable packagers in attendance to do a controlled trial run building
> > packages.  This also resulted in a few branch request bugzillas for
> > dependencies, which I realize in hindsight was confusing for packagers
> > not at the hackfest.  I apologize for not setting that expectation
> > ahead of time.
> >
> > Here is a summary of what is and isn't working at this point.
> >
> > What works:
> > creating epel10 branches (`fedpkg request-branch epel10`)
> > pushing commits to epel10 branches
> > pull requests to epel10 branches
> > Fedora CI scratch builds for epel10 pull requests
> > creating epel10.0 builds from epel10 branches (`fedpkg build` from
> >
> > an epel10 branch)
> > automatic bodhi updates, similar to rawhide
> >
> > What has not been completed yet:
> > publish the epel/10 repo
> > mirror the epel/10 repo
> > create epel-release for epel10
> > epel10 configs in mock-core-configs
> > Fedora CI tasks for epel10 pull requests
> > enable the testing period in bodhi
> >
> > With no published repo, no mirroring, and no testing period (0 days to
> > stable in bodhi), this is not a good time to start consuming EPEL 10.
> > However, it is a good time for packagers to start building their
> > packages.  To be clear, this is the announcement to packagers that
> > they can start building their packages.  I'm hoping that in the next
> > week or two we'll be able to get the mock configs done to enable
> > packagers to do local builds, but in the mean time koji scratch builds
> > are a solid alternative.
> >
> > We built about 70 packages during the allotted time of the hackfest,
> > and as I write this we just passed 100 builds.  Things seem to be
> > working well.  Please let me know if you notice any issues, aside from
> > known items on the "not completed yet" list above.
> >
> > Happy packaging!
> >
> > On Sat, Aug 10, 2024 at 12:29 AM Orion Poplawski  wrote:
> > > On 7/4/24 01:45, Carl George wrote:
> > > > I originally posted this on Fedora Discussion [0], but I'm sharing it
> > > > here as well for awareness.
> > > >
> > > > # Executive summary
> > > >
> > > > EPEL 10 is expected to be launched in Q4 of 2024.  You may start
> > > > noticing parts of the infrastructure coming online sooner than that.
> > > > **Please do not start creating EPEL 10 builds until we announce that
> > > > we are ready for packagers to start building.**
> > >
> > > I'm seeing some builds and bugzilla requests for branching/builds.  What
> > > is the current status?
> > >
> > > --
> > > Orion Poplawski
> > > he/him/his  - surely the least important thing about me
> > > IT Systems Manager                         720-772-5637
> > > NWRA, Boulder/CoRA Office             FAX: [phone]
> > > 3380 Mitchell Lane                       [e-mail]
> > > Boulder, CO 80301                 https://www.nwra.com/
> > >
> > > --
> > > _______________________________________________
> > > epel-devel mailing list -- [e-mail]
> > > To unsubscribe send an email to
>
> [e-mail]
> > > 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/[e-mail]...
> > > Do not reply to spam, report it:
>
> https://pagure.io/fedora-infrastructure/new_issue
> >
>
> --
> Orion Poplawski
> he/him/his  - surely the least important thing about me
> IT Systems Manager                         720-772-5637
> NWRA, Boulder/CoRA Office             FAX: [phone]
> 3380 Mitchell Lane                       [e-mail]
> Boulder, CO 80301                 https://www.nwra.com/
>
> --
> _______________________________________________
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Orion Poplawski]

I just built fail2ban and it generated a bunch of comments on various 
fail2ban bugs, e.g.:

https://bugzilla.redhat.com/show_bug.cgi?id=2217649

Why?

On 8/10/24 16:41, Carl George wrote:
> Hey Orion,
>
> I planned to send a status update following the hackfest, but I didn't
> think about the confusion that would be caused for packagers not at
> the hackfest who were getting branch requests.  Sorry about that.  I
> just posted a summary on the discussion thread.  I'll include it below
> as well.
>
> The EPEL 10 hackfest at Flock took place yesterday.  We were able to
> get enough of the infrastructure working prior to the hackfest to
> enable packagers in attendance to do a controlled trial run building
> packages.  This also resulted in a few branch request bugzillas for
> dependencies, which I realize in hindsight was confusing for packagers
> not at the hackfest.  I apologize for not setting that expectation
> ahead of time.
>
> Here is a summary of what is and isn't working at this point.
>
> What works:
> creating epel10 branches (`fedpkg request-branch epel10`)
> pushing commits to epel10 branches
> pull requests to epel10 branches
> Fedora CI scratch builds for epel10 pull requests
> creating epel10.0 builds from epel10 branches (`fedpkg build` from
>
> an epel10 branch)
> automatic bodhi updates, similar to rawhide
>
> What has not been completed yet:
> publish the epel/10 repo
> mirror the epel/10 repo
> create epel-release for epel10
> epel10 configs in mock-core-configs
> Fedora CI tasks for epel10 pull requests
> enable the testing period in bodhi
>
> With no published repo, no mirroring, and no testing period (0 days to
> stable in bodhi), this is not a good time to start consuming EPEL 10.
> However, it is a good time for packagers to start building their
> packages.  To be clear, this is the announcement to packagers that
> they can start building their packages.  I'm hoping that in the next
> week or two we'll be able to get the mock configs done to enable
> packagers to do local builds, but in the mean time koji scratch builds
> are a solid alternative.
>
> We built about 70 packages during the allotted time of the hackfest,
> and as I write this we just passed 100 builds.  Things seem to be
> working well.  Please let me know if you notice any issues, aside from
> known items on the "not completed yet" list above.
>
> Happy packaging!
>
> On Sat, Aug 10, 2024 at 12:29 AM Orion Poplawski  wrote:
> > On 7/4/24 01:45, Carl George wrote:
> > > I originally posted this on Fedora Discussion [0], but I'm sharing it
> > > here as well for awareness.
> > >
> > > # Executive summary
> > >
> > > EPEL 10 is expected to be launched in Q4 of 2024.  You may start
> > > noticing parts of the infrastructure coming online sooner than that.
> > > **Please do not start creating EPEL 10 builds until we announce that
> > > we are ready for packagers to start building.**
> >
> > I'm seeing some builds and bugzilla requests for branching/builds.  What
> > is the current status?
> >
> > --
> > Orion Poplawski
> > he/him/his  - surely the least important thing about me
> > IT Systems Manager                         720-772-5637
> > NWRA, Boulder/CoRA Office             FAX: [phone]
> > 3380 Mitchell Lane                       [e-mail]
> > Boulder, CO 80301                 https://www.nwra.com/
> >
> > --
> > _______________________________________________
> > epel-devel mailing list -- [e-mail]
> > To unsubscribe send an email to [e-mail]
> > 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/[e-mail]...
> > Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Jonathan Wright]

This is (unfortunately) expected.  Since epel 10 is currently being treated
like rawhide where bodhi updates are automatic, it will cite any bugs
listed in the change log in the bodhi update as well this generating the
emails.

On Sat, Aug 10, 2024, 21:53 Orion Poplawski  wrote:
> I just built fail2ban and it generated a bunch of comments on various
> fail2ban bugs, e.g.:
>
> https://bugzilla.redhat.com/show_bug.cgi?id=2217649
>
> Why?
>
> On 8/10/24 16:41, Carl George wrote:
> > Hey Orion,
> >
> > I planned to send a status update following the hackfest, but I didn't
> > think about the confusion that would be caused for packagers not at
> > the hackfest who were getting branch requests.  Sorry about that.  I
> > just posted a summary on the discussion thread.  I'll include it below
> > as well.
> >
> > The EPEL 10 hackfest at Flock took place yesterday.  We were able to
> > get enough of the infrastructure working prior to the hackfest to
> > enable packagers in attendance to do a controlled trial run building
> > packages.  This also resulted in a few branch request bugzillas for
> > dependencies, which I realize in hindsight was confusing for packagers
> > not at the hackfest.  I apologize for not setting that expectation
> > ahead of time.
> >
> > Here is a summary of what is and isn't working at this point.
> >
> > What works:
> > creating epel10 branches (`fedpkg request-branch epel10`)
> > pushing commits to epel10 branches
> > pull requests to epel10 branches
> > Fedora CI scratch builds for epel10 pull requests
> > creating epel10.0 builds from epel10 branches (`fedpkg build` from
> >
> > an epel10 branch)
> > automatic bodhi updates, similar to rawhide
> >
> > What has not been completed yet:
> > publish the epel/10 repo
> > mirror the epel/10 repo
> > create epel-release for epel10
> > epel10 configs in mock-core-configs
> > Fedora CI tasks for epel10 pull requests
> > enable the testing period in bodhi
> >
> > With no published repo, no mirroring, and no testing period (0 days to
> > stable in bodhi), this is not a good time to start consuming EPEL 10.
> > However, it is a good time for packagers to start building their
> > packages.  To be clear, this is the announcement to packagers that
> > they can start building their packages.  I'm hoping that in the next
> > week or two we'll be able to get the mock configs done to enable
> > packagers to do local builds, but in the mean time koji scratch builds
> > are a solid alternative.
> >
> > We built about 70 packages during the allotted time of the hackfest,
> > and as I write this we just passed 100 builds.  Things seem to be
> > working well.  Please let me know if you notice any issues, aside from
> > known items on the "not completed yet" list above.
> >
> > Happy packaging!
> >
> > On Sat, Aug 10, 2024 at 12:29 AM Orion Poplawski  wrote:
> > > On 7/4/24 01:45, Carl George wrote:
> > > > I originally posted this on Fedora Discussion [0], but I'm sharing it
> > > > here as well for awareness.
> > > >
> > > > # Executive summary
> > > >
> > > > EPEL 10 is expected to be launched in Q4 of 2024.  You may start
> > > > noticing parts of the infrastructure coming online sooner than that.
> > > > **Please do not start creating EPEL 10 builds until we announce that
> > > > we are ready for packagers to start building.**
> > >
> > > I'm seeing some builds and bugzilla requests for branching/builds.  What
> > > is the current status?
> > >
> > > --
> > > Orion Poplawski
> > > he/him/his  - surely the least important thing about me
> > > IT Systems Manager                         720-772-5637
> > > NWRA, Boulder/CoRA Office             FAX: [phone]
> > > 3380 Mitchell Lane                       [e-mail]
> > > Boulder, CO 80301                 https://www.nwra.com/
> > >
> > > --
> > > _______________________________________________
> > > epel-devel mailing list -- [e-mail]
> > > To unsubscribe send an email to
>
> [e-mail]
> > > 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/[e-mail]...
> > > Do not reply to spam, report it:
>
> https://pagure.io/fedora-infrastructure/new_issue
> >
>
> --
> Orion Poplawski
> he/him/his  - surely the least important thing about me
> IT Systems Manager                         720-772-5637
> NWRA, Boulder/CoRA Office             FAX: [phone]
> 3380 Mitchell Lane                       [e-mail]
> Boulder, CO 80301                 https://www.nwra.com/
>
> --
> _______________________________________________
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it:
> https://pagure.io/fedora-infrastructure/new_issue

[Miro Hrončok]

On 11. 08. 24 3:56, Jonathan Wright via epel-devel wrote:
> This is (unfortunately) expected.  Since epel 10 is currently being treated 
> like rawhide where bodhi updates are automatic, it will cite any bugs listed in 
> the change log in the bodhi update as well this generating the emails.

Using side tags to ship the updates should work as a workaround. (Assuming EPEL 
10 side tags work.)

[Mattia Verga]

Jonathan Wright wrote:
> This is (unfortunately) expected.  Since epel 10 is currently being treated
> like rawhide where bodhi updates are automatic, it will cite any bugs
> listed in the change log in the bodhi update as well this generating the
> emails.

You can disable that behavior by adding the release to the exclusion list at 
https://pagure.io/fedora-infra/ansible/blob/main/f/roles/bodhi2/base/templat...

[Carl George]

On Tue, Aug 13, 2024 at 1:47 AM Mattia Verga via epel-devel
 wrote:
> Jonathan Wright wrote:
> > This is (unfortunately) expected.  Since epel 10 is currently being treated
> > like rawhide where bodhi updates are automatic, it will cite any bugs
> > listed in the change log in the bodhi update as well this generating the
> > emails.
>
> You can disable that behavior by adding the release to the exclusion list at
> https://pagure.io/fedora-infra/ansible/blob/main/f/roles/bodhi2/base/templat...
> --
> _______________________________________________
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Thanks for the tip, I think it's a great idea.

https://pagure.io/fedora-infra/ansible/pull-request/2206

We should revert it when we disable automatic updates and enable the
testing repo.

[Miroslav Suchý]

Dne 11. 08. 24 v 12:41 dop. Carl George napsal(a):
> creating epel10 branches (`fedpkg request-branch epel10`)

Can be the branch automatically created for all packages that has epel9 branch? I am not looking forward to request 
dozens of branches for all my packages.

[Stephen Smoogen]

On Mon, 12 Aug 2024 at 17:44, Miroslav Suchý  wrote:
> Dne 11. 08. 24 v 12:41 dop. Carl George napsal(a):
> creating epel10 branches (`fedpkg request-branch epel10`)
>
> Can be the branch automatically created for all packages that has epel9
> branch? I am not looking forward to request dozens of branches for all my
> packages.

This is something I wanted to do in previous EPEL splits, but it has
usually gotten too many complaints from packagers to consider. Many
packagers don't want their packages in EPEL at all but will do so if there
are requests from someone or that there is going to be a branch packager
for EPEL packages. Many EPEL branch packagers really only want to support
one release because that is what they are using versus multiple ones.

That said, I think it is something to revisit like we did for EL7, EL8 and
EL9 :).

[Gary Buhrmaster]

On Tue, Aug 13, 2024 at 9:12 AM Stephen Smoogen  wrote:
> This is something I wanted to do in previous EPEL splits, but it has usually gotten too many complaints from packagers to consider. Many packagers don't want their packages in EPEL at all but will do so if there are requests from someone or that there is going to be a branch packager for EPEL packages. Many EPEL branch packagers really only want to support one release because that is what they are using versus multiple ones.

There is also the case (I had one), where a package
(in epel8) was later incorporated by RH into EL9, for
which automatic branch requests might have been an
issue (unless the automatic approval processes already
checks for that and rejects the branch request).
> That said, I think it is something to revisit like we did for EL7, EL8 and EL9 :).

Personally, automatic branching would work fine
for me, but often my bigger issue is opening the
bugzilla tickets for the often large dependency
chain for some scripting languages asking for
each package to be actually built, and then
waiting for the packager to have the resources
to build them.  If one starts with the premise that
the packagers should control the creation of all
branches then auto-creating all those dependency
branch/build bugzillas (and *their* dependency
branch/build bugzillas, and so on) might be a
better step forward to reduce the process delays.

[Troy Dawson]

How I get all my packages branched.
** Put all your packages in a file, one line per package.
  head -n2 my.package.list
    akonadi-calendar-tools
    akonadiconsole

** Run through the list and branch them all
  cat my.package.list | while read package
  do
    echo $package
    fedpkg request-branch --repo $package epel10
  done

Same amount of effort for 5, 20, 400 packages.

As someone else on the thread said, it's getting all the dependencies that
is the hard part.

Troy

[Carl George]

On Tue, Aug 13, 2024 at 10:17 AM Gary Buhrmaster
 wrote:
> On Tue, Aug 13, 2024 at 9:12 AM Stephen Smoogen  wrote:
> > This is something I wanted to do in previous EPEL splits, but it has usually gotten too many complaints from packagers to consider. Many packagers don't want their packages in EPEL at all but will do so if there are requests from someone or that there is going to be a branch packager for EPEL packages. Many EPEL branch packagers really only want to support one release because that is what they are using versus multiple ones.
>
> There is also the case (I had one), where a package
> (in epel8) was later incorporated by RH into EL9, for
> which automatic branch requests might have been an
> issue (unless the automatic approval processes already
> checks for that and rejects the branch request).

When you request a branch this is actually verified twice.  fedpkg
checks the CentOS Stream compose metadata before filing the issue and
it should reject the request (not even creating the issue) if the
package already exists in that metadata (because that means it's
already in RHEL, or on the way to RHEL soon).  If somehow the issue
gets filed anyways, the SCM toddler does the same check before
creating the branch.

If we were to automate things further, we'll definitely need to build
a similar check into that process.
> > That said, I think it is something to revisit like we did for EL7, EL8 and EL9 :).
>
> Personally, automatic branching would work fine
> for me, but often my bigger issue is opening the
> bugzilla tickets for the often large dependency
> chain for some scripting languages asking for
> each package to be actually built, and then
> waiting for the packager to have the resources
> to build them.  If one starts with the premise that
> the packagers should control the creation of all
> branches then auto-creating all those dependency
> branch/build bugzillas (and *their* dependency
> branch/build bugzillas, and so on) might be a
> better step forward to reduce the process delays.
> --
> _______________________________________________
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Carl George]

On Tue, Aug 13, 2024 at 4:12 AM Stephen Smoogen  wrote:
> On Mon, 12 Aug 2024 at 17:44, Miroslav Suchý  wrote:
> > Dne 11. 08. 24 v 12:41 dop. Carl George napsal(a):
> > creating epel10 branches (`fedpkg request-branch epel10`)
> >
> > Can be the branch automatically created for all packages that has epel9 branch? I am not looking forward to request dozens of branches for all my packages.
>
> This is something I wanted to do in previous EPEL splits, but it has usually gotten too many complaints from packagers to consider. Many packagers don't want their packages in EPEL at all but will do so if there are requests from someone or that there is going to be a branch packager for EPEL packages. Many EPEL branch packagers really only want to support one release because that is what they are using versus multiple ones.
>
> That said, I think it is something to revisit like we did for EL7, EL8 and EL9 :).
>
> --
> Stephen Smoogen, Red Hat Automotive
> Let us be kind to one another, for most of us are fighting a hard battle. -- Ian MacClaren
> --
> _______________________________________________
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Beyond just revisiting it, we need someone to step up to figure out
the implementation and policy work.  There was some discussion in the
EPEL Steering Committee meetings about doing it for EPEL 10 based on
ELN Extras workloads in Content Resolver, but that idea lost steam
around the time the branch requests became automated with a toddler.
Now for packages you're the maintainer of, getting the branch is one
additional command that results in the branch being ready within
minutes.  Is it even worth automating this further?  For packages
you're not a maintainer of, is it even appropriate for us to automate
the process and not rely on maintainer opt-in like we do now?

[Kevin Fenzi]

On Tue, Aug 13, 2024 at 05:11:54AM GMT, Stephen Smoogen wrote:
> On Mon, 12 Aug 2024 at 17:44, Miroslav Suchý  wrote:
> > Dne 11. 08. 24 v 12:41 dop. Carl George napsal(a):
> > creating epel10 branches (`fedpkg request-branch epel10`)
> >
> > Can be the branch automatically created for all packages that has epel9
> > branch? I am not looking forward to request dozens of branches for all my
> > packages.
>
> This is something I wanted to do in previous EPEL splits, but it has
> usually gotten too many complaints from packagers to consider. Many
> packagers don't want their packages in EPEL at all but will do so if there
> are requests from someone or that there is going to be a branch packager
> for EPEL packages. Many EPEL branch packagers really only want to support
> one release because that is what they are using versus multiple ones.
>
> That said, I think it is something to revisit like we did for EL7, EL8 and
> EL9 :).

I don't think this is something we want to do.

Things change a lot for many packges over 3 years. We shouldn't assume
that a package in EPEL N would also be desired in EPEL N+1. It might
only work with an older stack, it might be something that is soon to be
replaced, we can't really know.

kevin

[Orion Poplawski]

On 8/10/24 16:41, Carl George wrote:
> What has not been completed yet:
> publish the epel/10 repo

Do we have an ETA for an EPEL10 compose (if only in koji)?  Thanks!

[Carl George]

On Tue, Aug 13, 2024 at 3:15 PM Orion Poplawski  wrote:
> On 8/10/24 16:41, Carl George wrote:
> > What has not been completed yet:
> > publish the epel/10 repo
>
> Do we have an ETA for an EPEL10 compose (if only in koji)?  Thanks!
>
> --
> Orion Poplawski
> he/him/his  - surely the least important thing about me
> Manager of IT Systems                      720-772-5637
> NWRA, Boulder/CoRA Office             FAX: [phone]
> 3380 Mitchell Lane                       [e-mail]
> Boulder, CO 80301                 https://www.nwra.com/
>
> --
> _______________________________________________
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

The last few days folks have been travelling home from Flock, and
today releng was quite busy with F41 branching so I didn't want to
bother them.  I'm hoping to work with them to get it done later this
week or next week.

[Michael J Gruber]

Thanks for the heads-up on EPEL 10.

₣rom the view of a Fedora packager who maintains EPEL branches as a
way of "paying back" (for infra etc), there is the following problem:
There seem to be mass requests for branching packages for EPEL 10
which sound as if we just had to branch and build, maybe adjust.
As a matter of fact, the hardest part is getting all prerequisites
into EPEL first. From such mass requests I expect that at least build
requires and requires have been checked and blockers set up in
bugzilla accordingly, or at least *mentioned*.
The way it's being done now I've churned time on this to new avail.
The easy way out is letting the sig to handle this. (And the sig's FAS
handle is wrong in the ticket, too.)
So, please, let's make each others' work as easy as possible.

Michael

[Gary Buhrmaster]

On Sat, Aug 10, 2024 at 10:42 PM Carl George  wrote:
> Happy packaging!

I have noted that some dependencies for some
of my packages are (apparently) no longer
going to be shipped in EL10 (they were in
EL9).

Before I request the branches and builds
in EPEL10, I would like to make sure those
packages are really removed from EL10, and
are not some artifact of my misunderstandings.

Is there a list somewhere of packages that
are known to have been removed from EL10?

Thanks.

[Troy Dawson]

On Sun, Sep 1, 2024 at 3:03 PM Gary Buhrmaster 
wrote:
> On Sat, Aug 10, 2024 at 10:42 PM Carl George  wrote:
> > Happy packaging!
>
> I have noted that some dependencies for some
> of my packages are (apparently) no longer
> going to be shipped in EL10 (they were in
> EL9).
>
> Before I request the branches and builds
> in EPEL10, I would like to make sure those
> packages are really removed from EL10, and
> are not some artifact of my misunderstandings.
>
> Is there a list somewhere of packages that
> are known to have been removed from EL10?

Three things I do.
1 - Go to the CentOS Stream koji instance, look up the package, look at the
latest el10 build of that package, and see if it's tags have been removed,
or it has a trashcan tag.
Examples:
bash (still there) -
https://kojihub.stream.centos.org/koji/buildinfo?buildID=62779
java-17-openjdk (removed) -
https://kojihub.stream.centos.org/koji/buildinfo?buildID=66493

2 - dnf list <package>
This isn't the best.  Sometimes a package is still in the process of being
removed.  Or it's been untagged, but we haven't had a successful compose
pushed out.
But, it's still a quick way to check.

3 - jira search
The CentOS Stream 10 package removals are public in jira.  We have a tag
for centos-stream-10 package removals.
This isn't 100% accurate, because sometimes the package has been re-added,
but that is rare.
https://issues.redhat.com/browse/CS-2504?jql=labels%20%3D%20rhel-10-beta-pac...

I hope this helps.
Troy

[Gary Buhrmaster]

On Tue, Sep 3, 2024 at 4:01 PM Troy Dawson  wrote:
> I hope this helps.

It does.  Thanks.

[Leon Fauster]

Am 03.09.24 um 18:00 schrieb Troy Dawson:
> On Sun, Sep 1, 2024 at 3:03 PM Gary Buhrmaster 
> <[e-mail] > wrote:
> On Sat, Aug 10, 2024 at 10:42 PM Carl George <[e-mail]
> <mailto:[e-mail]>> wrote:
>
>  >
>  > Happy packaging!
>  >
>
> I have noted that some dependencies for some
> of my packages are (apparently) no longer
> going to be shipped in EL10 (they were in
> EL9).
>
> Before I request the branches and builds
> in EPEL10, I would like to make sure those
> packages are really removed from EL10, and
> are not some artifact of my misunderstandings.
>
> Is there a list somewhere of packages that
> are known to have been removed from EL10?
>
>
> Three things I do.
> 1 - Go to the CentOS Stream koji instance, look up the package, look at 
> the latest el10 build of that package, and see if it's tags have been 
> removed, or it has a trashcan tag.
> Examples:
> bash (still there) - 
> https://kojihub.stream.centos.org/koji/buildinfo?buildID=62779 
> https://kojihub.stream.centos.org/koji/buildinfo?buildID=62779
> java-17-openjdk (removed) - 
> https://kojihub.stream.centos.org/koji/buildinfo?buildID=66493 
> https://kojihub.stream.centos.org/koji/buildinfo?buildID=66493
>
> 2 - dnf list <package>
> This isn't the best.  Sometimes a package is still in the process of 
> being removed.  Or it's been untagged, but we haven't had a successful 
> compose pushed out.
> But, it's still a quick way to check.
>
> 3 - jira search
> The CentOS Stream 10 package removals are public in jira.  We have a tag 
> for centos-stream-10 package removals.
> This isn't 100% accurate, because sometimes the package has been 
> re-added, but that is rare.
> https://issues.redhat.com/browse/CS-2504?jql=labels%20%3D%20rhel-10-beta-pac... https://issues.redhat.com/browse/CS-2504?jql=labels%20%3D%20rhel-10-beta-package-removal

I wonder if RHEL10 will have a Workstation flavor? Or if CS10 will be 
usable as Workstation OS. When I see all the missing/removed parts.
Can not imagine that EPEL can compensate this all (e.g. is firefox in
the compose?).

[Carl George]

On Tue, Sep 3, 2024 at 1:16 PM Leon Fauster via epel-devel
 wrote:
> Am 03.09.24 um 18:00 schrieb Troy Dawson:
> > On Sun, Sep 1, 2024 at 3:03 PM Gary Buhrmaster
> > <[e-mail] > wrote:
> > On Sat, Aug 10, 2024 at 10:42 PM Carl George <[e-mail]
> > <mailto:[e-mail]>> wrote:
> >
> >  >
> >  > Happy packaging!
> >  >
> >
> > I have noted that some dependencies for some
> > of my packages are (apparently) no longer
> > going to be shipped in EL10 (they were in
> > EL9).
> >
> > Before I request the branches and builds
> > in EPEL10, I would like to make sure those
> > packages are really removed from EL10, and
> > are not some artifact of my misunderstandings.
> >
> > Is there a list somewhere of packages that
> > are known to have been removed from EL10?
> >
> >
> > Three things I do.
> > 1 - Go to the CentOS Stream koji instance, look up the package, look at
> > the latest el10 build of that package, and see if it's tags have been
> > removed, or it has a trashcan tag.
> > Examples:
> > bash (still there) -
> > https://kojihub.stream.centos.org/koji/buildinfo?buildID=62779
> > https://kojihub.stream.centos.org/koji/buildinfo?buildID=62779
> > java-17-openjdk (removed) -
> > https://kojihub.stream.centos.org/koji/buildinfo?buildID=66493
> > https://kojihub.stream.centos.org/koji/buildinfo?buildID=66493
> >
> > 2 - dnf list <package>
> > This isn't the best.  Sometimes a package is still in the process of
> > being removed.  Or it's been untagged, but we haven't had a successful
> > compose pushed out.
> > But, it's still a quick way to check.
> >
> > 3 - jira search
> > The CentOS Stream 10 package removals are public in jira.  We have a tag
> > for centos-stream-10 package removals.
> > This isn't 100% accurate, because sometimes the package has been
> > re-added, but that is rare.
> > https://issues.redhat.com/browse/CS-2504?jql=labels%20%3D%20rhel-10-beta-pac... https://issues.redhat.com/browse/CS-2504?jql=labels%20%3D%20rhel-10-beta-package-removal
>
> I wonder if RHEL10 will have a Workstation flavor? Or if CS10 will be
> usable as Workstation OS. When I see all the missing/removed parts.
> Can not imagine that EPEL can compensate this all (e.g. is firefox in
> the compose?).
>
> --
> Leon
>
> --
> _______________________________________________
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

Why can't EPEL compensate for this?  If RHEL doesn't ship it, then
it's probably eligible to be shipped in EPEL.  Several desktop apps
such as firefox were dropped, but all it takes is someone willing to
maintain them in EPEL 10.  If there is a package you rely on that was
dropped, then become a packager and file a bug asking the Fedora
maintainer to add you as a co-maintainer.

https://docs.fedoraproject.org/en-US/package-maintainers/Joining_the_Package...

https://docs.fedoraproject.org/en-US/epel/epel-package-request/#fedora_packa...

[Leon Fauster]

Am 04.09.24 um 05:46 schrieb Carl George:
> On Tue, Sep 3, 2024 at 1:16 PM Leon Fauster via epel-devel
> > I wonder if RHEL10 will have a Workstation flavor? Or if CS10 will be
> > usable as Workstation OS. When I see all the missing/removed parts.
> > Can not imagine that EPEL can compensate this all (e.g. is firefox in
> > the compose?).
>
> Why can't EPEL compensate for this?  If RHEL doesn't ship it, then
> it's probably eligible to be shipped in EPEL.  Several desktop apps
> such as firefox were dropped, but all it takes is someone willing to
> maintain them in EPEL 10.  If there is a package you rely on that was
> dropped, then become a packager and file a bug asking the Fedora
> maintainer to add you as a co-maintainer.

I had more the needed human resources then the technical
part in mind. BTW, thanks for your work on EPEL!

I do already my best in providing testing/integration time
and bug reports to elevate the quality of the available packages.

[Stephen Smoogen]

On Tue, 3 Sept 2024 at 23:47, Carl George  wrote:
> On Tue, Sep 3, 2024 at 1:16 PM Leon Fauster via epel-devel
>  wrote:
> > I wonder if RHEL10 will have a Workstation flavor? Or if CS10 will be
> > usable as Workstation OS. When I see all the missing/removed parts.
> > Can not imagine that EPEL can compensate this all (e.g. is firefox in
> > the compose?).
>
> Why can't EPEL compensate for this?  If RHEL doesn't ship it, then
> it's probably eligible to be shipped in EPEL.  Several desktop apps
> such as firefox were dropped, but all it takes is someone willing to
> maintain them in EPEL 10.  If there is a package you rely on that was
> dropped, then become a packager and file a bug asking the Fedora
> maintainer to add you as a co-maintainer.

Going from my experience with trying to maintain out-of-tree Firefox's in
the past.. it is not something I would say is well suited without a lot of
dedicated resources. I am guessing that is the reason it is being pulled
out as some sort of flatpak or similar tool.

1. You need to keep rust and other tooling up-to-date. Easy to do early in
a RHEL release, but over time getting harder and harder. The CentOS-7
Firefox package needed a LOT of newer compilers, toolkits etc which then
needed even more tooling which had to be researched every update.
2. You need to keep up-to-date with what is an 'important' update and what
isn't. Firefox in Fedora may get updated fairly regularly to keep up with
mainline LTS, but the RHEL one may not because various fixes are low and
probably affected some testing.
3. You end up having to deal with a LOT and I mean a lot of consumer
complaints because some websites no longer work after an update which you
have no control over. They may have dozens of extras installed which now
don't work, or they may have a corrupt cache, or a dozen other things which
they expect the maintainer to fix.

I wish anyone signing up to do this good luck, but I would really say that
this may be something not wanted.

[Andrew C Aitchison]

On Fri, 6 Sep 2024, Stephen Smoogen wrote:
> On Tue, 3 Sept 2024 at 23:47, Carl George  wrote:
> > On Tue, Sep 3, 2024 at 1:16 PM Leon Fauster via epel-devel
> >  wrote:
> > > I wonder if RHEL10 will have a Workstation flavor? Or if CS10 will be
> > > usable as Workstation OS. When I see all the missing/removed parts.
> > > Can not imagine that EPEL can compensate this all (e.g. is firefox in
> > > the compose?).
> >
> > Why can't EPEL compensate for this?  If RHEL doesn't ship it, then
> > it's probably eligible to be shipped in EPEL.  Several desktop apps
> > such as firefox were dropped, but all it takes is someone willing to
> > maintain them in EPEL 10.  If there is a package you rely on that was
> > dropped, then become a packager and file a bug asking the Fedora
> > maintainer to add you as a co-maintainer.
>
> Going from my experience with trying to maintain out-of-tree Firefox's in
> the past.. it is not something I would say is well suited without a lot of
> dedicated resources. I am guessing that is the reason it is being pulled
> out as some sort of flatpak or similar tool.

Mozilla has started shipping a firefox.deb for Ubuntu (and possibly Debian)
to compensate for Ubuntu moving to a Firefox snap.

I wonder whether they would take on RHEL10 ?
> You need to keep rust and other tooling up-to-date. Easy to do early in
>
> a RHEL release, but over time getting harder and harder. The CentOS-7
> Firefox package needed a LOT of newer compilers, toolkits etc which then
> needed even more tooling which had to be researched every update.
> 2. You need to keep up-to-date with what is an 'important' update and what
> isn't. Firefox in Fedora may get updated fairly regularly to keep up with
> mainline LTS, but the RHEL one may not because various fixes are low and
> probably affected some testing.
> 3. You end up having to deal with a LOT and I mean a lot of consumer
> complaints because some websites no longer work after an update which you
> have no control over. They may have dozens of extras installed which now
> don't work, or they may have a corrupt cache, or a dozen other things which
> they expect the maintainer to fix.
>
> I wish anyone signing up to do this good luck, but I would really say that
> this may be something not wanted.

[Carl George]

On Tue, Sep 3, 2024 at 11:01 AM Troy Dawson  wrote:
> On Sun, Sep 1, 2024 at 3:03 PM Gary Buhrmaster  wrote:
> > On Sat, Aug 10, 2024 at 10:42 PM Carl George  wrote:
> > > Happy packaging!
> >
> > I have noted that some dependencies for some
> > of my packages are (apparently) no longer
> > going to be shipped in EL10 (they were in
> > EL9).
> >
> > Before I request the branches and builds
> > in EPEL10, I would like to make sure those
> > packages are really removed from EL10, and
> > are not some artifact of my misunderstandings.
> >
> > Is there a list somewhere of packages that
> > are known to have been removed from EL10?
>
> Three things I do.
> 1 - Go to the CentOS Stream koji instance, look up the package, look at the latest el10 build of that package, and see if it's tags have been removed, or it has a trashcan tag.
> Examples:
> bash (still there) - https://kojihub.stream.centos.org/koji/buildinfo?buildID=62779
> java-17-openjdk (removed) - https://kojihub.stream.centos.org/koji/buildinfo?buildID=66493
>
> 2 - dnf list <package>
> This isn't the best.  Sometimes a package is still in the process of being removed.  Or it's been untagged, but we haven't had a successful compose pushed out.
> But, it's still a quick way to check.
>
> 3 - jira search
> The CentOS Stream 10 package removals are public in jira.  We have a tag for centos-stream-10 package removals.
> This isn't 100% accurate, because sometimes the package has been re-added, but that is rare.
> https://issues.redhat.com/browse/CS-2504?jql=labels%20%3D%20rhel-10-beta-pac...
>
> I hope this helps.
> Troy
> --
> _______________________________________________
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

One extra note I'll add, you don't have to necessarily check this
manually yourself.  When you run `fedpkg request-branch epel10`, it
will check the CentOS Stream 10 compose metadata, and it will refuse
to proceed if the source package you're asking for a branch in is in
that metadata.  If that check passes, fedpkg creates the SCM request
ticket, and the toddler that processes that ticket does the same
compose metadata check again before creating the branch.

So basically, if your branch request goes through, you're good.

[Carl George]

On Thu, Jul 4, 2024 at 2:45 AM Carl George  wrote:
> I originally posted this on Fedora Discussion [0], but I'm sharing it
> here as well for awareness.
>
> # Executive summary
>
> EPEL 10 is expected to be launched in Q4 of 2024.  You may start
> noticing parts of the infrastructure coming online sooner than that.
> **Please do not start creating EPEL 10 builds until we announce that
> we are ready for packagers to start building.**
>
> # Detailed description
>
> The EPEL Steering Committee has big plans for EPEL 10.  These plans
> are covered in detail in the original EPEL 10 proposal [1].  I also
> presented an EPEL 10 overview at the Fedora 40 release party [2].  At
> a high level, we are bringing minor versions to EPEL.  I encourage you
> to read the proposal or watch that video for a deeper explanation.
>
> I'm writing this post to share our planned timeline for EPEL 10, and
> to set expectations for the coming months.  Early CentOS Stream 10
> composes are already available [3], but it hasn't been officially
> launched yet because the content set is still in flux.  We expect to
> see the official launch announcement for CentOS Stream 10 later this
> year.  We intend to align the EPEL 10 launch with that, which will
> give us the following approximate timeline.
> August 2024: EPEL 10 hackfest at Flock [4] (see below for more details)
> Q4 2024: expected launch of CentOS Stream 10 and EPEL 10
> Q2 2025: expected launch of RHEL 10 (three years after RHEL 9)
>
> In the months ahead, you may notice parts of EPEL 10 infrastructure
> coming online, such as build targets in Koji and releases in Bodhi.
> We will need these infrastructure pieces in place to work out all of
> the details of integrating minor versions.  We'll send out an
> announcement when EPEL 10 is ready for package maintainers to start
> creating their builds.  **Please do not start creating EPEL 10 builds
> until we announce that we are ready for packagers to start building.**
>  Any builds created before this announcement may need to be discarded
> and rebuilt.
>
> I will be running an EPEL 10 Hackfest at Flock [4] in August (next
> month).  The plan is to work on various infrastructure pieces related
> to EPEL 10.  If we happen to have most of these pieces working prior
> to the hackfest, we can pivot our time to adding initial packages to
> EPEL 10.  I hope to see you there!
>
> [0] https://discussion.fedoraproject.org/t/epel-10-status-update/124549
> [1] https://discussion.fedoraproject.org/t/epel-10-proposal/44304
> [2] https://youtu.be/PxWxK5PgUuE
> [3] https://lists.centos.org/hyperkitty/list/[e-mail]/thread/QCO73...
> [4] https://flocktofedora.org/
>
> --
> Carl George

Quick note for anyone watching this thread, please keep in mind that
some pieces of the infrastructure will continue to be in flux until
the official launch.  For example, our plan was to turn on automatic
bodhi updates until the official launch.  That worked for a little
while and builds were created and moved to stable, but then that
stopped working once we tried to enable a bodhi compose.  We've
implemented a separate compose outside of bodhi, but we need to
temporarily disable new epel10 builds and revert it to finish
processing builds that are still in "pending->testing" and
"pending->stable" states.  I'll post here again once the builds can
resume.

[Andrew Bauer]

Thanks for the heads up. I received a few epel 10 branch and build requests this week and took that to mean I should build all my packages for epel 10.

I got several built, when I started seeing "Could not execute build: Unknown build target: epel10-candidate"... from your last message, it looks like this is by design. I apologize for the extra packages that are now in epel 10. I'll check back here for the green light to proceed again.

[Carl George]

On Fri, Sep 6, 2024 at 5:32 PM Andrew Bauer
 wrote:
> Thanks for the heads up. I received a few epel 10 branch and build requests this week and took that to mean I should build all my packages for epel 10.

Not necessarily, as you can see from the beginning of this thread.  I
would describe the current state as a "soft launch" period, intended
to give packagers more time to get their packages ready.  That is
resulting in lots of branch and build requests as packagers
re-discover their dependency chains and the packages they don't have
access to do themselves.  It's considerate to other packagers to act
fairly quickly on those requests to unblock the packages that depend
on them.  For packages you haven't gotten requests for, it's perfectly
fine to take your time.  It may even be wise to do some in some cases
if the upstream is releasing a new version soon that wouldn't be
allowed as an update in EPEL.
> I got several built, when I started seeing "Could not execute build: Unknown build target: epel10-candidate"... from your last message, it looks like this is by design. I apologize for the extra packages that are now in epel 10. I'll check back here for the green light to proceed again.

No need to apologize.  The build targets have been restored, so feel
free to build away (if you want to).
> --
> _______________________________________________
> epel-devel mailing list -- [e-mail]
> To unsubscribe send an email to [e-mail]
> 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/[e-mail]...
> Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue

[Carl George]

On Fri, Sep 6, 2024 at 4:11 PM Carl George  wrote:
> On Thu, Jul 4, 2024 at 2:45 AM Carl George  wrote:
> > I originally posted this on Fedora Discussion [0], but I'm sharing it
> > here as well for awareness.
> >
> > # Executive summary
> >
> > EPEL 10 is expected to be launched in Q4 of 2024.  You may start
> > noticing parts of the infrastructure coming online sooner than that.
> > **Please do not start creating EPEL 10 builds until we announce that
> > we are ready for packagers to start building.**
> >
> > # Detailed description
> >
> > The EPEL Steering Committee has big plans for EPEL 10.  These plans
> > are covered in detail in the original EPEL 10 proposal [1].  I also
> > presented an EPEL 10 overview at the Fedora 40 release party [2].  At
> > a high level, we are bringing minor versions to EPEL.  I encourage you
> > to read the proposal or watch that video for a deeper explanation.
> >
> > I'm writing this post to share our planned timeline for EPEL 10, and
> > to set expectations for the coming months.  Early CentOS Stream 10
> > composes are already available [3], but it hasn't been officially
> > launched yet because the content set is still in flux.  We expect to
> > see the official launch announcement for CentOS Stream 10 later this
> > year.  We intend to align the EPEL 10 launch with that, which will
> > give us the following approximate timeline.
> > August 2024: EPEL 10 hackfest at Flock [4] (see below for more details)
> > Q4 2024: expected launch of CentOS Stream 10 and EPEL 10
> > Q2 2025: expected launch of RHEL 10 (three years after RHEL 9)
> >
> > In the months ahead, you may notice parts of EPEL 10 infrastructure
> > coming online, such as build targets in Koji and releases in Bodhi.
> > We will need these infrastructure pieces in place to work out all of
> > the details of integrating minor versions.  We'll send out an
> > announcement when EPEL 10 is ready for package maintainers to start
> > creating their builds.  **Please do not start creating EPEL 10 builds
> > until we announce that we are ready for packagers to start building.**
> >  Any builds created before this announcement may need to be discarded
> > and rebuilt.
> >
> > I will be running an EPEL 10 Hackfest at Flock [4] in August (next
> > month).  The plan is to work on various infrastructure pieces related
> > to EPEL 10.  If we happen to have most of these pieces working prior
> > to the hackfest, we can pivot our time to adding initial packages to
> > EPEL 10.  I hope to see you there!
> >
> > [0] https://discussion.fedoraproject.org/t/epel-10-status-update/124549
> > [1] https://discussion.fedoraproject.org/t/epel-10-proposal/44304
> > [2] https://youtu.be/PxWxK5PgUuE
> > [3] https://lists.centos.org/hyperkitty/list/[e-mail]/thread/QCO73...
> > [4] https://flocktofedora.org/
> >
> > --
> > Carl George
>
> Quick note for anyone watching this thread, please keep in mind that
> some pieces of the infrastructure will continue to be in flux until
> the official launch.  For example, our plan was to turn on automatic
> bodhi updates until the official launch.  That worked for a little
> while and builds were created and moved to stable, but then that
> stopped working once we tried to enable a bodhi compose.  We've
> implemented a separate compose outside of bodhi, but we need to
> temporarily disable new epel10 builds and revert it to finish
> processing builds that are still in "pending->testing" and
> "pending->stable" states.  I'll post here again once the builds can
> resume.
>
> --
> Carl George

We were able to get all of the in-between builds processed, and have
re-enabled the new compose method.  We've also re-enabled the build
targets, and verified that a new build got an automatic update that
moved to stable automatically, just like rawhide.  Builds that are
marked stable should be available in the buildroot as soon as the
regen-repo task finishes, and then composed nightly.  This pipeline
should stay the same until the official EPEL 10 launch in Q4.  That's
when we'll switch to the standard EPEL pipeline, with manually created
updates, a default one week testing period, and bodhi composes.

Packagers can resume building for epel10 at their leisure.  Let us
know if anything doesn't seem to be working as expected.

[Paul Howarth]

On Fri, 6 Sep 2024 19:19:46 -0500
Carl George  wrote:
> We were able to get all of the in-between builds processed, and have
> re-enabled the new compose method.  We've also re-enabled the build
> targets, and verified that a new build got an automatic update that
> moved to stable automatically, just like rawhide.  Builds that are
> marked stable should be available in the buildroot as soon as the
> regen-repo task finishes, and then composed nightly.  This pipeline
> should stay the same until the official EPEL 10 launch in Q4.  That's
> when we'll switch to the standard EPEL pipeline, with manually created
> updates, a default one week testing period, and bodhi composes.
>
> Packagers can resume building for epel10 at their leisure.  Let us
> know if anything doesn't seem to be working as expected.

Prior to this change, I was able to edit the automatic update and add a
bugzilla ticket reference to it so that the EPEL 10 branch request
ticket would be closed when the update was pushed to stable.

Now, instead of having to add the bugzilla reference and push the
update to testing manually at the start of the update process, I need
to go and close the associated ticket manually at the end of the
process. It would be nice if this could be automated too.

Regards, Paul.

[Kevin Fenzi]

On Sat, Sep 07, 2024 at 04:11:07PM GMT, Paul Howarth wrote:
> On Fri, 6 Sep 2024 19:19:46 -0500
> Carl George  wrote:
> > We were able to get all of the in-between builds processed, and have
> > re-enabled the new compose method.  We've also re-enabled the build
> > targets, and verified that a new build got an automatic update that
> > moved to stable automatically, just like rawhide.  Builds that are
> > marked stable should be available in the buildroot as soon as the
> > regen-repo task finishes, and then composed nightly.  This pipeline
> > should stay the same until the official EPEL 10 launch in Q4.  That's
> > when we'll switch to the standard EPEL pipeline, with manually created
> > updates, a default one week testing period, and bodhi composes.
> >
> > Packagers can resume building for epel10 at their leisure.  Let us
> > know if anything doesn't seem to be working as expected.
>
> Prior to this change, I was able to edit the automatic update and add a
> bugzilla ticket reference to it so that the EPEL 10 branch request
> ticket would be closed when the update was pushed to stable.
>
> Now, instead of having to add the bugzilla reference and push the
> update to testing manually at the start of the update process, I need
> to go and close the associated ticket manually at the end of the
> process. It would be nice if this could be automated too.

See https://bodhi.readthedocs.io/en/latest/user/fedora-flavored-markdown.html

you can add rhbz#nnnnn to your changelog/git commit and bodhi will see
it and associate that bug with that update.

kevin

[Paul Howarth]

On Sat, 7 Sep 2024 09:09:49 -0700
Kevin Fenzi  wrote:
> On Sat, Sep 07, 2024 at 04:11:07PM GMT, Paul Howarth wrote:
> > On Fri, 6 Sep 2024 19:19:46 -0500
> > Carl George  wrote:
> > > We were able to get all of the in-between builds processed, and
> > > have re-enabled the new compose method.  We've also re-enabled
> > > the build targets, and verified that a new build got an automatic
> > > update that moved to stable automatically, just like rawhide.
> > > Builds that are marked stable should be available in the
> > > buildroot as soon as the regen-repo task finishes, and then
> > > composed nightly.  This pipeline should stay the same until the
> > > official EPEL 10 launch in Q4.  That's when we'll switch to the
> > > standard EPEL pipeline, with manually created updates, a default
> > > one week testing period, and bodhi composes.
> > >
> > > Packagers can resume building for epel10 at their leisure.  Let us
> > > know if anything doesn't seem to be working as expected.
> >
> > Prior to this change, I was able to edit the automatic update and
> > add a bugzilla ticket reference to it so that the EPEL 10 branch
> > request ticket would be closed when the update was pushed to stable.
> >
> > Now, instead of having to add the bugzilla reference and push the
> > update to testing manually at the start of the update process, I
> > need to go and close the associated ticket manually at the end of
> > the process. It would be nice if this could be automated too.
>
> See https://bodhi.readthedocs.io/en/latest/user/fedora-flavored-markdown.html
>
> you can add rhbz#nnnnn to your changelog/git commit and bodhi will see
> it and associate that bug with that update.

Yes, I do that for Fedora builds but EPEL is generally re-using the
same Fedora commits rather than creating new ones, and I like to keep
the branches in sync. I can live with it.

Regards, Paul.

[Carl George]

On Thu, Jul 4, 2024 at 2:45 AM Carl George  wrote:
> I originally posted this on Fedora Discussion [0], but I'm sharing it
> here as well for awareness.
>
> # Executive summary
>
> EPEL 10 is expected to be launched in Q4 of 2024.  You may start
> noticing parts of the infrastructure coming online sooner than that.
> **Please do not start creating EPEL 10 builds until we announce that
> we are ready for packagers to start building.**
>
> # Detailed description
>
> The EPEL Steering Committee has big plans for EPEL 10.  These plans
> are covered in detail in the original EPEL 10 proposal [1].  I also
> presented an EPEL 10 overview at the Fedora 40 release party [2].  At
> a high level, we are bringing minor versions to EPEL.  I encourage you
> to read the proposal or watch that video for a deeper explanation.
>
> I'm writing this post to share our planned timeline for EPEL 10, and
> to set expectations for the coming months.  Early CentOS Stream 10
> composes are already available [3], but it hasn't been officially
> launched yet because the content set is still in flux.  We expect to
> see the official launch announcement for CentOS Stream 10 later this
> year.  We intend to align the EPEL 10 launch with that, which will
> give us the following approximate timeline.
> August 2024: EPEL 10 hackfest at Flock [4] (see below for more details)
> Q4 2024: expected launch of CentOS Stream 10 and EPEL 10
> Q2 2025: expected launch of RHEL 10 (three years after RHEL 9)
>
> In the months ahead, you may notice parts of EPEL 10 infrastructure
> coming online, such as build targets in Koji and releases in Bodhi.
> We will need these infrastructure pieces in place to work out all of
> the details of integrating minor versions.  We'll send out an
> announcement when EPEL 10 is ready for package maintainers to start
> creating their builds.  **Please do not start creating EPEL 10 builds
> until we announce that we are ready for packagers to start building.**
>  Any builds created before this announcement may need to be discarded
> and rebuilt.
>
> I will be running an EPEL 10 Hackfest at Flock [4] in August (next
> month).  The plan is to work on various infrastructure pieces related
> to EPEL 10.  If we happen to have most of these pieces working prior
> to the hackfest, we can pivot our time to adding initial packages to
> EPEL 10.  I hope to see you there!
>
> [0] https://discussion.fedoraproject.org/t/epel-10-status-update/124549
> [1] https://discussion.fedoraproject.org/t/epel-10-proposal/44304
> [2] https://youtu.be/PxWxK5PgUuE
> [3] https://lists.centos.org/hyperkitty/list/[e-mail]/thread/QCO73...
> [4] https://flocktofedora.org/
>
> --
> Carl George

It's just about time for the official launch of EPEL 10.  I've created
a checklist of items [0] we need to complete for this.

We'll be turning off automatic bodhi updates soon as part of this
checklist, hopefully this week.  For maintainers, that means that when
you create an EPEL 10 build you'll need to create the bodhi update
yourself, just like you would for EPEL 9 or EPEL 8.  We'll also go
back to the default of seven days in the testing repo before updates
move to stable.  If you need to build closely related packages
together, you still have side tags [1] (preferred) and buildroot
overrides [2] at your disposal.

I also want to remind maintainers to check for bugs that have been
reported against your EPEL 10 packages.  We've identified several that
were built and released but are not installable.  Most of these have
had fail-to-install bugs filed already, and I intend to file bugs for
the rest of them.  If you get one of these bugs, please give it your
prompt attention so we can have the repo in a healthy state by the
time of the launch announcement.  If you don't think you'll be able to
resolve the installation problem within the next 5-10 days, reply as
such in the bug and I can untag the build to remove it from the repo.
The branch won't be retired, so as soon as you resolve the
installation problem it can be added back to the repo with a new
build.

[0] https://pagure.io/epel/issue/300
[1] https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guid...
[2] https://docs.fedoraproject.org/en-US/package-maintainers/Package_Update_Guid...