On Fri, 11 Oct 2019 at 14:29, Chris Murphy <lists(a)colorremedies.com> wrote:
> > My main gripe is the current situation where users are thrown under the
> > bus and then we give them a business card and say: read these
> > instruction to figure out how to save yourself.
> > I think this is unacceptable.
> Ordinary every day user or do you mean packagers being
> the bus. And really then, is there a difference because neither the
> mortal user or immortal packager should be thrown under the bus, when
> we get right down to it. That's certainly not a design tolerance. Too
> much trust in dnf has been built up for that to happen. It's natural
> and necessary any possibility of that be resisted.
> And I don't actually know any of the parameters under
> don't even understand RPM let alone modularity. Every time I approach
> packaging I find too many barriers to entry, or at least something
> else that seems more interesting. I'm quite content with dnf and
> packagers doing the work. Is there a shrinking packager problem?
There has been a shrinking packager problem for years due to multiple problems
1. A lot of packagers were doing this as volunteer time, and that is a
limited resource. You get sick, you get tired, you have a work
deadline, etc and then you find yourself 2-3 releases behind and not
feeling like looking at 200 bugzilla's.
2. A lot of packages needed more development work than a packager
could pursue. If I packaged up xtank because i loved the game, and was
able to fix a couple of things.. that is ok. However when it turns out
that it needs a lot of forward port work because Fedora moved to
X11R20 and the maintainers want to stick to Xorg for a bit longer..
you just let the bugzilla's pile up hoping it will sort itself.
3. For years there was a cross distro 'arms' race of 'our distro needs
as many packages as possible or no one will use it'. So you ended up
with some set of packages being pulled in which people were 'sort' of
interested in versus invested in.
4. Packaging is like making cheese, there are 2000 different ways to
do so and it is hard to know which ones are good. Trying to come up
with consensus at times or getting people to follow the consensus ends
up with tyres burning in the streets.
5. Getting reviews takes time and energy from reviewers. When you have
100 packages you absorbed from 4 different packagers.. you have little
time to look at someone else's and mentor them. So instead you have a
backlog of package reviews and probably people who are no longer
interested tied to it.
6. Package upstreams are a lot faster and change greatly. There are a
lot of software which will completely add a dozen new dependencies and
the packager has to rip out the embedded versions or find the versions
which work. Of course those versions rarely work with everything else
and you end up with conflicts between things. That is tiring and
people age out.
As packagers left for some reason or another, other packagers would
find that meant something they needed was going away and would take
that package. And like a death of a thousand papercuts, that meant
that those packagers also started to find their time eaten up so they
might have less time to mentor others. Then some of those people
burned out and you ended up with even more 'well I will take your 100
packages' added onto people.
Just to be clear, this isn't a problem with only Fedora. Debian,
OpenSuSE, etc are all facing the same problems as volunteers
interested in working on distributions are not a 'growing' percentage.
It also doesn't mean that it is the end of the world. It does mean we
have to be more clear about our limits and stick to them. Trying to
package up a lot (or all ) of software does not make sense for
multiple reasons. However the primary one is that most software was
never written to be integrated into an Operating System. It was
written as a universe of its own, and the developers dont' see it as
their job or vision to be tied to an OS. We can force all kind of
things to try to make it but each one takes time and energy from
people who are volunteering that effort and could be doing something
devel mailing list -- devel(a)lists.fedoraproject.org
To unsubscribe send an email to devel-leave(a)lists.fedoraproject.org
Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
Stephen J Smoogen.