Re: maybe a path forward for java and modules? [was Re: The Future of the Java Stack (also regarding ELN and RHEL)]

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

 



On Fri, Sep 18, 2020 at 02:16:11AM +0200, Kevin Kofler wrote:
> Matthew Miller wrote:
> > I mean, some of y'all like to maintain and keep obscure dependency
> > packages up to date just for their own sake, and that's *awesome* -- but
> > we just can't hold everyone to that standard. At least, not if we want
> > more than a few dozen packagers.
> 
> That is a pretty strong assertion, with no facts to back it.
> 
> I think that packagers are more likely to be driven away by changes such as 
> Modularity that make packaging more and more complex, or even by the very 
> fact that the dependencies they need were taken private by their maintainer, 
> than by the very reasonable minimum standard we want to hold our packagers 
> to.
> 
> A private dependency is necessarily a form of technical debt that is 
> inevitably going to hurt us as soon as we want to package something else 
> that happens to depend on that same dependency. (Unless of course the 
> dependency really cannot be used for anything else than building that one 
> dependent package, in which case nobody is going to expect the maintainer to 
> make it work for anything else even if it is public, so that trivial case 
> need not be considered any further.) Hence, this risks driving away the 
> people who would be packaging the other dependent packages if the dependency 
> was readily available to them.

Fully agreed. The problem with modularized packages is that there is
no smooth transition between the states. A normal package, even if not maintained
fully, can be picked up by anyone at any time. Even by a non-packager: any user
can open a PR in pagure to fix some particularly annoying issue.
But once modularized as build-only, the package is not visible to users, is not
visible to other packagers, possibly loses out on any distro-wide mass changes,
and most importantly, trying to take it back out of the module is not smooth
at all.

> And that is just the impact on packagers. You also have to consider the 
> impact on end users. Do not forget that most packagers were users before 
> becoming packagers. Hiding packages from users or labeling them as 
> officially unsupported is going to make Fedora less attractive to users, 
> which in turn will lead to fewer people potentially becoming packagers.

I partially disagree about the "labeling them as officially
unsupported is going to make Fedora less attractive to users". If a package
*is* not fully supported, then I don't see users should not know this. In fact,
if I were to install a package as a user and see a message like
"Sorry, we don't have enough round tuits to handle bugs in this package.
Type «I understand» to proceed." then it could make an easy entry point for new
packagers.

Zbyszek
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx




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

  Powered by Linux