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

[Toshio]

On Thu, 2004-08-05 at 00:08, Jeff Spaleta wrote:
> On Thu, 05 Aug 2004 04:57:08 +0200, Ralf Corsepius <rc040203 at freenet.de> wrote:
> > The problem is: RH/FC not having fixed "known bugs" prevents
> > Fedora.US/FE from publishing packages for FC1.
> 
> I'm personally not all that thrilled at having FE packagers target
> publishing any new packages in current or old FC releases. I think new
> FE publishing should target FC development and FE 'releases' should
> freeze out on the same timescales as FC instead of obsessing over
> trying to continue to base work on an FC release that is 1 or 2 month
> away from being officially EOLd. The more FE packages that get
> introduced against the development tree... the less post-release
> problems with Core we will have with FE long term.  Continuing to add
> NEW extras against an FC release is how we break upgrade paths when
> Core consumes new functionality in development that was in the past in
> extras.
> 
> If Core+Extras ends up looking like a rolling release like i use to
> see with ximian desktop, I'm going to puke my guts out. I hate the
> rolling release model with rpm packages. You sneak in a packaging fix
> thats meant to fix something else, don't do enough QA and every user
> ends up having to try to do a package rollbacks for several packages.
> No thanks. I'll chew my own arm off first.
>
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.  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. 
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.

BTW -- My problem with Ximian Desktop as a rolling release was that it
was too interdependent.  One bad library takes ten other packages with
it.  With the current policy (That Ralf is saying is too strict) of not
allowing Extras to replace Core, I think rolling releases for Extras
makes sense.  If massive interdependencies end up in Extras I think they
should be moved to Core (from Michael Tiemann's strawman: 
    * preference for packages that maximize scope of Fedora Extras
    * preference for packages that satisfy most dependencies)
[My main reason for believing KDE should stay in Core as I don't use it
myself.]

> > You don't develop on packages for FC1, I presume?
> 
> FC1 is at best a month away from EOL (though im none too happy that
> there hasnt been an actual FIRM date about FC1 EOL but ill save that
> for another debate) if anyone is still considering building new
> packages against FC1 at this point, its seems a foolhardy goal.
>  
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.

Further, every FC system is a potential contributer to the project. 
Someone shouldn't be excluded from contributing just because their
platform is an EOL product.  Instead we should be deciding how we will
support these contributers with the goal of creating knowledgable,
trained packager who will be well versed in how to help development when
they do upgrade to a current release.

> > IMO, this substantially weakens Fedora.US/FE and therefore causes damage
> > the Fedora Project as a whole in longer terms.
> 
> I think 6 month EOL's for Core make any argument about long term
> projhect damage a little thin. Legacy with its current manpower and
> infrastructure can't handle legacy issues with FE packages. Michael
> has already said that there is reluctance currently for fedora.us
> package maintainers to continue to support packages in a legacy
> situations. Fedora Core's timescale are extremely aggressive and push
> people to move to the next release very quickly. I think the
> development model as a whole does better long term, if new Fedora
> Extras development focuses continually on the Core development tree,
> instead of dragging attention backwards to suppliment Core releases
> that have already been frozen out.  If new packages can be built
> painlessly for Core releases that are still active, great.

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.

-Toshio
-- 
_______S________U________B________L________I________M________E_______
  t  o  s  h  i  o  +  t  i  k  i  -  l  o  u  n  g  e  .  c  o  m
                                                          GA->ME 1999
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
URL: <http://listman.redhat.com/archives/fedora-devel-list/attachments/20040805/29b95f44/attachment.sig>