On Tue, Jan 16, 2018 at 8:20 AM Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote:
On Tue, Jan 16, 2018 at 8:01 AM, Neal Gompa
> It's interesting that you bring this up, because SUSE elected to do
> this for the SLE 15 development[1]. All the sources are public, and
> while only a few things (a few bots and SUSE employees) can submit
> into SLE 15, it's been helping them with the Leap 15 development and
> for making sure stuff is properly synchronized between Factory (their
> equivalent of Rawhide), the openSUSE Leap 15 development tree, and the
> SUSE Linux Enterprise 15 development tree. Technically, I can
> indirectly contribute to SLE 15 through submitting change requests to
> the Leap 15 project, which has some interesting implications.
This is interesting, but I wonder how often we shoot ourselves in the
foot by comparing an idea to what someone else kind of already did
that's similar but not exactly the same. I'd rather see us take an
idea and evaluate what we, Fedora, want out of it. And I know we kill
ideas because of doubt, so let's not do that right now. Let's go
through the exercise and see if this is something that will be
beneficial and *worth* discussing with Red Hat rather than just
assuming it would be shot down.
> The holy grail would be allowing people to submit PRs that Red Hat
> folks could consider to include into RHEL 8, but honestly, I don't
> think it'll happen. I even doubt we'd be able to have EL branches of
> packages merged into Dist-Git. And mirroring CentOS branches is not
> particularly useful (though their Git frontend is garbage...), a link
> to the package in CentOS Git would be sufficient for people to find
> the equivalent in CentOS for Fedora packages.
So a few specific theoretical benefits would be:
- Better Git frontend for CentOS
- Possibility to submit PRs against RHEL branches
- Easy to see changes from RHEL and Fedora (and CentOS).
What are some others?
Having such branches available could help with EPEL as well. In RHEL 7, we had no official python3 packages in the main repositories, so EPEL 7 tended to carry them. Having an EPEL branch that can easily pull from the RHEL/CentOS branch and apply just the diff necessary to build the missing pieces would be very handy (and easier on maintainers to keep up-to-date). This in turn might lead to people being more inclined to maintain things in EPEL.
_______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
