Re: Summary/Minutes from today's FESCo Meeting (2020-11-11)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.

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.

Attachment: signature.asc
Description: PGP signature

_______________________________________________
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

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Fedora Announce]     [Fedora Users]     [Fedora Kernel]     [Fedora Testing]     [Fedora Formulas]     [Fedora PHP Devel]     [Kernel Development]     [Fedora Legacy]     [Fedora Maintainers]     [Fedora Desktop]     [PAM]     [Red Hat Development]     [Gimp]     [Yosemite News]

  Powered by Linux