----- Original Message -----
> From: "Stephen John Smoogen" <smooge@xxxxxxxxx>
> To: "Development discussions related to Fedora" <devel@xxxxxxxxxxxxxxxxxxxxxxx>
> Cc: "Dinesh Prasanth Moluguwan Krishnamoorthy" <dmoluguw@xxxxxxxxxx>
> Sent: Tuesday, July 30, 2019 12:05:59 PM
> Subject: Re: Over 500 orphaned packages seeking new maintainers
>
> On Tue, 30 Jul 2019 at 10:55, Aleksandar Kurtakov <akurtako@xxxxxxxxxx>
> wrote:
>
> >
> >
> > On Tue, Jul 30, 2019 at 5:48 PM Alexander Scheel <ascheel@xxxxxxxxxx>
> > wrote:
> >
> >>
> >>
> >> ----- Original Message -----
> >> > From: "Christopher" <ctubbsii@xxxxxxxxxxxxxxxxx>
> >> > To: "Development discussions related to Fedora" <
> >> devel@xxxxxxxxxxxxxxxxxxxxxxx>
> >> > Cc: "Fabio Valentini" <decathorpe@xxxxxxxxx>
> >> > Sent: Monday, July 29, 2019 6:14:57 PM
> >> > Subject: Re: Over 500 orphaned packages seeking new maintainers
> >> >
> >> > On Mon, Jul 29, 2019 at 5:36 PM Alexander Scheel <ascheel@xxxxxxxxxx>
> >> wrote:
> >> > >
> >> > > > Question (not for Fabio specifically, but for the list) modules can
> >> have
> >> > > > (Build)Requires on other modules
> >> > > > right?
> >> > >
> >> > > Yes, if the module maintainer is willing to expose their module in the
> >> > > BUILDROOT. That was PKI's problem: mizdebsk orphaned the ursine
> >> packages,
> >> > > exposed them in a module available only at runtime, and refused to
> >> open
> >> > > it up for build-time use. He wanted us to maintain our own versions of
> >> > > all of the packages we use that he modularized.
> >> >
> >> > I don't think "refused" is a fair characterization. My understanding
> >> > of the problem is that creating a module is new (and change is hard),
> >> > and unnecessary for most basic packages, so long as their BRs are
> >> > available. Maintaining many of the java BRs across multiple releases
> >> > was becoming burdensome, so mizdebsk decided to take advantage of
> >> > modules to reduce their work load. The ideal at that point was to
> >> > expose modules to the ursine BUILDROOT, in order for ursine packagers
> >> > to have BRs on them without having to themselves be shipped in a
> >> > module. Without that, lots of ursine packages were going to suffer,
> >> > and that's what happened. Fedora is now extremely hostile to Java
> >> > packagers, unless 1) the java packager is willing to take on dozens or
> >> > hundreds of packages, or 2) the java packager is willing to learn how
> >> > to do all this module stuff.
> >> >
> >> > I don't think it's fair to say that mizdebsk "refused" to open them up
> >> > to build-time use... but perhaps fair to say that they refused to open
> >> > them up to build-time use, when that didn't solve the underlying
> >> > problem (because they would still only be available to modular
> >> > packages, and not to ursine ones, which is what was needed).
> >>
> >> This actually has nothing to do with modules vs. ursine packages. mizdebsk
> >> maintains a very small API on his modules. This limits what other modules
> >> can do with it, including in the BUILDROOT. So when our first attempt to
> >> save Dogtag was to modularize it (into the now-deprecated pki module),
> >> we realized that wouldn't work *because* of that small API. It simply
> >> didn't contain what we needed.
> >>
> >> We reached out to mizdebsk and his stance was that we should bundle all
> >> our dependencies (that he modularized) into *our* module, maintaining
> >> *separate* streams from his. This is completely unworkable at scale. He
> >> didn't want to expand the API. We put our time elsewhere and stayed
> >> ursine.
> >>
> >> I think "refused" is thus a fair categorization.
> >>
> >
> > And you offered him to take ownership, right? I just couldn't stand
> > looking how the single guy keeping Java ecosystem working in Fedora for a
> > number of years is being *blamed* for not doing exactly what others need
> > and I haven't heard of *anyone* actually proposing to take some of his
> > load.
> >
> >
>
> The issue is that no one has time to take ownership of these packages. The
> whole premise around Fedora's package model for the last 15 years is that
> the number of packagers and the number of packages linearly grew. You might
> end up having more packages, but there was always a stream of new packagers
> who could help take up some of the load and help out. The problem is that
> the number of needed packages has grown exponentially, and the number of
> interested packagers has either staid linear or decreased.
>
> I agree that where Mizdebsk is not maintainable and he is flailing to try
> and come up with a solution in modularity which allows him to have some
> sort of livable life. However, I also agree with Alexander's analysis but
> for different reasons. The solution is neither maintainable to the
> distribution nor in the end to Mizdebsk. It will collapse horribly at some
> point where mizdebsk leaves.. or the number of packages needed for what his
> final tool have become unmistakably large. I disagree that it is mizdebsk's
> job to fix that or not to refuse to keep doing it.
Where this fails is where there's duplication of efforts. Take slf4j as an
example. mizdebsk maintains it in one of his various modules (it looks like
the javapackages module). We maintain it in the SIG as an ursine package so
things like Dogtag and a lot of other things don't break. When you go to
install Dogtag though, you never get the SIG version though: you always
get slf4j from the module (which we can't use in the BUILDROOT because its
not exposed through the API). This is a "feature" in DNF: default module
stream branches beat any ursine package, even with a higher NVR. To me,
and probably to mizdebsk as well, that's unfair.
>From a "how do we solve this perspective": this isn't feasible long term.
If mizdebsk leaves, we're screwed (sorry that we pick on you so much!).
If he joins the SIG, we have the same amount of duplication and work.
In my opinion we need:
- More (active) SIG members [*],
- mizdebsk joins the SIG,
- We either:
- Drop the modular versions of the packages, or
- Make the modular APIs complete and fix the non-modular building problems,
- Standardization and automation around how we maintain packages in the SIG.
Some combination of these would likely work too (1 + 4), but would be
suboptimal and wasting time.
What do other language ecosystem SIGs do? How many packages do they
maintain?
My 2c,
Thanks
- Alex
[*]: And I admit, I too am partially at fault here as a partially-active
SIG member.
>
>
>
> >
> >> > At least, that's my understanding of the situation.
> >> >
> >> > FWIW, I'm probably going to orphan the last of my Java packages, too,
> >> > because I don't have time to figure out how to create a bunch of
> >> > modules just so I can get the BRs I need. My time would be better
> >> > spent building ursine packages in COPR, outside of Fedora's modularity
> >> > efforts. I've been watching keenly, to see if the situation will
> >> > change, and Fedora will become Java-friendly again, but I don't see
> >> > that happening, sadly.
> >>
> >> Right, and perhaps you'll get lucky and your modules will work because
> >> your BRs are exposed in the API of modules. But until then, the SIG is
> >> picking up hundreds of packages just to keep the entire ecosystem alive
> >> and to help out those maintainers who don't have time or don't want to
> >> modularize.
> >>
> >> > _______________________________________________
> >> > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> >> > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> >> > Fedora Code of Conduct:
> >> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> > List Archives:
> >> >
> >> https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
> >> >
> >> _______________________________________________
> >> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> >> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> >> Fedora Code of Conduct:
> >> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> >> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> >> List Archives:
> >> https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
> >>
> >
> >
> > --
> > Alexander Kurtakov
> > Red Hat Eclipse Team
> > _______________________________________________
> > devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> > To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> > Fedora Code of Conduct:
> > https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> > List Archives:
> > https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
> >
>
>
> --
> Stephen J Smoogen.
>
> _______________________________________________
> devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
> Fedora Code of Conduct:
> https://docs.fedoraproject.org/en-US/project/code-of-conduct/
> List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
> List Archives:
> https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
>
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
