XMMS (was: Re: rawhide report: 20050405 changes)

Gregory Maxwell gmaxwell at gmail.com
Tue Apr 5 20:14:41 UTC 2005


On Apr 5, 2005 3:40 PM, Mike Bird <mgb-fedora at yosemite.net> wrote:
[snip]
> Why are useful Core packages being thrown into the uncoordinated
> obscurity of Extras before the system is ready to handle them?
> 
> And why oh why throw out popular packages to make room for Eclipse on
> the Core CD's?!
> 
> Oh, and Seth, is it that the Extras system can't rebuild all or that you
> don't want to schedule one yet?

Hey Mike, Chill a bit here...
Extras is a long way from being "uncoordinated" and obscure....  The
intensity of your words is offensive to the people who are working
really hard to make extras a reality.

At the same time, I think we can agree that it isn't the same for a
package to be in extras as in core. I'm not sure that this is entirely
bad, but in some cases I think FC-core style maint would be better..

Here are some reasons that if I were a package, I might not want to be
in extras:

1. Much smaller audience (lots of people do install everything in
core, but not so with extras today)
2. More difficult distribution model (if someone burns me the DVD ISO
redhat provides it has all of core, but none of extras)
3. 'Less reliable'source: When I get a distro from redhat, I'm getting
it from people I trust.. When I get extras it's coming from a bunch of
people on the internet I dont know.  Now it's probably true that core
doesn't have that much more redhat oversight on low profile packages,
but it's a perception issue.
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.
4. Almost no build synchronization.  When is a package in extras
guaranteed to build on a new version of FC?  ... Never.  It's possible
that a package will effectively drop out of core without any conscious
decision.  What if a user depends on that package, upgrades to FCn+1,
and finds that it no longer works?  This is far less likely to happen
'on accident' for packages in core.  Should every user have to search
for all the apps they use on the varrious discussion lists before
upgrading to have a reasonable expectation that everything will work
with only minimal fiddling after an upgrade?

All of these issues only matter for packages that are coming out of
core.. For a package that never was in core, it is less of an issue...
being in Extras is better than nothing at all.

Basically if we carry on in the direction of moving most of the
non-essential stuff into extras, and don't provide release
stabilizations for extras we will eventually create an environment
where RHES is the only option for those who want a redhat distro with
some degree of full-system stability... It's nearly useless to say
that we've QAed fedora core if we reach a point where every FC user is
spending a large part of their using extras packages that haven't been
QAed.

At the same time, extras contains a lot of great package for even
further out stuff.. software where it just isn't reasonable to have
strong QA goals on it... Stuff we would never accept in core..  And
thats great.

Perhaps a solution would be to define a subset of extras that belong
to a set of more stable/more important. These packages follow the same
revision timeline as FC, and perhaps even redhat would agree to delay
the release of FC due to problems with something in this subset. Then
only remove package from this subset through a process which provides
for transparency and discussion, to avoid pulling the rug out from
under anyone.




More information about the test mailing list