On Tue, Jan 16, 2018 at 8:18 AM, Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> wrote: > On Tue, Jan 16, 2018 at 8:01 AM, Neal Gompa <ngompa13@xxxxxxxxx> wrote: >> On Sat, Jan 13, 2018 at 12:39 PM, Matthew Miller >> <mattdm@xxxxxxxxxxxxxxxxx> 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@xxxxxxxxxx> wrote: > > On Tue, Jan 16, 2018 at 8:20 AM Josh Boyer <jwboyer@xxxxxxxxxxxxxxxxx> > 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. -- 真実はいつも一つ！/ Always, there's only one truth! _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
