Following is the list of topics that will be discussed in the FESCo meeting Wednesday at 15:00UTC in #fedora-meeting-2 on irc.freenode.net.
To convert UTC to your local time, take a look at http://fedoraproject.org/wiki/UTCHowto
or run: date -d '2020-11-11 15:00 UTC'
Links to all issues to be discussed can be found at: https://pagure.io/fesco/report/meeting_agenda
= Discussed and Voted in the Ticket =
Move the FESCo meeting +1 hour (to 15:00 UTC) when DST is not in action https://pagure.io/fesco/issue/2496 APPROVED (+6, 2, -0)
F35 System-Wide Change: Python 3.10 https://pagure.io/fesco/issue/2494 APPROVED (+8, 0, -0)
Nonresponsive maintainer: Mark Chappell (tremble) https://pagure.io/fesco/issue/2492 APPROVED (+4, 0, -0)
Nonresponsive maintainer: Marek Cermak macermak https://pagure.io/fesco/issue/2491 APPROVED (+3, 0, -0)
= New business =
#2495 Election Interview Questions — FESCo (Fedora 33) https://pagure.io/fesco/issue/2495
#2475 proposal: let's develop the idea of a new repo for lightly-maintained packages https://pagure.io/fesco/issue/2475
#2473 updates policy is out of date https://pagure.io/fesco/issue/2473
= Open Floor =
For more complete details, please visit each individual issue. The report of the agenda items can be found at https://pagure.io/fesco/report/meeting_agenda
If you would like to add something to this agenda, you can reply to this e-mail, file a new issue at https://pagure.io/fesco, e-mail me directly, or bring it up at the end of the meeting, during the open floor topic. Note that added topics may be deferred until the following meeting.
===================================== #fedora-meeting-2: FESCO (2020-11-11) =====================================
Meeting started by dcantrell at 15:00:45 UTC. The full logs are available at https://meetbot.fedoraproject.org/fedora-meeting-2/2020-11-11/fesco.2020-11-... .
Meeting summary --------------- * init process (dcantrell, 15:00:48) * Igor is alive, but busy (mhroncok, 15:07:00)
* #2495 Election Interview Questions — FESCo (Fedora 33) (dcantrell, 15:08:05) * ACTION: dcantrell followup with bcotton regarding election question gathering process (dcantrell, 15:14:31)
* #2475 proposal: let's develop the idea of a new repo for lightly-maintained packages (dcantrell, 15:16:41)
* #2473 updates policy is out of date (dcantrell, 15:20:08) * ACTION: nirik to followup with qa and devel list re: 2473 (dcantrell, 15:28:03)
* Next week's chair (dcantrell, 15:29:02) * ACTION: zbyszek will chair next meeting (dcantrell, 15:29:47)
* Open Floor (dcantrell, 15:29:57)
Meeting ended at 15:31:45 UTC.
Action Items ------------ * dcantrell followup with bcotton regarding election question gathering process * nirik to followup with qa and devel list re: 2473 * zbyszek will chair next meeting
Action Items, by person ----------------------- * dcantrell * dcantrell followup with bcotton regarding election question gathering process * nirik * nirik to followup with qa and devel list re: 2473 * zbyszek * zbyszek will chair next meeting * **UNASSIGNED** * (none)
People Present (lines said) --------------------------- * dcantrell (63) * mhroncok (28) * King_InuYasha (22) * nirik (21) * zbyszek (14) * zodbot (13) * decathorpe (5) * sgallagh (1) * ignatenkobrain (0) * Conan_Kudo (0) * Eighth_Doctor (0) * cverna (0) * Sir_Gallantmon (0) * Son_Goku (0) * Pharaoh_Atem (0)
Generated by `MeetBot`_ 0.1.4
.. _`MeetBot`: http://wiki.debian.org/MeetBot
Dne 11. 11. 20 v 16:47 David Cantrell napsal(a):
- #2475 proposal: let's develop the idea of a new repo for
lightly-maintained packages (dcantrell, 15:16:41)
For the record - the initial ticket can be found here: https://pagure.io/fesco/issue/2475
We already have "lightly-maintained packages" - it is called Copr projects. Do we need something in between?
On Wed, Nov 11, 2020 at 06:05:20PM +0100, Miroslav Suchý wrote:
Dne 11. 11. 20 v 16:47 David Cantrell napsal(a):
- #2475 proposal: let's develop the idea of a new repo for
lightly-maintained packages (dcantrell, 15:16:41)
For the record - the initial ticket can be found here: https://pagure.io/fesco/issue/2475
We already have "lightly-maintained packages" - it is called Copr projects. Do we need something in between?
Yeah, because we want those packages to be available as build dependencies. So coprs are out (unless we allow pulling in coprs into the koji buildroot, which I don't think we should.)
Instead of a separate maintained repo, I'd go for a "Requires" or "Provides" tag on packages instead. This would be easier to implement (packagers could just add this as any other Requires), and we could easily tweak dnf to emit a warning or require a special option before those packages were installed on the end user system.
Zbyszek
* Miroslav Suchý [11/11/2020 18:05] :
We already have "lightly-maintained packages" - it is called Copr projects. Do we need something in between?
The issue here is discoverabilty. If $PACKAGE is in a separate repository, be it a 'lightly-maintained' repo or a copr, how do we go about communicating to users wanting to install it that they need to activate that repository and that the software they download from it may or may not work?
Emmanuel
David Cantrell wrote:
- #2475 proposal: let's develop the idea of a new repo for
lightly-maintained packages (dcantrell, 15:16:41)
This suggestion keeps coming up again and again, but the repetition does not make it any more practical. A small handful individual maintainers wants to use some library/infrastructure package(s) for their package builds, but at the same time excuse themselves from actually maintaining those library/infrastructure package(s). This may be more convenient to the minority that gets to "lightly maintain" those packages, but at the cost of offloading technical debt to the entire remainder of the community, both the majority of maintainers (who would benefit from having the library/infrastructure package(s) fully maintained as a potential build and/or runtime dependency of their own package(s)) and the end users (who would benefit from having the library/infrastructure package(s) fully maintained to build local software, and in some cases, such as Tomcat, also to use them directly).
I still believe that this concept is inherently incompatible with the idea of a cooperative community distribution, and that bringing it up again and again with minimally changed wording is not a constructive thing to do.
I can see why RHEL has a business case for having such "second-class citizen" packages, but this is not how Fedora works or should work.
Kevin Kofler
On Fri, Nov 13, 2020 at 12:07:29AM +0100, Kevin Kofler via devel wrote:
I still believe that this concept is inherently incompatible with the idea of a cooperative community distribution, and that bringing it up again and again with minimally changed wording is not a constructive thing to do.
I can see why RHEL has a business case for having such "second-class citizen" packages, but this is not how Fedora works or should work.
Well, except, it clearly *does* work that way. We have many lightly-maintained packages in practice. I think it's better to label them as such and find positive ways to encourage the collaboration I think we all agree is best, rather than the current state where we basically just pretend that everything is maintained with high attention.
Matthew Miller wrote:
Well, except, it clearly *does* work that way. We have many lightly-maintained packages in practice.
Do we really? Which are those packages?
The one that keeps getting brought up is Tomcat, but I can tell you from my personal experience that the Fedora Tomcat package has always been working just fine (not only as a build dependency, but for its intended use as a web application server: I use it to locally test Java web applications).
I think it's better to label them as such and find positive ways to encourage the collaboration I think we all agree is best, rather than the current state where we basically just pretend that everything is maintained with high attention.
I think that if a maintainer is not able to offer a package the attention they think it needs, they should ask for help, not mark the package as unsupported or hidden. That is how the collaborative approach is supposed to work.
Now, if no help shows up, that can only mean one of two things: * either the package is actually working so well that no help is really needed, * or nobody actually cares enough about the package to give it more attention. In both cases, the package is working well enough for what is actually needed and there is no need to give it any special marking.
But the situation into which we want to get is that the help is not only requested by the maintainer, but that comaintainers actually sign up for it. But that requires upholding a cooperative environment. Privatizing build dependencies by marking them as "lightly maintained" achieves the exact opposite.
Kevin Kofler
On Fri, Nov 13, 2020 at 12:52:06AM +0100, Kevin Kofler via devel wrote:
Matthew Miller wrote:
Well, except, it clearly *does* work that way. We have many lightly-maintained packages in practice.
Do we really? Which are those packages?
Every single package that failed to build from source and that people refused to see orphaned and retired when it was pointed out that they are in fact not really maintained ?
Pierre
On Fri, Nov 13, 2020 at 09:58:22AM +0100, Pierre-Yves Chibon wrote:
On Fri, Nov 13, 2020 at 12:52:06AM +0100, Kevin Kofler via devel wrote:
Matthew Miller wrote:
Well, except, it clearly *does* work that way. We have many lightly-maintained packages in practice.
Do we really? Which are those packages?
Every single package that failed to build from source and that people refused to see orphaned and retired when it was pointed out that they are in fact not really maintained ?
Those packages are automatically removed from Rawhide. Aren't they?
-- Petr
On Fri, Nov 13, 2020 at 10:11:28AM +0100, Petr Pisar wrote:
On Fri, Nov 13, 2020 at 09:58:22AM +0100, Pierre-Yves Chibon wrote:
On Fri, Nov 13, 2020 at 12:52:06AM +0100, Kevin Kofler via devel wrote:
Matthew Miller wrote:
Well, except, it clearly *does* work that way. We have many lightly-maintained packages in practice.
Do we really? Which are those packages?
Every single package that failed to build from source and that people refused to see orphaned and retired when it was pointed out that they are in fact not really maintained ?
Those packages are automatically removed from Rawhide. Aren't they?
Now, yes (irc).
Pierre
Pierre-Yves Chibon wrote:
Every single package that failed to build from source and that people refused to see orphaned and retired when it was pointed out that they are in fact not really maintained ?
As I have already mentioned more than once when the FTBFS policy has been discussed, a failure to build from source is not necessarily a fatal bug. If the package has no broken dependencies and needs no changes, there is no actual need to rebuild the package. Hence, I find it unfair to call packages "not really maintained" just because a FTBFS was not fixed immediately. (Even the policy allows for 6+ months to fix FTBFS bugs.)
I prefer spending my time on making actual user-visible improvements to my packages rather than on fixing yet another mass FTBFS caused by a rude incompatible change done in some other package.
Kevin Kofler
* Kevin Kofler via devel [13/11/2020 00:52] :
The one that keeps getting brought up is Tomcat, but I can tell you from my personal experience that the Fedora Tomcat package has always been working just fine (not only as a build dependency, but for its intended use as a web application server: I use it to locally test Java web applications).
I suspect this isn't sufficient a test to determine if a package is well maintained or not. At a minimum, you also need to look at CVEs for which fixes have not being pushed.
Emmanuel
Emmanuel Seyman wrote:
- Kevin Kofler via devel [13/11/2020 00:52] :
The one that keeps getting brought up is Tomcat, but I can tell you from my personal experience that the Fedora Tomcat package has always been working just fine (not only as a build dependency, but for its intended use as a web application server: I use it to locally test Java web applications).
I suspect this isn't sufficient a test to determine if a package is well maintained or not. At a minimum, you also need to look at CVEs for which fixes have not being pushed.
I see Tomcat CVE fixes getting pushed regularly, though I have not attempted to quantify the exact time it takes for an upstream security fix to go out to Fedora.
Kevin Kofler
On Thu, 12 Nov 2020 at 18:53, Kevin Kofler via devel < devel@lists.fedoraproject.org> wrote:
Matthew Miller wrote:
Well, except, it clearly *does* work that way. We have many lightly-maintained packages in practice.
Do we really? Which are those packages?
The one that keeps getting brought up is Tomcat, but I can tell you from my personal experience that the Fedora Tomcat package has always been working just fine (not only as a build dependency, but for its intended use as a web application server: I use it to locally test Java web applications).
The following is to give hypothetical answers to your question about which packages are lightly-maintained. This isn't a statement that they should be split into a light repository but that they are probably not getting the attention that strongly maintained packages have.
1. Any set of packages greater than 5 being maintained by a single packager. There is only so much attention a person can give to software and work with either fixing things directly or pushing those bugs upstream. 2. Any package that has a statistically larger number than the 'average' untouched bugzilla tickets at the autoclose period. 3. Various packages which no-one wants to maintain but end up just in a person's queue because it's a build dependency for the chain of things they do care about.
Again I am not saying that they should go into a different repository.. but we have to recognize that they do exist versus constantly sweeping them under the rug with a 'oh that never happens' or a 'I don't see why someone else can't maintain it' or 'if I write enough angry emails to the list someone will pick it up to shut me up.' [All of which I believe i have been guilty of at some point in the last 25 years of working on distros.]
I think it's better to label them as such and find positive ways to encourage the collaboration I think we all agree is best, rather than the current state where we basically just pretend that everything is maintained with high attention.
I think that if a maintainer is not able to offer a package the attention they think it needs, they should ask for help, not mark the package as unsupported or hidden. That is how the collaborative approach is supposed to work.
Now, if no help shows up, that can only mean one of two things:
- either the package is actually working so well that no help is really needed,
- or nobody actually cares enough about the package to give it more attention.
or 3. Nobody wants to take up that responsibility because they feel maxed out already. 4. The package is a complete piece of crap to work with, but fixing it only brings up a long list of complaints from certain people who no one wants to have unless they are paid a lot of money to do so. 5. Everyone wants it to be someone else's problem.
We are at the other side of the bell curve of people interested in working on operating systems. There are a larger number of people who have packages but aren't part of Fedora anymore and their emails bouncing or dev/null than we had in the past. We are not seeing a lot of new people coming in... so the number of packages per packager is going to go up.
In both cases, the package is working well enough for what is actually needed and there is no need to give it any special marking.
But the situation into which we want to get is that the help is not only requested by the maintainer, but that comaintainers actually sign up for it. But that requires upholding a cooperative environment. Privatizing build dependencies by marking them as "lightly maintained" achieves the exact opposite.
Kevin Kofler
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On Thu, Nov 12, 2020, 4:15 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Nov 13, 2020 at 12:07:29AM +0100, Kevin Kofler via devel wrote:
I still believe that this concept is inherently incompatible with the
idea
of a cooperative community distribution, and that bringing it up again
and
again with minimally changed wording is not a constructive thing to do.
I can see why RHEL has a business case for having such "second-class citizen" packages, but this is not how Fedora works or should work.
Well, except, it clearly *does* work that way. We have many lightly-maintained packages in practice. I think it's better to label them as such and find positive ways to encourage the collaboration I think we all agree is best, rather than the current state where we basically just pretend that everything is maintained with high attention.
I'm not sure anyone's pretending.
In my experience distros that spilt up into many repos add complexity (and mistakes) on the releng side and a poor UX for the users.
If we had labels in Pagure for the packages that you consider to be troublesome, would that help?
- Ken
On Fri, Nov 13, 2020 at 2:52 PM Ken Dreyer ktdreyer@ktdreyer.com wrote:
On Thu, Nov 12, 2020, 4:15 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Nov 13, 2020 at 12:07:29AM +0100, Kevin Kofler via devel wrote:
I still believe that this concept is inherently incompatible with the idea of a cooperative community distribution, and that bringing it up again and again with minimally changed wording is not a constructive thing to do.
I can see why RHEL has a business case for having such "second-class citizen" packages, but this is not how Fedora works or should work.
Well, except, it clearly *does* work that way. We have many lightly-maintained packages in practice. I think it's better to label them as such and find positive ways to encourage the collaboration I think we all agree is best, rather than the current state where we basically just pretend that everything is maintained with high attention.
(snip)
I'm not sure anyone's pretending.
In my experience distros that spilt up into many repos add complexity (and mistakes) on the releng side and a poor UX for the users.
If we had labels in Pagure for the packages that you consider to be troublesome, would that help?
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 ...).
While I think SIGs would be appropriate for sharing maintenance of dependencies of a certain stack, what I thought about recently was to give those packages to a "nursery" user (similar to an "orphan" user), which would keep them safe from removal, but mark them as "do not remove, but no single user is responsible for this".
Fabio
Fabio Valentini 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.
Kevin Kofler
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.
Hi
On Fri, Nov 13, 2020 at 5:23 PM Matthew Miller wrote:
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.
I think for a community distro, having it all in a single repo is technically better as well because part of the problem that was being solved by the merge was not just the community Red Hat delineation but also the issue of build dependencies - core packages couldn't depend on packages from extras and by splitting up repos again you will reintroduce the same problems. So don't do that. What you need is some metadata and the capability for the client tooling to expose that metadata so users can make informed choices on what they are installing and that can be as flexible as you want it to be. apt-listbugs etc does similar things.
Rahul
On Fri, Nov 13, 2020 at 05:46:46PM -0500, Rahul Sundaram wrote:
I think for a community distro, having it all in a single repo is technically better as well because part of the problem that was being solved by the merge was not just the community Red Hat delineation but also the issue of build dependencies - core packages couldn't depend on packages from extras and by splitting up repos again you will reintroduce the same problems. So don't do that. What you need is some metadata and the
But that's policy as well. It would be reasonable to have a different policy, like "build and soft dependencies are okay from base -> secondary, but not hard runtime requirements".
... but anyway:
capability for the client tooling to expose that metadata so users can make informed choices on what they are installing and that can be as flexible as you want it to be. apt-listbugs etc does similar things.
Yeah, a metadata-based approach works for me as well.
Hi
On Fri, Nov 13, 2020 at 5:54 PM Matthew Miller mattdm@fedoraproject.org wrote:
On Fri, Nov 13, 2020 at 05:46:46PM -0500, Rahul Sundaram wrote:
I think for a community distro, having it all in a single repo is technically better as well because part of the problem that was being solved by the merge was not just the community Red Hat delineation but
also
the issue of build dependencies - core packages couldn't depend on
packages
from extras and by splitting up repos again you will reintroduce the same problems. So don't do that. What you need is some metadata and the
But that's policy as well. It would be reasonable to have a different policy, like "build and soft dependencies are okay from base -> secondary, but not hard runtime requirements".
Partly yes, some of it could be solved by policy but we didn't have soft dependency capability back then so we were limited even more technically but even now, you are proposing not having cross repo runtime deps which also will end up being problematic. Using metadata for this allows you to do well supported, lightly supported and the notion of playground etc all in one repo and if a package gets better, you can just update the metadata without having to move around packages which is a pain point for all the mirrors.
Rahul
Matthew Miller wrote:
But that's policy as well. It would be reasonable to have a different policy, like "build and soft dependencies are okay from base -> secondary, but not hard runtime requirements".
But a build-time dependency often automatically results in a hard runtime dependency, e.g., for C/C++ libraries.
A common issue in the Core vs. Extras days was that a package in Core had to be compiled without some compile-time-optional feature because that feature would have depended on a library in Extras. The above proposal would not solve this issue.
Kevin Kofler
Matthew Miller wrote:
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.
Well, I was around in the old split days and I remember all the headaches around the lines of "package X cannot be built against library Y because X is in Core whereas Y is in Extras" and all the ugly workarounds we had for such issues. Having one unified repository helped a lot to resolve those very technical issues.
Kevin Kofler
On Fri, Nov 13, 2020 at 3:23 PM Matthew Miller mattdm@fedoraproject.org wrote:
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.
It's true that RHEL 8 split content into BaseOS and AppStream, but the technical reasons for that particular split were never clear to me.
For example, Fedora users (and release engineers, etc) would have to add multiple repos into kickstarts instead of one.
- Ken
Ken Dreyer wrote:
On Fri, Nov 13, 2020 at 3:23 PM Matthew Miller mattdm@fedoraproject.org wrote:
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.
It's true that RHEL 8 split content into BaseOS and AppStream, but the technical reasons for that particular split were never clear to me.
As far as I know, all the splitting done in RHEL, also the individual modules within the modular AppStream repository, is done mainly for business reasons that do not apply to Fedora at all.
Kevin Kofler
Matthew Miller mattdm@fedoraproject.org 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.
On Tue, Nov 17, 2020 at 1:21 PM Robbie Harwood rharwood@redhat.com wrote:
Matthew Miller mattdm@fedoraproject.org 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@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On Wed, Nov 18, 2020 at 03:37:11PM -0500, Alexander Scheel wrote:
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.
But that's not what's being proposed. We've had different repos in Fedora for years -- the main repo, plus updates, plus updates-testing. And we have the separate modularity one now. Fedora is going to continue to self-host, and doesn't have whatever business reason RHEL has for not shipping the buildroot.
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.
I'm not suggesting anything that would require anyone to "go searching for special repos".
All that said, I think we can implement something that serves the purpose I'm looking for as metadata.
Matthew Miller mattdm@fedoraproject.org writes:
On Wed, Nov 18, 2020 at 03:37:11PM -0500, Alexander Scheel wrote:
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.
But that's not what's being proposed.
Isn't it? Some packages go in main, and others go in light (or whatever it'd be called)?
We've had different repos in Fedora for years -- the main repo, plus updates, plus updates-testing. And we have the separate modularity one now. Fedora is going to continue to self-host, and doesn't have whatever business reason RHEL has for not shipping the buildroot.
I think that conflates uses of the word "different".
The package sets between main/updates/updates-testing are not meaningfully different: almost all packages in updates/updates-testing already have a version in main. That is, you would have a complete system with pretty much every package available just by setting up main.
That's of course not how RHEL-style repo separation works: packages in AppStream, for instance, or BuildRoot, are wholly disjoint from those in BaseOS. (This is also how generalized modules behave.)
What I believe Alex and I are arguing is that there is no technical advantage to RHEL-style repo-splitting where some packages go in one repo and a non-overlapping set goes in another. Rather, it incurs a large burden both on maintainers and end-users.
Thanks, --Robbie
On Thu, Nov 19, 2020 at 03:04:26PM -0500, Robbie Harwood wrote:
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.
But that's not what's being proposed.
Isn't it? Some packages go in main, and others go in light (or whatever it'd be called)?
Right, it is not. there's no "many sub-packages are missing from released bits that are otherwise available". In fact, going back to the beginning, making such packages _available_ is exactly the intention. So it's the opposite.
We've had different repos in Fedora for years -- the main repo, plus updates, plus updates-testing. And we have the separate modularity one now. Fedora is going to continue to self-host, and doesn't have whatever business reason RHEL has for not shipping the buildroot.
I think that conflates uses of the word "different".
The package sets between main/updates/updates-testing are not meaningfully different: almost all packages in updates/updates-testing already have a version in main. That is, you would have a complete system with pretty much every package available just by setting up main.
Okay, fair enough. But still, it's not like "there's more than one repo" is suddenly new science.
On Thu, Nov 19, 2020 at 03:04:26PM -0500, Robbie Harwood wrote:
What I believe Alex and I are arguing is that there is no technical advantage to RHEL-style repo-splitting where some packages go in one repo and a non-overlapping set goes in another. Rather, it incurs a large burden both on maintainers and end-users.
Remember, I'm trying to solve a real problem here:
Some packagers in Fedora do not have time to maintain the build dependencies for the packages that they are actually interested in and have time to build. The RHEL solution is to not ship those. The packagers don't feel good about just dumping the — as we've said, "lightly maintained" — deps into the package collection. They'd feel better _not packaging the main packages in Fedora at all_. This is not a good outcome. I'd like to find a better approach, and having a repo for these things (which, as I've said, unlike RHEL, we'd absolutely ship) is one idea that came to mind.
However, I'm not stuck on that one and it's probably not useful to stay stuck on it if there's not enough support to do it. So, let's find a different solution.
One approach suggested was a tag in spec files themselves.
Another one might be to have metadata in a separate file in dist-git.
Another would be to have an external service which maintains the list — like PDC does for "critical path" packages.
Such a system could also be used for other things, like defining a minimal core which we'd want to apply greater CI gating and scrutiny to. (Maybe the existing critical path set is a good start, but I'm thinking something that starts smaller.)
* Matthew Miller [19/11/2020 17:13] :
Some packagers in Fedora do not have time to maintain the build dependencies for the packages that they are actually interested in and have time to build.
I suspect that these packages are maintained only to the point where they can build (and thus be used as buildreqs) but their maintainer also doesn't want them to be updated without making sure that the update will not break the package they are really interested in.
However, I'm not stuck on that one and it's probably not useful to stay stuck on it if there's not enough support to do it. So, let's find a different solution.
What exactly do you want to do with this list of lightly-maintained packages?
Is this something you want to present to end-users? Is this a list we should show to people tempted to become packagers? Do we want to generate auto-replies to bugs filed in Bugzilla? Should SIGs keep a lookout for security fixes to apply?
I suspect we'll only be able to determine the best approach if we know what problem you're trying to solve.
Emmanuel
Emmanuel Seyman emmanuel@seyman.fr writes:
However, I'm not stuck on that one and it's probably not useful to stay stuck on it if there's not enough support to do it. So, let's find a different solution.
What exactly do you want to do with this list of lightly-maintained packages?
I have been wondering this myself: what advantage will this bring, besides a bit more peace of mind for the maintainer?
I'd also like to point out that we actually have a concept for lightly maintained packages that cannot reach end users: modularity. I know its not popular, but it would be an option for this. However, I wouldn't be a fan if it being used like this.
Cheers,
Dan
I'm opposed to this change as well, due to, imo, making it harder/less obvious/more confusing to see where I have to pull from any given package that I want to consume as an end-user on my system, or as a package maintainer in my buildroot.
I've however found myself having to maintain packages that I only needed as builddeps for the packages that I really care about. So that's definitely not ideal, however:
I like the notion of a 'metadata-based' approach, where labels are added to packages (or rather, their respective dist-git repos) that potentially fall under the 'lightly maintained' category.
These labels could be processed by the distro internally and acted upon accordingly in some way, but I certainly don't want that maintenance status to manifest in the package being made available in one repo or the other (and even potentially moving from one to the other between releases per changes in their apparent quality of maintenance).
Cheers,
Christian
On Fri, Nov 20, 2020 at 12:44 AM Dan Čermák dan.cermak@cgc-instruments.com wrote:
Emmanuel Seyman emmanuel@seyman.fr writes:
However, I'm not stuck on that one and it's probably not useful to stay stuck on it if there's not enough support to do it. So, let's find a different solution.
What exactly do you want to do with this list of lightly-maintained packages?
I have been wondering this myself: what advantage will this bring, besides a bit more peace of mind for the maintainer?
I'd also like to point out that we actually have a concept for lightly maintained packages that cannot reach end users: modularity. I know its not popular, but it would be an option for this. However, I wouldn't be a fan if it being used like this.
Cheers,
Dan _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On Fri, Nov 20, 2020 at 12:03:27AM +0100, Emmanuel Seyman wrote:
I suspect that these packages are maintained only to the point where they can build (and thus be used as buildreqs) but their maintainer also doesn't want them to be updated without making sure that the update will not break the package they are really interested in.
That's probably also true. So communicating that reverse-dependency might be another important aspect. CI gating should in theory help here.
What exactly do you want to do with this list of lightly-maintained packages?
Is this something you want to present to end-users?
Yes.
Is this a list we should show to people tempted to become packagers?
Possibly? Maybe more appropriate for packagers interested in increasing overall packaging quality.
Do we want to generate auto-replies to bugs filed in Bugzilla?
Yes, I think so. Explaining the situation and asking for help. We may also want to have a process for making sure that bugs which actually might percolate up to the actual package of interest don't get discarded.
Should SIGs keep a lookout for security fixes to apply?
That would be awesome in general, I think.
On Fri, Nov 20, 2020 at 11:16:03AM -0500, Matthew Miller wrote:
On Fri, Nov 20, 2020 at 12:03:27AM +0100, Emmanuel Seyman wrote:
I suspect that these packages are maintained only to the point where they can build (and thus be used as buildreqs) but their maintainer also doesn't want them to be updated without making sure that the update will not break the package they are really interested in.
That's probably also true. So communicating that reverse-dependency might be another important aspect. CI gating should in theory help here.
What exactly do you want to do with this list of lightly-maintained packages?
Is this something you want to present to end-users?
Yes.
Well, I'm not sure how we would do this. I mean a 'normally maintained' package still means the end-user should expect the maintainer to solve their bug when they are willing and able to do so. We don't promise any kind of turnaround on issues or deadlines on things. So how would a 'lightly maintained' package be different here?
Is this a list we should show to people tempted to become packagers?
Possibly? Maybe more appropriate for packagers interested in increasing overall packaging quality.
Do we want to generate auto-replies to bugs filed in Bugzilla?
Yes, I think so. Explaining the situation and asking for help. We may also want to have a process for making sure that bugs which actually might percolate up to the actual package of interest don't get discarded.
The problem there is that there are lots of reasons for different maint levels, and it's hard to image a generic template handling that.
Even if we bundle all the ones specifically in this exact case "I only maintain these packages because I care about 1 thing that uses them", it's hard to explain to users the expectation here. Imagine a bug against one of these packages that:
* bumps to a new release/version. This might be fine, if the 1 package you care about still works fine, but might be something you reject if it doesn't. I suppose you could ask the user to test it and let you know?
* Fixes some cosmetic bug that has nothing to do with how it's being used by the one package. If the maintainer had time they could apply/build this, but again would have to make sure it doesn't affect the thing they care about.
* Is some complex thing that needs a bunch of investigation. I don't think the maintainer of the one thing will have time/energy to do that now, but not sure who would if we tell the user more? "The maintainer doesn't care about your bug because they only care about package X, you are on your own" is I suppose a bit better than silence in some ways.
* Complains about an update that was needed for the one package. I would think this would be closed, sorry, nothing I can do either way?
In the last FESCo meeting we got off on a bit of a tanget here talking about how we might look at improving all bug handling somehow. I think it might be constructive to look into ideas around that and they might help these 'lightly maintained' packages too?
It's not a easy problem for sure. ;(
There's currently 16,288 bugs against fedora components. About 84% of them are in "NEW" state. 570 bugs were opened in the last 7 days 555 bugs were closed in the last 7 days. (So, I guess right now we are treading water)
The top 10 packages bug counts are not too surprising:
kernel 1040 Package Review 730 gnome-shell 286 anaconda 267 selinux-policy 241 dnf 215 firefox 157 distribution 139 systemd 131 NetworkManager 95
Interestingly, 40% of our open bugs are against rawhide. Thats pretty amazing considering we move rawhide bugs to branched when we branch, so those 40% were all filed in the last months.
Should SIGs keep a lookout for security fixes to apply?
That would be awesome in general, I think.
Always a good idea.
kevin
On 19.11.2020 23:13, Matthew Miller wrote:
Some packagers in Fedora do not have time to maintain the build dependencies for the packages that they are actually interested in and have time to build.
By allowing such packages, we will open the Pandora's box. Most of them will never receive updates and will have known bugs and security vulnerabilities. As a result, the packages that will use them will also be vulnerable.
That's why I'm strongly against this proposal. All packages must be equally maintained.
On Fri, 20 Nov 2020 at 02:58, Vitaly Zaitsev via devel < devel@lists.fedoraproject.org> wrote:
On 19.11.2020 23:13, Matthew Miller wrote:
Some packagers in Fedora do not have time to maintain the build
dependencies
for the packages that they are actually interested in and have time to build.
By allowing such packages, we will open the Pandora's box. Most of them will never receive updates and will have known bugs and security vulnerabilities. As a result, the packages that will use them will also be vulnerable.
That's why I'm strongly against this proposal. All packages must be equally maintained.
Packages are NOT all equally maintained. They haven't been for years. There are not enough active packagers to equally maintain the ~23000 (22446 regular + 657 module srcrpms) packages in rawhide. We have a lot of packages who are only maintained in the sense that it was orphaned and someone realized that some other package needed it. Yes there are some packages which have not had an update because the upstream feels the package is done.. we have other code that is slow updating.. and a lot of other excuses of 'not all packages' when this topic gets brought up. However start saying 'ok let's count how many are like that' and people skitter off fast.
I get it. No one wants to look at the basement or attic and clean it up.. doesn't matter how many rats are in it from the buildup. just put out more traps in the places we live and its fine.
[To be clear I am not for sticking packages in a attic repository. I am for admitting we have a lot of closets and probably a basement of little maintained packages, we have stuck things in it one way or another, and we can either clean up the mess or get rid of it.]
On 20.11.2020 13:58, Stephen John Smoogen wrote:
We have a lot of packages who are only maintained in the sense that it was orphaned and someone realized that some other package needed it. Yes there are some packages which have not had an update because the upstream feels the package is done.. we have other code that is slow updating.. and a lot of other excuses of 'not all packages' when this topic gets brought up. However start saying 'ok let's count how many are like that' and people skitter off fast.
If the "lightly-maintained packages" will be allowed, more and more packagers will ditch their header-only libraries and move into this repo. This is not good, because many people use them not only for building packages, but also for the development.
I maintain a lot of such header-only packages.
Dne 13. 11. 20 v 14:51 Ken Dreyer napsal(a):
On Thu, Nov 12, 2020, 4:15 PM Matthew Miller <mattdm@fedoraproject.org mailto:mattdm@fedoraproject.org> wrote:
On Fri, Nov 13, 2020 at 12:07:29AM +0100, Kevin Kofler via devel wrote: > I still believe that this concept is inherently incompatible with the idea > of a cooperative community distribution, and that bringing it up again and > again with minimally changed wording is not a constructive thing to do. > > I can see why RHEL has a business case for having such "second-class > citizen" packages, but this is not how Fedora works or should work. Well, except, it clearly *does* work that way. We have many lightly-maintained packages in practice. I think it's better to label them as such and find positive ways to encourage the collaboration I think we all agree is best, rather than the current state where we basically just pretend that everything is maintained with high attention.I'm not sure anyone's pretending.
In my experience distros that spilt up into many repos add complexity (and mistakes) on the releng side and a poor UX for the users.
If we had labels in Pagure for the packages that you consider to be troublesome, would that help?
~~~
Provides: lightlymaintainedpackage(foo)
~~~
:)
V.
- Ken
devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org 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@lists.fedoraproject.org
On Fri, Nov 13, 2020 at 04:17:14PM +0100, Vít Ondruch wrote:
Provides: lightlymaintainedpackage(foo)
Thats.... actually not horrific. And it matches some of our other things like "Provides: bundled(foo)" which we use to mark non-ideal packaging situations.
On Fri, Nov 13, 2020 at 06:51:17AM -0700, Ken Dreyer wrote:
I'm not sure anyone's pretending.
In my experience distros that spilt up into many repos add complexity (and mistakes) on the releng side and a poor UX for the users.
If we had labels in Pagure for the packages that you consider to be troublesome, would that help?
Yeah, I think this might also be a good approach, and as you say, possibly easier than creating a setup where packages can migrate easily between two repos.
The one thing I would like is for us to be honest with ourselves and our users, and I'd like that to be transparent, not just something you need to check in pagure to find out -- there should be a dnf command to run to show this status for packages on your current system.
On Thu, Nov 12, 2020 at 06:15:27PM -0500, Matthew Miller wrote:
On Fri, Nov 13, 2020 at 12:07:29AM +0100, Kevin Kofler via devel wrote:
I still believe that this concept is inherently incompatible with the idea of a cooperative community distribution, and that bringing it up again and again with minimally changed wording is not a constructive thing to do.
I can see why RHEL has a business case for having such "second-class citizen" packages, but this is not how Fedora works or should work.
Well, except, it clearly *does* work that way. We have many lightly-maintained packages in practice. I think it's better to label them as such and find positive ways to encourage the collaboration I think we all agree is best, rather than the current state where we basically just pretend that everything is maintained with high attention.
Let's stop using the word 'repo' for this idea. 'Label' is better but I'm not sure that explains things enough.
The objective I had was to identify things considered "lightly maintained" to expand collaboration. We have new package maintainers looking for packages to help with or we have multiple packages depending on the same lightly-maintained packages which presents an opportunity for maintainers to help each other out. The objective is to increase discoverability beyond the FTBFS reporting.
Example:
* A program is added by a new package maintainer that requires a library we do not have in Fedora. This package maintainer also adds a package for that library and is assigned as the maintainer. However, the program is the only thing using this library and the package maintainer focuses on maintaining the program and not necessarily the library package. We can cite policy, but the reality is that this does happen.
Maintaining a package as a BuildRequires is not always the same as maintaining the package for broad availability.
There is ongoing work we expect package maintainers to do and if we were able to categorize or otherwise easily identify these packages as open to gaining more co-maintainers, I think it would help the project as a whole.
I'm not suggesting we make a separate repo. A labeling or categorization capability that fits in to our existing tools I think would help a lot.
Thanks,
-
Alexander Scheel -
Christian Glombek -
Dan Čermák -
David Cantrell -
Emmanuel Seyman -
Fabio Valentini -
Ken Dreyer -
Kevin Fenzi -
Kevin Kofler -
Matthew Miller -
Miroslav Suchý -
Petr Pisar -
Pierre-Yves Chibon -
Rahul Sundaram -
Robbie Harwood -
Stephen John Smoogen -
Vitaly Zaitsev -
Vít Ondruch -
Zbigniew Jędrzejewski-Szmek