Proposal: Rolling Release

[Les Mikesell]

Jeff Spaleta wrote:
> 
>> That's the wrong question.  The real question is, what interface did you
>> just break in an update? You don't need to know anything about anyone else's
>> software.  You just need to provide working interfaces.  Or, when you
>> whimsically break them in updates, give a hint about how to get a working
>> version back.
> 
> Are you suggesting that we should never provide an unstable interface
> in any of the libraries or scripting modules that we package?

No, I'm saying that necessary changes should be planned, and to the 
extent possible, batched at version releases.  And where that isn't 
possible, interface and command line changes to expect should be 
published before the update so users and 3rd parties know how to work 
around the breakage.

> And
> that we only provide technologies that upstream has committed to API
> stability between subsequent releases?

I'd like that very much but given what you have to work with, I'll agree 
it is impossible.  However, like any other QA aspect, I'm suggesting 
that you do the best you can not to break local or 3rd party programs 
built on the platform you just shipped.

> Surely you aren't suggesting
> that.  You can't really expect us to hold an API stable when upstream
> isn't...that's just silly.

No, what is silly is to actually try to use a platform that you know is 
going to break because the people building it have no concern for the 
people using it.  Even simple things like the change in samba that broke 
backuppc's ability to pass windows authentication some time ago can be a 
disaster.

> At best you could maybe hope for a subset of available technologies to
> be identified as upstream interface stable, and get a subset of
> maintainers to pledge to keep interfaces stable inside a release
> timeframe in conjunction with those upstream projects.

Who forces you to push interface-changing updates out of rawhide?  If I 
wanted today's bugs from an upstream project I'd grab it from there 
instead of using a distribution's release version of the code.   The 
fedora major release cycle is already fast enough anyway.  If some 
upstream project can't settle on an interface you are doing your users a 
favor by keeping it away from them.

> There is no
> coherent initiative towards what could be generously termed a 'Fedora
> SDK'. I've seen no interest from a group of active
> maintainers..ever..to take on that problem space and commit to seeing
> it happen.  Something like this would require a community member to
> step forward and be a strong, active, persuasive leader on the effort.

I'm not sure what that even means.  If fedora has something unique, I 
don't particularly want it and don't understand why anyone would develop 
for something intentionally non-standard.  What I'd really want is for 
LSB-compliance to someday get to the point where programs running on 
Fedora would never need to know that it is fedora at all, much less the 
version and last-update-date underneath.

> I very much doubt that you are the right person to lead such an
> effort, even if you did decide this is the issue that would finally
> get you off the fence and working on something constructively.  So my
> advice to you is, dial back the rhetoric and see if you can get other
> people talking about this and identify the person you think can lead
> this initiative.

Is there someone involved in development that eats his own dog food 
(i.e. uses fedora with current updates as infrastructure for some large 
project or even in a lab setting with many users)?

-- 
   Les Mikesell
     lesmikesell at gmail.com