Fedora Extras is extra

[Jeff Spaleta]

On Tue, 30 Nov 2004 12:51:08 -0500, William M. Quarles <quarlewm at jmu.edu> wrote:
> And the repositories don't all compete with each other.  That's only how
> Fedora Extras sees it, because THEY are the newcomers trying to compete
> with all of the other repositories.  

I use the term compete.. in a larger sense then you do.
I look at any duplication of effort, to package the same packages in
different locations as competition for manpower. I believe the entire
process is manpower limited, and I believe it is wise to reduce the
amount of manpower used on inter-repo regression testing and use it
for other things. Disagreements at this level come down to priorities,
resource allocation and priorities. While there is always a place for
divergence and duplicated effort.. as a generator for innovation and
experimentation. I see no reason to spend the man-power to encourage a
mainline process that makes duplication of effort as central approach
to mainstream package distribution and maintaince.

And please, you need to understand this is no longer a fedora.us
against the repository establishment. Red Hat made a decision to merge
fedora.us into the larger Fedora project. Red Hat is not a newcomer to
the issue of packaging. We must not look at this from a territorial
perspective, this is about making policy that best benefits the
project long term. What you see as "new comer" symdrome.. i see as
growth of a older distribution to encompass a larger mission. Can it
be a bad thing that the distributing is growing to encompass more
functionality? You can either agree that centralization is a good
thing and will use your limited resources and your limited time to
move towards that direction. Or you will disagree with centralization
and will work against it.  I personally choose to work towards
centralization, and find the cost of inter-repo regression testing to
be a poor use of limited time and limited manpower resources.
Everything has an opportunity cost, and I would much rather see Core
and Extras developers concetrating there limited time and limited
resources on working inside a centralized non-overlapping buildsystem
than having to try to keep up with 5 or 10 or 15 variations of
conflicting packages from a variety of locations.  I don't even expect
Core and Extras developers to have to be concerned with Fedora
Alternatives when Alternatives walks out of the vapor somewhere down
the line.

> A lot of the non-Fedora-Extras
> repositories are interoperable now because the individual maintainers
> have been working together on that. 

And they have their priorities... to them.. doing this makes a lot of
sense because of the constraints and priorities from their perspective
based on their history. Red Hat on the other hand has a longer history
and a different perspective... and have chosen to merge with fedora.us
into the larger Fedora project.

> That has been emphasized several
> times already on and off of this thread.  I think that it was either
> Axel or Dag that said that the repository world has been broken down now
> into only two camps, not 4, not 3, only two: Fedora.us, and non-Fedora.us.

That is their opinion, and i think they are very good at choosing
language that makes them out to be the victim in a personal way. I
don't think these sorts of comments are constructive and it greatly
dimishes the level of discourse.  We must move beyond "us versus them"
mentalities. I dont think its useful to talk about "repositories" when
counting heads in this fashion. I think its useful to talk about the
number of human packagers. Again I believe that the process is in
general manpower limited.  A centralized...common buildsystem model..
scales to many humans much better than the.. small group of humans per
repository model. Its a matter of economics of scale.
And I also believe that centralization makes it much easier to keep
the communication flowing from users..to packagers...to developers. I
believe it will be much easier for upstream developers to become more
involved with distribution level bugreporting and fixing if there is
centralization of packages for the specific distribution.

I also believe that centralized model lowers the bar for all potential
packagers who enter the community in all future times. A centralized
model, established and makes avaliable a set of common best practise
tools and build system to ALL new packagers who enter the system. The
centralized model provides inherent mechanism for mentoring.  The
small group model on the other hand raises the bar for all new
packagers who need to not only learn best practises on their own but
must build their own build system and distribution infrastructure for
their own repository, and then must build their own repository
brandname in the community competing for mindshare with established
repositories. The issues surrounding brand identification alone
probably limit the number of repositories in this model to something
like 15 or 20 "popular" locations, before the community is unable to
keep up with all of them in a meaningful way.

> A volunteer would still have to come forward to keep maintaining that
> particular package however.  I'm sure that far from all of the packages
> will be popular to maintain.

You skirt my main point.... it its absolutely much easier for a
volunteer to come forward.. if there is a pool of packagers who
understand the build system being used for the now unmaintained
packages.  When you have different repositories....you have different
build systems. You lower the bar greatly to a new maintainer if the
new maintainer is already building packages on the same build system
as the unmaintained packages. The more packagers using the same
tools.. the more packagers who are qualified to volunteer.
The process is manpower limited... creating a system and a process..
that makes it easy for a package to switch ownership to another
maintainer fluidly is an important step in making sure manpower is
being used effectively.  I believe making inter-repository regression
testing a priority is a waste of manpower that can be used for other
more important things.

> I don't completely disagree with that.  I just think that their should
> be some centralization, mainly libraries, and also programs that are
> useful mainly because a lot of other programs use them.  These would be
> packages that would not be relevant to Core but would be relevant to
> programs outside of core.  And leave open some "third-party"
> communication.

No one is preventing anyone from doing whatever third-party
communication they want to do as individual packagers. But we are
talking about specific policy statements... and i see no reason to
mandate that all packagers in Core and Extras make the effort to
regression test with outside repositories as a matter of policy. In
fact, i believe such testing is a waste of limited resources that
could be used for other purposes.


-jef