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

[Jeff Spaleta]

On Thu, 05 Aug 2004 21:16:25 -0400, Toshio <toshio at tiki-lounge.com> wrote:
> 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.

A fair point. Everything has trade-offs. I could live with new
packagers being encouraged to build against the latest Core release
for a window of time with an intent to sync development with help. But
I think for example encourging new contributors to target FC1 right
now  is a dimishing returns situation even on the mentoring front.
Contributing is part access and part responsibility, I think that at a
minimum its appropriate to require new contributors to be targeting
new packages against the newest available Core release instead of the
oldest available as a compromise between making the process accessible
and making sure packagers are committed to taking responsibility. If
you can't be bothered to run the latests release, thats going to lead
to significant problems to your ability to maintain a Fedora package,

> Although I do think it's a goal worthy of being done at the collection level.

I still think you have a different interpretation of Tiemann's
strawman than I do. Hopefully
Tiemann finds time to read these rantings before he redrafts to clarity what
'at the collections level' means in your sentence. I'll refrain from
further twisting Tiemann's proposal for my own agenda until his
promised update next week.
  
> 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.  

Cough... have you see the work Dirk Westfal is doing with his custom
rpm based livecd creation templates? 
http://www.linux4all.de/livecd/barebone/index.htm
I should let Dirk comment on the difficult livecd issues are as he views them.
And i should let Marco comment on the difficult rule issues are as he
views them.
What limited personal communication i've had with both of them makes
me think getting Extras synced with Core helps them. My assessment of
the situation could of course be wrong, so it would be nice for them
to at least give a brief "Jef is on crack" response if I'm offbase
here.

 > Ironically, that's actually pretty close to my thoughts on what belongs
> in Core vs Extras:  How much harm does instant gratification get you?

If its not co-ordinated with appropriate action tied to the devel
tree.. it potentially gets you a broken update path from Core release
to Core release.

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

Trade-offs, personal interests played off against larger interests of
the project you are contributing to. I want a balance between the two.
I'm not saying that people can't build new stuff for FC1 right now,
but I want their desire for instant gratification balanced against the
larger projects need for continued maintainence of that package for
FC2 and FC3 development that is currently on-going.

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

I want people to committed to making a good faith effort to work on
issues in the development tree. I have no illusions what-so-ever that
all issues with Extras packages are going to be resolvable in a timely
manager inside development. I fear for the sanity of anyone who takes
of the challenge to maintain wine as an extra, thats going to be a
constant pain.  I just want a commitment to make the effort. So no i
don't think failing to build in rawhide is a reason to exclude a
specific package from existing releases. But if the packager isn't
working to resolve the problems with the package in the development
tree... that needs to have some consequences.

-jef