The hard problems with Collections: (Was: tuxracer & chromium move to Extras_

[Jeff Spaleta]

On Thu, 29 Jul 2004 10:30:52 -0400, Tim Daly <daly at rio.sci.ccny.cuny.edu> wrote:
> Jeff,
> 
> Your three items would clearly be tasks for the various maintainers.

I didn't say it wasn't their job. I'm saying these are the harder
issues in the set.
And not necessarily the obvious ones.

> I'm a little puzzled by your third task where you write:
> 
> > 3)making sure that the C continuum install media sets ALL come with
> > tools that understand how to use Core and Extras to get updates AND
> > additional software, not just from the internet but also from media.
> 
> First, you're still maintaining the concept of Core and Extras.
> That's gone.

Becuase Core as one installable distribution in the continuum is going
to drive the release and testing cycle for Fedora development, simply
becuase its the one installable distribution that Red Hat has primary
interest in, and Red Hat makes the final say. Core isn't gone, a rose
by any other name....still has thorns.  Red Hat's compelling interest
are going to be embodied in something akin to what is called Core now
even in the contiuum model. The volunteer efforts of red hat employees
to maintain other installable collections inside Fedora aside, the
compelling business interests at Red Hat, are still going to be
focused on one specific point in the continuum. That one point in the
continuum is going to drive the release and testing cycles. Call it
core, or whatever, it will be a singularity in the continuum and it
will carry weight beyond which other continuum distributions have when
its time to think about delays in the development cycle.

> Second, why would vendors care? The maintainer concept is "downstream".

Vendors... as in people selling install media to users who do not have
the network connectivity to do online installs or upgrades.
Fedora.redhat.com has a whole page dedicated to a list of these
entities. Its not so much that vendors care, but that people care
about being able to get access to media sets to install from, media
sets with a small finite number of discs.

> 
> For instance, I have an interest in a platform that supports computational
> mathematics. So I'm volunteered as the CA maintainer. My job is to define,
> tag, configure, test, and maintain a CA distribution. (See Quantian at
> http://dirk.eddelbuettel.com/quantian.html). This is a fully configured
> system that specializes in computational mathematics packages.

Are you suggesting that other points in the continuum are not going to
be synced with the 6month-ish release cycle that Core (or whatever you
want to call it that Fedora development tree is patterned to release
against). I really don't think any debian based downstream
distribution example is a good example for the types of problems any
fedora downstream distribution is going to face. Fedora development
moves FAST. If other points in the continuum can not sync'd to that
fast pace, thats going to be a problem, if the intent is to have all
points in the Fedora continuum trying to use the same package updates
that live inside Fedora's package set. If each point in the continuum
is just going to end up having its own release cycle and its own set
of package updates...they might as well just fork and be seperate
distributions and not even try to use the fedora build system or use
the fedora name, they will diverge quickly.

Debian's glacial release cycle gives something like Quantian a lot of
leeway to upgrade packages as needed without conflicting with the
debian base from which its derived. Trying to base anything of Fedora
with its quicker time-based 'Core' release cycle pretty much demands
that releases of a Fedora collection be in sync with the Fedora base
time cycle. If knoppix and quantian had to deal with a stable debian
branch that churned every 6 months... they'd fork and maintain
seperate development of packages completely.

> In the "maintainer world", the standard install menu could include
> the tag install lists maintained by special interests. 

this assume anaconda will be the installer for all points in the
continuum, this isnt going to be the case. There has already been
repeated gnashing of teeth about making room in Fedora for
non-anaconda based install media using something like rule.

> Thus, a
> "computational mathematics" install item would install all of the
> items that are included in Quantian plus any system tools and libraries
> needed to support the goal. Since a Quantian-like install is KDE based
> then KDE would be implied.

>From what set of install media? Being able to select any continuum
member from the installer means you have to have ALL fedora packages
on hand on media. That's just not practical. Every continuum member
will need its own set of install media to be practical, to prevent
people from having to have 17 cdroms on hand during media based
installs.
No one is going to want to have their point in the continuum need
stuff off of disk 17 to do a media based anaconda install.
 
> Lugs could have their own maintainers (the NYLUG branch).
Pretty sure this comment comes from a misunderstand of what i meant by vendor.

> 
> The Linus of the maintainer world only deals with maintainers.

Let me just point out.. since you brought up the kernel development as a model.
"downstream" maintainership of the kernel is something fedora
development has explicitly working to avoid becuase of its burdens.
I'm not sure encouraging a "downstream" distribution maintainership
model inside fedora makes for a consistent world view when "upstream
upstream upstream!!!!" is such a frequently heard chant. I think its a
bit misleading to setup a system that expects volunteer downstream
maintainers to build a distribution as an achievable goal, when
upstream is where fedora developer's place their efforts.

> 
> The current Core+Extras cannot satisfy any possible subset of users.
> Since "advocacy is volunteering" we can make complaints work for us.
> If you want a specialized build that includes tuxracer because you
> teach a newbie class then either contact the current "newbie" maintainer
> or become the "newbie" maintainer. Since maintaining a distribution is
> a lot of hard work there will be very few people who will step up to the
> task of being a maintainer. This works quite well in the linux build
> process and is clearly socially acceptable. Why not use it here?

Yes... advoocacy IS volunterring. But, its one must not encourage
volunteers to tackle tasks that we know are beyond reasonable efforts
to accomplish, becuase that is the best way to have volunteers burn
out and cripple the volunteer efforts completely.  I'm not sure you
have heard my rant about the lack of planning and management of
volunteers that fedora continues to not have a solution for, I'll
gladly rant about that to you if you want. But for now let me just
restate that your kernel development analogy you used has a darker
intepretation concerning the burden of "downstream" maintainership
versus "upstream." And if the fedora developers know better and they
know "upstream" maintainership is prefered, we should not as a matter
of policy build a system inside fedora where "downstream"
maintainership of alternative package collections is encouraged if we
know "downstream" maintainership leads to significant burdens. The
conspiracy theorist in me, would say that such a system would only
serve to shut volunteers up by encouraging them to toil on an
unaccomplishable task.  I definitely want to see someone inside the
fenceline at Red Hat use this "downstream" maintainership model long
enough to see 2 or 3 'Core' releases to gauge the robustness of the
"downstream" distribution focus, before encouraging any bright shiny
new volunteer to attempt this.

-jef"about as bright and shiny as a 1902 penny, dug up from an unused
new york sewer pipe"spaleta