[cloud] #63: list fedora accounts needed for releng to make official cloud images content

2014-05-29 Thread Fedora Cloud Trac Tickets
#63: list fedora accounts needed for releng to make official cloud images
content
+
 Reporter:  mattdm  |  Owner:
 Type:  task| Status:  new
 Priority:  normal  |  Milestone:  Fedora 21 (Branch)
Component:  --- |   Keywords:
+
 What official accounts and agreements do we need to upload cloud images to
 our intended targets, including Amazon AWS, Google GCE, and etc?

 What do we need to a) upload docker base images and b) do docker trusted
 builds?

-- 
Ticket URL: https://fedorahosted.org/cloud/ticket/63
cloud https://fedorahosted.org/cloud
Fedora Cloud Working Group Ticketing System
___
cloud mailing list
cloud@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/cloud
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct


Re: Fedora.next QA planning: generic / Product-specific release criteria and blocker review issues

2014-05-29 Thread Adam Williamson
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