F11 Proposal: Stabilization

[Michael DeHaan]

Tom "spot" Callaway wrote:
> On Mon, 2008-11-17 at 16:35 -0500, Jon Masters wrote:
>   
>> Yo,
>>
>> Can I make a proposal for a major theme for an upcoming Fedora (whether
>> F11 or F12): Stabilization.
>>
>> Rather than the latest bells and whistles, I would personally much
>> prefer that stuff that used to work didn't break randomly, and that
>> stable Fedora updates wouldn't result in me wondering whether suspend,
>> graphics, SELinux, or some other feature that was working was going to
>> break today. This isn't actually a rant, more pointing out a necessity.
>>     
>
> I'm not sure what magic fairy we'll have to sacrifice for this. We're
> always going to be moving forward and things are going to break.
>
> If you're volunteering to help QA, then I applaud you.
>
> ~spot
>
>   

One thing that comes to mind -- Debian style stable, testing, unstable, 
and experimental is kind of an interesting policy that gets halfway 
there, but it's probably wrong for us.   Rather, don't think of those 
particular time frames, but the idea of having different levels of 
repos.      This is closer to Casey's proposal a few threads down.

However he suggests something that might be a bit too close to EPEL -- 
EPEL doesn't work because a package can easily slip from testing to EPEL 
because it's just a monthly roll -- some packages are just a week old 
and there is no voting.  For some packages, voting would be hard to get.

Perhaps this discussion would be better framed around use cases of 
problems it is trying to solve, and then we can find solutions that fit 
those use cases:

Use case --- I have no desire to update my desktop, but I want newer 
virt tools, and I want security updates.

Use case -- my friend wants newer Open Office but that's it, and doesn't 
want to update ImportNetworkThingy until many people say it's ok.

How do we compare against the above already, and how might we take small 
actionable steps to get closer to them?

The above use cases almost seems to imply Debian pin priorities, and 
that makes me afraid.

Hard problem.

--Michael