Proposed Alpha criteria adjustments
jlaska at redhat.com
Wed Jul 27 14:04:47 UTC 2011
On Tue, 2011-07-26 at 17:27 -0700, Adam Williamson wrote:
> On Tue, 2011-07-26 at 14:35 -0400, James Laska wrote:
> > > The asymmetry there was intentional and I sort of like it; I think it's
> > > a bigger problem if we install to your type of storage then shut it down
> > > uncleanly than if we just don't install to it. But on the other hand,
> > > you could argue we can capture any really serious cases under the Final
> > > 'data corruption' criterion. So, I can see both sides on this.
> > To make sure I follow your concerns ... by linking the storage
> > partitioning and console-based shutdown, you worry we're exposed to
> > other storage scenarios (RAID, iSCSI, FCoE etc...) where shutdown
> > wouldn't work and might leave the system in need of sck (or worse)?
> > My rationale for making the link between shutdown and partitioning was
> > because it seemed odd to accept a RAID-related shutdown bug as an Alpha
> > blocker, but at the same time reject anything related to installing
> > RAID.
> I understand that, but consider: the fact that we don't *require* (for
> e.g.) RAID installs to work at Alpha doesn't mean that they *never
> work*. In fact, they usually (or at least sometimes) do. I'd suggest
> that probably, at Alpha time, *at least* one storage option that's not
> required to work, does work. And that means probably _someone_ out there
> is using it. Sure, any data you put on an Alpha distribution is data you
> don't care about and etc etc, which is why we made the data corruption
> criterion Final stage, so I can see both ways on this, just wanted to
> explain my rationale.
> > Would you feel comfortable if in addition to the proposed Alpha shutdown
> > criteria, we also update the existing Beta desktop-shutdown criteria to
> > include the "desktop, and console-based, mechanisms for shutting down a
> > system ..."?
> Mm, I dunno, we don't wanna make it too complicated, I guess.
Agreed. Thanks for the feedback. I've updated the criteria  with
your proposed rewording. We can of course revisit should any problems
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://lists.fedoraproject.org/pipermail/test/attachments/20110727/1e4fc8c1/attachment.bin
More information about the test