On Tue, Jan 16, 2018 at 8:18 AM, Josh Boyer jwboyer@fedoraproject.org wrote:
On Tue, Jan 16, 2018 at 8:01 AM, Neal Gompa ngompa13@gmail.com wrote:
On Sat, Jan 13, 2018 at 12:39 PM, Matthew Miller mattdm@fedoraproject.org wrote:
On Sat, Jan 13, 2018 at 10:40:36AM +0100, Kevin Kofler wrote:
That's just all the more reason to publish the branched packages in CentOS Git as soon as they're branched, or even maintain them in Fedora dist-git. But I'm not holding my breath for it to happen any time soon.
I wouldn't suggest holding breath, exactly, but let's entertain the idea. (I mean, at the very least, hey, it's open source, and we could import branches from CentOS dist-git if we found a benefit from it....)
If we did this in Fedora dist-git, how would people feel about having a RHEL/CentOS branch which is effectively owned by the company? Since the Core/Extras merge, we've striven to avoid cases where Red Hat has special access. This wouldn't introduce any regression in that to Fedora-OS branches themselves, but there would be some "company-specialness" which we've kept away from. Is that okay?
(just a nit, but I think you mean "strived")
Didn't we *just* lose this functionality (per branch ACLs) when we moved to Pagure? That being said, while I would *love* for RHEL branches to be part of the Fedora Dist-Git, I really doubt it would happen. That said, syncing in the CentOS branches into the tree would be interesting, and make it much easier to see where things lie w.r.t. changes between Fedora and RHEL.
I was wondering about the ACLs myself.
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.
I do the comparisons because I want us to be able to learn from what other people do. The goal is to take the idea, and do it better. For example, SUSE's model has an indirect contribution model. A way for us to improve on the idea is to allow PRs to directly contribute improvements to EL branches.
As for the doubts, I just didn't want to get my hopes up... But I definitely have wishes about what I would like to see, as I outlined.
At first, I missed it. Then I read it, and I blinked in disbelief. Then I decided to write a response, and then forgot to send it. Now I sent it. :)
Well, I'm glad you did. At least the conversation is flowing.
Indeed. I think there's an interesting opportunity here.
On Tue, Jan 16, 2018 at 8:35 AM, Stephen Gallagher sgallagh@redhat.com wrote:
On Tue, Jan 16, 2018 at 8:20 AM Josh Boyer jwboyer@fedoraproject.org wrote:
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.
It's not just this, though. Packages transition between EPEL and RHEL quite a bit, and if it were as simple as just renaming a branch and changing the ACLs, that would make things much better. Also, it would bring some more consistency to how EPEL operates and less surprises. I know one of the reasons I don't do too many packages in EPEL anymore is because I get surprised too often by what RHEL does. It's just not worth it to deal with that mess unless someone really wants it.