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

[Toshio Kuratomi]

On Thu, Aug 05, 2004 at 11:04:39PM -0400, Jeff Spaleta wrote:
> 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,
> 
I'll buy that.  There does have to be some commonality for mentoring to work
so requiring a recent stable Core is valid.  And willingness to sync with
devel if someone's extending the help is part of the process of working as
a member of a community project.

> > 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 you've got the correct interpretation (now that I've re-read it.)
I'm suggesting an alternative to part of his proposal as I think there needs
to be a space for both styles of work.

> > 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.
> 
Haven't looked.  I'll take a look.  The present state of the art may be
better than I think.  Also note that I don't doubt that syncing with devel
will help do this, I just think it's the easiest of the problems to solve.

>  > 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.
> 
That coordination should be happenning whether it's synced to the devel
tree or not, yes?  Are we saying this is going to be easier to achieve when
it's the Extras maintainer who's supposed to be tracking Core rather than
the Core developer who's supposed to be tracking Extras?

> > .... 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.
> 
Yep.  And I can see a need to keep moving maintenence forward.

I personally wouldn't find a requirement to build against the latest stable
release onerous.  I don't know if it's a good idea or not for the project's
health, though.  Maybe Fedora Legacy could take the contributions for older
releases and if we find there's more people who package for Legacy than for
recent FC we'll know we're doing something wrong.

> > 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.
>
I agree with your goals here.  My only idea for enforcement is to leave
behind packagers who won't work to integrate fixes that enable development
builds.  A package which targets only FC1 is a different package from one
that targets only FC2/FC-devel/etc after all.

-Toshio