[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]

Re: F11 Proposal: Stabilization



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



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]