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

[Toshio]

On Thu, 2004-08-05 at 16:33, Jeff Spaleta wrote: 
> 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.

My priority is to get the most people contributing and learning what
makes good packaging.  To my way of thinking, the best way to do that is
to let people package the latest one or two applications without having
to flush the whole OS.  And then (the hard part) get them to stick with
them as others critique and add their knowledge of what would make those
packages better.

> 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've just reread the proposal and see that I was misreading it the first
time through.  Fedora Extras, as the "maximal universe of packages
that:[list of requirements concerning content]" is something I agree
with.  The following explanatory paragraph that says that it will be
size limited "(based on how many packages can be integration tested
within some reasonable time before and/or after the related Fedora Core
release is frozen and released)."  Is the part I skipped.  I think it's
a mistake to require the maximal universe of packages to be synced to
the devel tree for reasons I state later in this reply.  Although I do
think it's a goal worthy of being done at the collection level.

> 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.

I think the syncing of packages is the least of your worries.  Creating
livecd and Rule based mediasets through cherry-picking Extras strikes me
as close to impossible even with ordained syncing.  This is where I
think collections have to pick up the slack rather than a global Extras
policy.  Collections maintainers will have to approach packagers and
tell them they want to use the package in the collection and what the
needs of the collection are (Can you merge this change, what release
date we're targeting, etc).  In return, the packagers would specify what
their needs are (I can't actively sync against the new Core, so someone
else will have to do testing and fixing in that environment, I'm also a
member of this Collection and they need to make sure that this optional
feature is always enabled.)
  
>   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.
> 
I can see that as one end product.  But I wouldn't hold that it was
achievable until Red Hat's vision is stated to coincide with it.

> 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.

Very true.  And once again, I think it needs to be handled at the
collections level.  With people who want to maintain collections not
just selecting packages but working with package maintainers to
integrate packages in features and time-frame.

> 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.
I don't see it either for Extras (in my view of Extras that is.)  But I
do see it happening with a collection of a subset of Extras where 
contributers have agreed that their priority is to target the Core
development schedule.

> 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.
Sure.  I can agree with the idea that integration belongs in the devel
tree so it doesn't pull things backward.  I can also agree with Ralf
that at times there's too much focus on the next release and not enough
on having things buildable on a stable release.  I don't have a solution
for reconciling that part so I won't argue either point.  

> >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.
>
See my statements in the last two blocks for why I think targeting devel
makes this mandatory.

> > 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.

Ironically, that's actually pretty close to my thoughts on what belongs
in Core vs Extras:  How much harm does instant gratification get you? 
Kernel, most libraries, rpm, build/language toolchains are Core because
upgrading them inappropriately will break things.  Useful programs that
have tons of dependencies belong there too.  Extras should be largely...
extra.  If I live at the bleeding edge and it breaks, my system won't
fall apart, just that one package.  (This also implies that bleeding
edge software that requires Core library updates are a no-no... which is
already Fedora Extras policy...)

Additionally, I think instant gratification is a factor that should be
used to bring new packagers into the fold. 

> > 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... 
> 
sure.  Priority I can understand...

> if YOU as an invidual packager want to
> build for FC1 great, after you have the package synced with Core
> development. 
... but I don't think a requirement to sync with Core development is
reasonable.  Forcing people to use unstable software so they can
contribute isn't why I'm packaging.

> 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.

Right.  As I said, I don't have anything constructive to add on either
side of the priority of backports front so I'm staying out of that.

>  
> > 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.
>   
Right.  But it's not just build infrastructure.  It's also running and
testing the package.  If it builds in the devel tree but is only tested
on a GenToo box, do we really want to clear it for inclusion?  More
reasonably, there are going to be times when a package is created on a
FC-release-X box, QA'd by others on FC-release-X boxes, and the build
fails on RawHide is that grounds to exclude it?

> 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.

I agree with the care and feeding of the package part.  That's how
packagers will learn to become better.  I don't necessarily agree with
targeting the devel tree.  If we want to lower the bar so new packagers
can get involved, we need to make it so they can experiment with
building and testing on their system which will probably be a Core
release tree, not the devel tree.  OTOH, having someone say, "This
didn't build on the latest test release, here's a patch to fix it."
would be good.  On the gripping hand, what happens when someone doesn't
step forward with patches?  What happens when the patches make the
package incompatible with the release the packager is running?  Then
they've invested a lot of effort to create a package that isn't
maintainable by them.

-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/9a36fb0c/attachment.sig>