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.
_______________________________________________
> 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 KurtakovRed 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
