Development to release quality (was: Re: openssh: no pre-release sanity check?)

Alex Hudson fedora at alexhudson.com
Mon Sep 12 09:26:15 UTC 2011


(I'm really glad this topic has come up - I think it's critically
important....)

On Mon, 2011-09-12 at 00:19 +0200, Kevin Kofler wrote:
> Clyde E. Kunkel wrote:
> > Maybe there needs to be a classification for rawhide similar to the
> > karma system for updates-testing, but limited to just a set of packages
> > that should just always work (maybe openssh would be one). 
> 
> We cannot do any useful development [[with that system]]

I mostly agree with this, if karma is used in general as a gating
mechanism as with release. However, if we think about the general
principle of karma - getting some transparency about which packages /
packagers are releasing broken - I think that's a useful thing to track.

I don't see that as being a way of assigning blame or anything like
that, but highlighting the areas which are particularly problematic.

> We just need people to grasp that Rawhide is NOT suitable for any sort of 
> production use and that it WILL break. (Not "may", "will"!) As they say: 
> "Rawhide eats babies!"

This, I totally disagree with. Without any expectation that Rawhide
should work, there is even less incentive for anyone to use it to test
it.

I view this as entirely equivalent to having a rule about not breaking
trunk in version control: I don't know anyone who seriously argues that
breaking a project compile is a good thing. Breaking the OS should be
culturally identical - that it's a "development branch" or whatever is
totally irrelevant.

The crucial reasoning here is that rawhide is a shared resource. Sure,
people using rawhide ought to know roughly how to fix stuff when it
breaks - but that imposes a maintenance burden on everyone who gets a
broken update.

Having a generally-usable rawhide would do much to improve quality in
Fedora, because more subtle errors - or bugs limited to certain
sub-populations - will get picked up much earlier. If rawhide is not
suitable for "production use", that means it will get virtually no
real-life use, and while rwmj's points about VM testing are well-taken,
it's not a real shake-down. Actual use by technically competent real
users is crucial for quality, and having to wait until alpha/beta for
large numbers of those users to try the software really is too late in
the day.

Cheers

Alex.


--
This message was scanned by Better Hosted and is believed to be clean.
http://www.betterhosted.com



More information about the devel mailing list