On 26. 04. 19 2:00, Christopher wrote:
On Thu, Apr 25, 2019 at 2:39 PM Tom Hughes <tom@xxxxxxxxxx> wrote:
On 25/04/2019 19:29, Stephen John Smoogen wrote:
On Thu, 25 Apr 2019 at 04:23, Nicolas Mailhot
<nicolas.mailhot@xxxxxxxxxxx <mailto:nicolas.mailhot@xxxxxxxxxxx>> wrote:
Le mercredi 24 avril 2019 à 16:14 -0400, Stephen Gallagher a écrit :
>
> FWIW, things should *not* be getting harder. Some folks just jumped
> the gun and made changes they weren't supposed to (yet) and now the
> Modularity team has a lot of fires to put out and very few resources
> with which to do it.
That’s not overly nice to the people that “jumped the gun”. They’re
using modularity exactly as it was designed. Tragedy of the commons is
an entirely predictible outcome, of something without a built-in
sharing strategy.
That is my view of the matter also. There are a lot of packagers with
way too many packages... and we have too many dependencies... so any
tool which allows for that to be 'easier' is going to start an avalanche
of packages getting moved out of the 'ursine commons'. As someone said
yesterday to me, it is like showing that you can make a better living as
a farmer using industrial farming techniques and then complaining that
the small old-fashioned farmer no longer exists... or that a lot of
people quit being farmers because those who used the industrial methods
took over the market.
How does modularity make it easier though?
It seems to me that it does the exact opposite - instead of having
one version of each package to maintain I now have multiple versions
to worry about! I mean obviously I could convert to a module and
only maintain one version but what would be the point? There would
still be extra metadata relating to the module to maintain anyway.
I probably agree with you, based on my own experience alone. However,
I think arguing against modularity is a distraction from the problem
at hand. Can't we just concede that modularity benefits some, but not
all, packagers? Fighting with the "Modularity team", whoever they are
(a SIG? a mailing list?, a team at RedHat? ... I don't really know who
they are) is only going to divide us and distract from the real issue.
This isn't their fault. The packaging process is the responsibility of
FESCo. It is their responsibility to ensure that the packaging
processes in place are adequate to enable packagers to contribute,
regardless of what's going on with any specific subset of packagers.
But, it's clear that the current processes are breaking, getting more
burdensome, and require more education, tooling, documentation, and
general fine-tuning. As a result, many packagers are getting "left
behind".
Perhaps I'm looking in the wrong places, but I haven't seen much in
terms of what FESCo is specifically doing to address this "left
behind" issue within the packaging process. Is there a place where
they regularly document what they are doing from a process engineering
and oversight perspective, and receive community feedback on what they
are doing? I think that could be helpful, but I don't know where to
look (if it exists).
I am afraid there is no such dedicated place.
Recently, we've talked about the "contributing to Fedora is harder" at one of
the FESCo meetings [1] and this is what we came up with Randy (bowlofeggs) after
as 2 major issues:
https://pagure.io/fesco/issue/2114
https://pagure.io/fesco/issue/2115
However there might be more.
I'd be very happy if you help me to identify major pain points that need to be
addressed.
The problem at FESCo is that we cannot make people implement stuff or fix
things. We can possibly only stop new stings from happening too fast.
I believe that several unfortunate choices were made in the past, but I realize
it is to late to say: "scratch this, let's go back X releases". Instead we
should try to "unbreak things" however nobody really knows how to do that :(
There was the packager UX initiative draft [2] proposed in December 2018,
however it seems nobody really is eager to go and start doing this.
It seems that this is a bit too much for volunteers and Red Hat paid Fedora
contributors are already folly occupied by their primary responsibilities.
I'm glad you've opened this topic.
[1]
https://meetbot.fedoraproject.org/fedora-meeting-1/2019-03-25/fesco.2019-03-25-15.00.log.html
[2] https://fedoraproject.org/wiki/Objectives/Packager_Experience
--
Miro Hrončok
--
Phone: +420777974800
IRC: mhroncok
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: https://lists.fedoraproject.org/archives/list/devel@xxxxxxxxxxxxxxxxxxxxxxx
