Re: Major criteria re-write / re-design proposal: Beta draft

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



----- Original Message -----
> Hey, folks. CCing anaconda list on this one due to the changes to the
> partitioning requirements (see below) - please send replies to test@,
> though, to avoid a thread fork.
> 
> Further to my previous mail -
> https://lists.fedoraproject.org/pipermail/test/2013-March/114198.html
> -
> I've now got a first draft of the Beta criteria, along the lines of
> the
> Alpha draft in that mail. Here it is:
> 
> https://fedoraproject.org/wiki/User:Adamwill/Draft_beta_criteria_sandbox
> 
> I did much the same as the Alpha - tried to simplify the main text as
> much as possible, and use hidden paragraphs for legalistic details.
> 
> I did not yet add the References sections. Oh, I should also note
> that
> one thing I mean to add to the References for all three milestones is
> a
> link for each criterion to the test case that enforces it. We'll also
> now be able to do links from the test cases to the criteria they
> enforce, so the two will be much more clearly tied together.
> 
> There isn't much significant change to the wording in this Beta
> draft,
> somewhat less than there was in Alpha. Mostly just places I found I
> could rewrite things without losing any meaning. The exception is
> that I
> did the partitioning criteria rather differently, as we found quite
> quickly in the F18 cycle that we were unhappy with the first attempt
> at
> re-drafting the partitioning criteria.
> 
> I decided to go with one set of criteria for guided partitioning and
> one
> for custom, explicitly written as such (it turned out we did not
> enforce
> enough requirements on guided partitioning, the way we had it written
> before). I decided to try and be less concise for this specific case,
> and write out the requirements more comprehensively. I also decided
> on
> balance this is a case where we shouldn't try to be too 'generic' as
> it
> just winds up being too vague - we had "most commonly-used filesystem
> types" before, which is so vague you could drive any kind of bus
> through
> it. So I figured we should just go ahead and specify the exact
> storage
> types we support, and adjust the list as time goes on.
> 
> I think the actual requirements I came up with accurately reflect the
> consensus among QA and anaconda team about what we should
> realistically
> support at Beta. Notably I left out anything about resizing
> partitions
> and anything about re-using existing containers; I figure those are
> more
> appropriate for Final. I also left out 'complex' configurations like
> LVM-on-RAID.
> 
> As part of the partitioning revamp I tried to make the RAID
> requirements
> more sensible (previously it talked about 'creating' hardware and
> firmware RAID, which doesn't make any sense).
> 
> Again, comments, suggested refinements etc welcome! Especially if
> anyone
> can think of a way to make any of the 'main' criteria wordings even
> shorter and clearer, that would always be a win.

Generally, I like these reworked criteria - easy to follow, the alpha
vs beta diff is really very good idea! 

For "Supported media types" and the link to the list of officially
supported methods - it's not as easy to find it on that page. I'd
say a list on criteria page would be better, even it requires sync
with the link...

I'm not sure about the Contingency section (and sorry for not pointing
it out on Alpha draft).
First thing - Alpha and Beta have a different deadline. Does it 
refer to release candidate? So RC has to be done by this deadline? Or
Go/No-Go which is on Thursday. The first makes sense - we need a 
clear blocker list to compose RC and without RC. In this case I'd 
mention RC explicitly there. Let me think about it a little bit more.

Jaroslav

> --
> Adam Williamson
> Fedora QA Community Monkey
> IRC: adamw | Twitter: AdamW_Fedora | identi.ca: adamwfedora
> http://www.happyassassin.net
> --
> test mailing list
> test@xxxxxxxxxxxxxxxxxxxxxxx
> To unsubscribe:
> https://admin.fedoraproject.org/mailman/listinfo/test
-- 
test mailing list
test@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe:
https://admin.fedoraproject.org/mailman/listinfo/test



[Index of Archives]     [Fedora Desktop]     [Fedora SELinux]     [Photo Sharing]     [Yosemite Forum]     [KDE Users]

  Powered by Linux