Thanks for looking over the plan Kevin.
1. I wasn't planning any changes for bugzilla. I think it's appropriate for
the bug reports to be filed against the epel8 component. Typically there
should be an epel8 branch already when an epel8-next branch is requested. The
only exception I can imagine is if a package has a dependency on a package that
is in CentOS Stream but isn't in a RHEL GA release yet. Even then, it would
only be a temporary situation, because within six months that package would
make it into RHEL and then the package should be built in epel8, not
epel8-next. Do you think it would be worthwhile for fedscm-admin to enforce a
requirement of an epel8 branch before allowing the creation of an epel8-next
branch?
I think if it's easy/possible to make it reject epel8-next and
epel8-playground branches when a package doesn't have a epel8 branch that
would be nice. I am not sure this is required however, as you note it
should be a pretty rare case...
2. I'm perfectly fine waiting until after F33 is done. That makes lots of
sense.
Cool. Thanks
kevin
--
On Sat, Oct 3, 2020 at 12:07 PM Kevin Fenzi <kevin(a)scrye.com> wrote:
>
> On Thu, Oct 01, 2020 at 11:12:28PM -0500, Carl George wrote:
> > Here is my rough outline of the steps required to implement this proposal.
> > I imagine things would happen roughly in this order, but some things could
> > probably take place in parallel.
> >
> > 1. EPEL Steering Committee approves the proposal
> > 2. koji changes:
> > - create CentOS Stream 8 external repo
> > - create epel8-next build target (inheriting from epel8)
> > - dist macro override for that target
> > 3. create PDC entries
> > 4. update fedscm-admin with branch SLAs
> > 5. configure dist-git to allow branch name
> > 6. update pungi config
> > 7. add epel-next-repo subpackage to epel-release
> > 8. add epel8-next release in bodhi
> > 9. document in the wiki
> > 10. announcement email
> >
> > Please let me know if I'm missing anything.
>
> Looks pretty good to me, but two things:
>
> 1. I assume (but good to ask) that we are not going to change anything
> in bugzilla? ie, bug reports should just go against the epel component?
> Of course now that playground is 'seperate' and next will also be, would
> we ever have cases where we have a component without epel branch, but
> with playground and/or next? And what would we do for bugs there?
>
> 2. We are heading into final freeze for Fedora 33 next tuesday, so not
> sure how much will get done until f33 is out the door. Is it ok to do
> this after? Some of it could be done with freeze breaks and such, but
> might be easier just to do it all at once after f33 freeze is over?
>
> Thanks much for putting this together!
>
> kevin
> --
>
> >
> > On Wed, Sep 23, 2020 at 8:43 PM Carl George <carl(a)redhat.com> wrote:
> > >
> > > I agree, using .el8.next for the dist macro makes the most sense. This
will
> > > enable maintainers to use a similar workflow to Fedora branches, where
older
> > > branches can be fast forwarded, and the same commit can be built for
> > > different targets but still have different NVRs in Koji. Here is an
example
> > > workflow for a fictional foo package that already exists in Fedora.
> > >
> > > - request epel8 branch
> > > - merge master branch to epel8 branch
> > > - build epel8 branch, resulting in foo-1-1.el8
> > > - realize it won't install on CentOS Stream due to a library
difference
> > > - request epel8-next branch
> > > - merge epel8 branch to epel8-next branch
> > > - build epel8-next branch, resulting in foo-1-1.el8.next
> > >
> > > After the next RHEL 8 minor release (when that library difference affects
> > > everyone), the maintainer can increment the release on the epel8 branch
and
> > > proceed as usual.
> > >
> > > On Sun, Sep 20, 2020 at 1:31 PM Kevin Fenzi <kevin(a)scrye.com>
wrote:
> > > >
> > > > On Wed, Sep 16, 2020 at 09:54:00PM -0500, Carl George wrote:
> > > > > At the EPEL Steering Committee last week, we had an extensive
discussion of
> > > > > this proposal, specifically focused on how to handle the dist
macro. I
> > > > > believe these are the possible choices.
> > > > >
> > > > > * keep dist the same as epel8 (.el8)
> > > > >
> > > > > RHEL, CentOS Linux, CentOS Stream, and EPEL are all currently
using .el8 for
> > > > > dist. It would make sense to continue using the same dist for
EPEL Next.
> > > > > However, this would put a little more work on packagers. They
would not be
> > > > > able to build the same commit for both EPEL and EPEL Next
because the NVR
> > > > > will conflict in Koji. In simple rebuild situations, this is
not a problem
> > > > > because at a minimum the release will be higher. But if a
packager wanted
> > > > > to update the package in both EPEL and EPEL Next, they will need
to first
> > > > > update and build it in EPEL, then bump the release and build it
in EPEL
> > > > > Next. This isn't ideal, but isn't terrible either, and
can be partially
> > > > > mitigated by good documentation around EPEL Next workflows.
> > > > >
> > > > > * modify dist to always be higher than epel8 (.el8.next or
similar)
> > > > >
> > > > > In EPEL Next we could define dist to a string that RPM evaluates
higher than
> > > > > .el8, such as .el8.next. This would allow EPEL and EPEL Next
branches to be
> > > > > in sync and the same commit could be built for both targets.
The higher
> > > > > dist would ensure the upgrade path works.
> > > >
> > > > I think this makes the most sense and will help packages workflows
the
> > > > best.
> > > >
> > > > kevin
> > > > _______________________________________________
> > > > epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
> > > > To unsubscribe send an email to
epel-devel-leave(a)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/epel-devel@lists.fedoraproj...
> > >
> > >
> > >
> > > --
> > > Carl George
> >
> >
> >
> > --
> > Carl George
> > _______________________________________________
> > epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
> > To unsubscribe send an email to epel-devel-leave(a)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/epel-devel@lists.fedoraproj...
> _______________________________________________
> epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
> To unsubscribe send an email to epel-devel-leave(a)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/epel-devel@lists.fedoraproj...
--
Carl George
_______________________________________________
epel-devel mailing list -- epel-devel(a)lists.fedoraproject.org
To unsubscribe send an email to epel-devel-leave(a)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/epel-devel@lists.fedoraproj...