Core vs. Extras (was: Re: rawhide report: 20050405 changes)

[Gregory Maxwell]

On Apr 5, 2005 5:21 PM, Michael Schwendt <fedora at wir-sind-cool.org> wrote:
> > 1. Much smaller audience (lots of people do install everything in
> > core, but not so with extras today)
> 
> Moot point, as laziness is the primary reason why Joe User chooses an
> everything-install in the fear that manual selection of packages would be
> to complicated or time consuming. Despite the availability of tools like
> Yum, it's still considered too inconvenient to add missing pieces after
> installation (and system-config-packages is a dead end with regard to
> adding software to an up-to-date FC). And do those people only install
> everything, or do they also use everything? Where is the benefit of users
> who install everything but use only a fraction of the packages? For most
> of the Extras users it makes no sense to install every package from
> Extras.

Care to cite some research showing it's just lazyness?

My laptop is often without any sort of internet connection.  An
everything install has saved my butt multiple times.  Not everyone is
able to be tied to a fast internet connection, and not everyone who
can be are at all times.

An everything install still lets us now if the install of a package
blows up the system in some indirect way, even if the user never uses
it.


 
> > 2. More difficult distribution model (if someone burns me the DVD ISO
> > redhat provides it has all of core, but none of extras)
> 
> Does the same "someone" also burn complete Fedora Core Updates onto a
> separate DVD? That could also be done with a mirrored snapshot of Fedora
> Extras today. But as pointed out above, Joe User most likely doesn't want
> another DVD of packages from which to use only a few.

Considering the number of times I've been asked to burn a disk with
updates here for the small group of users I've adopted in my area (all
of who probably have good internet access), I think you're missing
something here.

  
>  If you believe in threats like that, you
> belong to the target group of Fedora Extras commits-list, where you
> can observe CVS commits.

I'll join. :) Though I think threats like that are hopeless, it's
always better to have more eyes.

> > 4. If a package is broken in core is known broken it has some
> > potential for holding up a release. Not so for extras, so there is
> > more incentive to fix a package.
> 
> Well, in a community project, anyone who has strong interest in a package,
> which is found to be broken, can volunteer as the one who provides a quick
> fix.

Presuming that it matters much to people with awayness, time, and
ability.  I'd be willing to help maintain packages that I don't give a
hoot about because I know other people (without the ability to fix
them) need them... But I can't do that for all of Extras, because it
tends to include many many things that very few people care about.  A
smaller subset of 'things we think matter' would be fun to contribute
to maintaining.
 
> > 4. Almost no build synchronization.  When is a package in extras
> > guaranteed to build on a new version of FC?  ... Never.
> 
> Bad. Unless I'm misinformed, hopefully we still plan to have FC4 Extras
> ready together with the release of FC4 or shortly after. For that we would
> need a mass rebuild at least for FC4 Test3, though, to catch remaining
> packages which don't compile or fail at run-time and which have not been
> checked by their owners due to lack of a Rawhide or FC4 Test installation.
> I also think there are a very few package owners still missing.

Well it's not the case today, ... and it hasn't been the case historically. 

> Fedora Extras Development is used to prepare packages for FCn+1,
> currently. And once more, a user, who _depends on a package_, should
> invest some time in making sure the package does work in FCn and continues
> to work in FCn+1.

But do we only maintain packages for people with the time and skills
to do it themselves? I advocate a subset of things that we, as a
community, will commit to supporting for other people even if very few
people are directly committed to the member packages of that set.
 
> > Perhaps a solution would be to define a subset of extras that belong
> > to a set of more stable/more important.
> 
> Start with a set of packages which you think are not stable or not good
> enough. File a bug report for each package.

Fair enough, but it doesn't correct the systemic lack of polish found
in out-of-core packages.