release criteria, data corruption

[Chris Murphy]

On Jul 24, 2014, at 4:14 PM, Mike Ruckman <roshi at fedoraproject.org> wrote:

> 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.

Just to be clear, I'm suggesting keeping the language that says block until fixed or noted in common bugs. I'd like to think that'd be uncontroversial because it's really easy to just common bugs it.

If anything, I'd add two things, just to this newish category of "data corruption/loss of existing user data"

a.) Anaconda's alpha & beta warning could suggest reading Common Bugs/Release Notes for major bugs that may include data corruption/loss bugs.

b.) For final release, I think it's reasonable to block on such known bugs until fixed or somehow mitigated, not merely subscribe them to common bugs.

If we're willing to block on "fix or document" in beta, then presumably we'd block on "fix" for final.

Chris Murphy