On Tue, Nov 17, 2020 at 1:21 PM Robbie Harwood <rharwood@xxxxxxxxxx> wrote: > > Matthew Miller <mattdm@xxxxxxxxxxxxxxxxx> writes: > > > On Fri, Nov 13, 2020 at 10:52:57PM +0100, Kevin Kofler via devel wrote: > >> > I completely agree. This is one of the reasons I switched away from > >> > ubuntu years ago (with its 4 (?) tiers of support + repos for its > >> > packages ...). > >> I agree, Fedora did the Core-Extras Merge back in the day for a reason. > > > > That reason was _mainly_ to erase the inside Red Hat, > > community-around-the-edges distinction. That was a huge success and Fedora > > wouldn't be interesting without that. But I think the _technical_ choice was > > in retrospect a mistake. There's a reason RHEL 8 switched the _other_ way. > > Respectfully, I don't agree with that. From a technical perspective, > the splitting of RHEL into many repos is awful to work with, and there > was no reason to suppose it would be otherwise. > > Suppose I depend on a package. That package could now come from any of > the following repositories (assuming I haven't forgotten any): > > - AppStream > - BaseOS > - CRB > - BuildRoot > - EPEL > > And that's just for me building things in BaseOS + AppStream, not even > any layered products. For me internally, these repos are all nearby, > but what if I weren't? Some come from Red Hat, some from CentOS, EPEL > (and ELN) from Fedora, ... > > This is painful to work with; I just need my package to build. From a > technical perspective, we need to consider the time lost due to trying > to configure machines and testing environments with the right repos, > the impossibility of figuring out what repo a package actually is > shipped in [1] (if it even is), etc.. > > And that doesn't even get into modularity - where there's another layer > of package non-discoverability. > > Also RHEL/EPEL policy currently means that "hidden" packages in RHEL > can't be exposed in EPEL - because that would be repackaging them. > > In summary, from a technical perspective, this is an unwieldy mess. > Nothing is gained from the packager's point of view or the end user's > point of view. The gains [2] are in the lifecycle and support realms - > firmly in business, not technical. > > So: no new repo splits please. The only distinction we should care > about is "Fedora" and "not Fedora", in my view - keep it simple and > approachable. I second what Robbie has said as well. I am against the thought of this change. As my team has found out within Red Hat, this repo split has been a large PITA. Because RHEL also won't self-host and many sub-packages are missing from released bits that are otherwise available in e.g., BUILDROOT, building our bits in COPR for QE to test has been an impossible battle. After close to a year, this use case still hasn't been enabled internally. Consider also what other groups such as COPR have to do to support repo splits. Yeah, it might be quick to split it in Koji and repo files, but the impact on other teams and contributors is a huge negative. If people have to go searching for special repos and dependencies to build their packages, the developer experience of Fedora will suffer more. That will push more people to Ubuntu. My 2c., Alex > > Thanks, > --Robbie > > 1: This is an issue with RHEL tools, in my view. > 2: I contend that hiding packages doesn't actually reduce support > burden, just hides it, but that's orthogonal to the conversation. > _______________________________________________ > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx > 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/devel@xxxxxxxxxxxxxxxxxxxxxxx _______________________________________________ devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx 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/devel@xxxxxxxxxxxxxxxxxxxxxxx
