On Thu, 25 Apr 2019 at 20:01, Christopher <ctubb...@fedoraproject.org>
wrote:

> On Thu, Apr 25, 2019 at 2:39 PM Tom Hughes <t...@compton.nu> wrote:
> >
> > On 25/04/2019 19:29, Stephen John Smoogen wrote:
> > >
> > >
> > > On Thu, 25 Apr 2019 at 04:23, Nicolas Mailhot
> > > <nicolas.mail...@laposte.net <mailto:nicolas.mail...@laposte.net>>
> 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
>

Sorry I didn't mean to come across as fighting with the modularity team. My
main problem is that something like this looked like it was going to happen
no matter the solution added to Fedora. If we had come up with some other
tool which transformed how things are done.. this would have still
happened. The issue is that everyone involved got sucked up into other
problems and let the spinning china plates hit the floor. [And since I am
on this list, and I do follow things.. I am one of those people who let the
plates fall.]



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




-- 
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://getfedora.org/code-of-conduct.html
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org

Reply via email to