release criteria, data corruption

[Mike Ruckman]

On Thu, Jul 24, 2014 at 02:09:33PM -0600, Chris Murphy wrote:
> https://fedoraproject.org/wiki/Fedora_21_Final_Release_Criteria#Data_corruption
>
> I suggest moving this criterion from final to beta due to bugs like this one:
> https://bugzilla.redhat.com/show_bug.cgi?id=1120964
>
> Beta is rather publicly marketed, and people are actively encouraged
> to participate. Many will do this with as dual-boot. I don't think
> it's OK for known corruption of existing user data (the entire prior
> OS) to progress to beta release; but aside from that, and the ensuing
> negative experience it'd cause, it also significantly reduces the test
> coverage because we'd have to say "Hi, we want you to test beta but
> not in a dual boot scenario with Windows."
>
> Alternatively make a new beta criterion that explicitly blocks on corruption of
> existing user data, rather than corrupting newly generated data.
>
> Chris Murphy

I'm +1 for at blocking at beta for *at least* the corruption of existing user
data. 

I can see arguments for both sides. It is a "beta" which is by definition 
likely broken in some aspects (capable of destroying all the things you let 
it near). We have a warning right there in anaconda about the potential for 
being sucked down a rabbit hole of bugs. So it could easily be argued that 
whatever happens, they were warned beforehand.

But I can also see the "we advertised it" as "come try the new stuff!" so we 
should try to not eat any data they might have on disk. I don't think it's a
bad idea to block for this particular case at beta release time instead of 
final. Most people (I would guess anyway), expect a semi-finished product at
beta time - something with minor-ish issues. Eating your existing data is 
more of an alpha bug IMO.

-- 
// Mike 
--
Fedora QA
freenode: roshi
http://roshi.fedorapeople.org