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 -- test mailing list test@xxxxxxxxxxxxxxxxxxxxxxx To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
