On Tue, 2014-05-27 at 18:22 -0700, Adam Williamson wrote: > Second, there's a similar issue of organization with regard to the > release criteria. I haven't explicitly written this down anywhere, but > I've been sort of unconsciously expecting that we'd keep the existing > 'generic' release criteria pages for criteria that are not > Product-specific, and then we'd have Product-specific release criteria > pages which would basically be *additive*: they'd add additional > criteria applicable only to that Product. They could also perhaps > 'patch' the generic criteria to a limited degree, though this would get > messy if the delta got too great. > > However, Mike (roshi) has produced draft release criteria for the Cloud > product as part of his work on the 'test outline' for that product - > https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Alpha_Release_Criteria , https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Beta_Release_Criteria , https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Final_Release_Criteria - and used another possible approach; the criteria he has drawn up are clearly intended to be *comprehensive* with regard to the Cloud product. They would not need to be read in conjunction with the 'generic' criteria. > > I'm not as sure which approach I prefer here, and to a degree the > difference between them isn't as clear cut as it appears at first > glance; however the criteria are ultimately presented, we'll likely have > several that are applicable to multiple Products. Even if these are > displayed multiple times on 'comprehensive' pages for each Product, they > might be shared at the 'source' level using mediawiki transclusion, for > instance (to prevent them diverging unintentionally). And of course we > aren't necessarily tied to mediawiki for presenting the criteria, which > is another factor to bear in mind (I know one of tflink's Grand Plans > involves a different way of maintaining and presenting the release > criteria). So, just an update on this part: I've spent today poking at various approaches to this. The bad news is that handling it at all cleanly with the approach we generally seemed to like - having separate pages for each product, but using transclusion to share 'common' criteria - is going to be difficult and would wind up looking pretty ugly on the 'back end', due to the limitations of mediawiki transclusion. Basically I think we'd unavoidably wind up with a huge pile of template pages containing very small numbers of release criteria - or even just one criterion, or even a *subsection* of one criterion. The resultant criteria pages would look nice and clean when you just viewed them, but it'd be a bit of a mess behind the scenes, and it might be hard to figure out how the heck to edit anything properly. There's a few reasons for this: * Criteria don't just map nicely as 'universal' or 'specific to one product'. Some are specific to a given type of install medium, for instance - which would make them apply to, say, two products but not the third. We couldn't just have template pages for 'universal' and each product, but we'd also need template pages for each install medium type, and the criteria pages for each product would have to transclude the correct template pages for the install medium types that product actually ships. There may be even more factors like this that I haven't noticed yet: each one would add another degree of complexity. * Transclusion is a kind of 'all or nothing' thing. You can't break up transcluded blocks. This is a problem, because we organize the criteria into sub-sections. So we wind up needing a set of template pages *for each criteria sub-section*. * There are many criteria which cover multiple circumstances, only some of which apply to each Product (or media type). The criterion "Release-blocking images must boot" is universal, for instance, but its notes are not: some of its notes wouldn't apply to some products. So do we split a single release criterion up and have template pages for each line of its notes? That seems a bit nutty. But it also reads awkwardly if we have a "Fedora 21 Workstation Alpha release criteria" page which includes notes like "Supported cloud environments: Release-blocking cloud images must boot in the Fedora OpenStack Cloud and in Amazon EC2." Do we just give up on 'dynamically' sharing that criterion between pages, and write static copies of it into each product's page? Then maybe it unintentionally diverges between the three some time. So...I'm not optimistic we'll be able to handle it particularly cleanly by transclusion. For now what I'm planning to do is mock up completely static versions of the criteria pages as they apply to each Product, and then just look at them to see just how bad the problem is, just how tricky it would be to reproduce that same result using shared templates. If it's really as bad as it seems at first glance, I suspect the only viable approaches will be: 1) have separate criteria pages for each product with maybe just basic transclusion for only those criteria which can be shared perfectly cleanly between all three products 2) keep one combined set of release criteria, and just add new sections to it which are specified only to apply to particular products 3) design a much better system for storing and displaying the release criteria than Mediawiki 3) would be nice, of course, but takes resources. tflink would like to work on it, but we can hardly call it a high priority right now with taskotron work still needing to be done. 2) is a bit ugly, but it's the closest to our current approach, and probably the easiest to do. 1) gives us a nice 'clean looking' result but is somewhat more work to implement and carries a risk of unintentional divergence of the criteria in future, when changes made to the criteria for one product aren't properly applied to the other products when they should be. Anyway, that's where I'm at with this right now...when I have anything concrete I'll throw it up for people to look at. If anyone has any brilliant ideas or a really elegant implementation of transclusion, or something, that'd really help. -- Adam Williamson Fedora QA Community Monkey IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net http://www.happyassassin.net _______________________________________________ cloud mailing list cloud@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
