EOL, rolling releases, and Extras (Was Re: Fedora Extras vs. CLOSED RAWHIDE)

[Jeff Spaleta]

On Thu, 05 Aug 2004 14:52:17 -0400, Toshio <toshio at tiki-lounge.com> wrote:
> I agree that Core shouldn't be a rolling release, but I think Extras is
> currently very much a Rolling Release.  And it's best if it stays that
> way.  

I think you are wrong. I think having synced time releases of Extras
as a priority
makes a lot of issues go away.  Issues that i think are vastly more
important than your desire as an end-user to get the lastest one or
two applications without having to flush your whole OS. I'd rather
work towards making it less painful to do whole Fedora Core upgrades
then to build a Fedora development process that encourages people to
focus attention to older Core releases.

Having synced Extras and Core releases.. as a priority allows for a
MUCH easier generation of other 'collections' besides Core. Read
Tiemann's strawman proposal.
I very interested in making sure the development process of Fedora
makes it easy for people to make and continue to maintain a Fedora
livecd or a Rule based mediaset or other installable 'collections' by
picking and choosing among Fedora Extras and Fedora Core packages to
bundle together as a new installable collection. If Extras is not
synced against Core releases, any sort of community maintained
'collection' is going to be burdened to  deal with the different
timesscales associated with Core and Extras package development.  So
that we can FINALLY get past these crappy 'whats in Core' debates and
just let Core be an arbitrary set of packages with NO inherent
distinction in the development process. Every package treated equally
in development process itself, then distilled into collections..one
collection being named Core.

The other issue synced Extras to Core will greatly help with is doing
installs and upgrades painlessly from computers without broadband,
from media sets. This is a serious issue for a lot of people, and
having point release media sets of Core+Extras as a priority that
people can use with anaconda is an absolute necessity if we want to
actually consider Fedora Extras as part of Fedora and not just another
3rd party repository.  I don't want Fedora Extras to be just like it
is now...i want it to be INTEGRATED into the development process.
I want to see FC5 and FE5 come out on media sets, and have anaconda
understand how to deal with FE5 media when installing FC5 from media.
I want to see FC5.1 and FE5.1 update media sets 3 months later which
include supplimental updates and new packages as well via bittorrent.

I want to get to the point where we can seriously talk about moving
things out of Core into Extras or out of Extras into Core..without
upgrade path problems. This is only going to happen if we make
development Extras targert Core development as a PRIORITY.  I want to
get to the point where Red Hat feels comfortable enough to allow some
of the RHEL cruft to drift over to Extras to make room for community
contributed things that are less RHEL relevant into Core. I don't see
that happening if Extras is continued to be treated with its own
timetables and development paths.

The keyword here is.. PRIORITY. If some Extras maintainers want to
keep rolling packages every day for FC releases to keep close to
upstream... great... more power to those individuals, if they have
they time to continue to roll updates great. BUT there is a HUGE
difference between giving invidivuals the space to do that...and
demanding ALL the packagers, community or red hat, to deal with that
sort of churn. The development tree is where integration issues
between Core packages are primarily worked out... i see no reason why
integration issues between Extras and Core package should NOT be
worked out in the same way. An integrated Extras needs to be
proactively developed and get interaction problems solved with Core
developers while Core developers are focused on the development tree.
We are talking about corner cases here, where there is some sort of
build problem associated with a bug or packaging error in an already
released FC release that would prevent the successful building of
suppliment FE packages  for released Cores.
I don't want to drag to focus of development backwards as a matter of
policy. If maintainers can work the issues out for themselves and
every packager invovled with the maintaince issues can come to
agreement..great. If not, no biggie, work out the integration issues
in the development and make sure the next FC-N/FC-N package sets have
it all ironed out.

>As a spare time packager, I can't be constantly updating my system
> so I can release a package at the same time as a new Core is released.

If the Fedora infrastructure that is put in place for community to use
can't address your concern about continually updating your own system,
then we are doomed regardless.

> As a user, I want to find a package that's as close to upstream at the
> time I'm looking, not one that was released when the distro came out.

Instant gratification seems to be a constant demand... and an odd one.
If you want as close to upstream as possible really... update from the
development tree for
ALL the packages from the kernel right on up the stack.  If its okay
to eat close to upstream Extras, you should be okay eating close to
upstream Core as well. The distinction between what is in Core and
what is in Extras needs to be come less distinct from a development
process point of view or we aren't going to make any progress on
really expanding the potential of Fedora in new directions.


> FC1 might be near EOL, but it's still widely used.  With such quick
> EOL'ing, there will always be a large number of systems that are EOL but
> still in use.  I can't upgrade my wife's machine until October, for
> instance, because she has a class that's wrapping up and I don't want to
> disrupt it's stability until it's over.  I don't think EOL of Core is
> such a good measure of whether to continue trying to build Extras
> packages for it.

as a PRIORITY is what i said... if YOU as an invidual packager want to
build for FC1 great, after you have the package synced with Core
development. But if your new builds dont work becuase of a problem
with a dependancy in Core or in Extras, i don't think its appropriate
to demand that the Core or Extras packager get the necessary fix out
the door. Their personal priorities might be different than yours and
I don't think its necessarily appropriate to have them make your
interests their priority with their efforts. I think its fair to
demand everyone to make the development tree the priority for package
integration work, and any integration issues in already released Cores
is discretionary. Luckily most Core developers can be bribed with
either alcohol or a KK doughnut, so i think I have a pretty good shot
and talking my way through any corner case discussions to my benefit.
 
> For those developers who have the time and resources to update their
> machines to the latest rawhide/test releases, I think you have a good
> point about having developers look forwards instead of back.
> 
> For the volunteers who want a stably running system that they can
> package foobar for and then submit to Extras because they want to give
> back to the community, I don't see this is an option.  For the same type
> of volunteers who want to do QA of packages when the developers are only
> looking towards test/rawhide, this is also an unnecessary raising of the
> bar.

If contributing packages to Fedora means actually running the
development tree...then we are doomed. I would hope that whatever
build infrastructure drops from the heavens for contributors to use
will not demand that all contributors be running a full fedora
development tree...nor any Fedora release at all on the systems where
they craft packages.  But that being said. I don't think its enough
for people to submit a package just because it seems to sort of work
on the version of Fedora they are running. I think we must demand
more. We need maintainers, not fly-by-night chuck-it-over-the-fence
one-off packagers. People who submit packages must commit to long term
care and feeding of the package across multiple releases of Core...and
that means targetting the development tree as a priority and then
worry about existing Core releases.

-jef"bah upstream released a new version 2 hours ago...why doesnt
fedora have a new package yet...2 whole hours wasted..thats 2 hours of
gentoo compiling up in smoke"spaleta