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

[Kevin Fenzi]

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 
anaconda267 
selinux-policy  241 
dnf 215 
firefox 157 
distribution139 
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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Matthew Miller]

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.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Vitaly Zaitsev via devel]

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.

--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Stephen John Smoogen]

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.]




-- 
> Sincerely,
>Vitaly Zaitsev (vit...@easycoding.org)
> ___
> devel mailing list -- devel@lists.fedoraproject.org
> To unsubscribe send an email to devel-le...@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
>


-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Vitaly Zaitsev via devel]

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.


--
Sincerely,
  Vitaly Zaitsev (vit...@easycoding.org)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Christian Glombek]

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 
wrote:

> Emmanuel Seyman  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-le...@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
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Dan Čermák]

Emmanuel Seyman  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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Emmanuel Seyman]

* 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Matthew Miller]

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

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Matthew Miller]

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.



-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Robbie Harwood]

Matthew Miller  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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Matthew Miller]

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

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Alexander Scheel]

On Tue, Nov 17, 2020 at 1:21 PM Robbie Harwood  wrote:
>
> Matthew Miller  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-le...@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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Robbie Harwood]

Matthew Miller  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.


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Kevin Kofler via devel]

Ken Dreyer wrote:

> On Fri, Nov 13, 2020 at 3: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.
> 
> 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Kevin Kofler via devel]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Rahul Sundaram]

Hi

On Fri, Nov 13, 2020 at 5:54 PM Matthew Miller 
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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Matthew Miller]

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.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Ken Dreyer]

On Fri, Nov 13, 2020 at 3: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.

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Kevin Kofler via devel]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Rahul Sundaram]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Matthew Miller]

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.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Kevin Kofler via devel]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Kevin Kofler via devel]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Kevin Kofler via devel]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Matthew Miller]

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.


-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Matthew Miller]

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.

-- 
Matthew Miller

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[David Cantrell]

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,

--
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Vít Ondruch]

Dne 13. 11. 20 v 14:51 Ken Dreyer napsal(a):



On Thu, Nov 12, 2020, 4:15 PM 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.



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-le...@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


OpenPGP_0x0CE09EE79917B87C.asc
Description: application/pgp-keys


OpenPGP_signature
Description: OpenPGP digital signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Stephen John Smoogen]

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-le...@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
>


-- 
Stephen J Smoogen.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Fabio Valentini]

On Fri, Nov 13, 2020 at 2:52 PM Ken Dreyer  wrote:
>
>
>
> On Thu, Nov 12, 2020, 4:15 PM 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.

(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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Ken Dreyer]

On Thu, Nov 12, 2020, 4:15 PM 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.
>


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

>
>
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Pierre-Yves Chibon]

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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Emmanuel Seyman]

* 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Petr Pisar]

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


signature.asc
Description: PGP signature
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Pierre-Yves Chibon]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Kevin Kofler via devel]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Matthew Miller]

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

Fedora Project Leader
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Kevin Kofler via devel]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Emmanuel Seyman]

* 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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Zbigniew Jędrzejewski-Szmek]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[Miroslav Suchý]

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?

-- 
Miroslav Suchy, RHCA
Red Hat, Associate Manager ABRT/Copr, #brno, #fedora-buildsys
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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

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

[David Cantrell]

=
#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-11-15.00.log.html
.



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

--
David Cantrell 
Red Hat, Inc. | Boston, MA | EST5EDT
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@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