[cloud] #36: Coordinate F21 / fedora next website
by Fedora Cloud Trac Tickets
#36: Coordinate F21 / fedora next website
----------------------------+-------------------------------
Reporter: mattdm | Owner: jzb
Type: task | Status: new
Priority: normal | Milestone: Fedora 21 (Final)
Component: Website & Wiki | Keywords:
----------------------------+-------------------------------
'''Summary:''' Since we are now one of the three top level artifacts
Fedora produces, we want to emphasize our unique niche. Updated website
with new flashier branding, plus tools for selecting different images for
different use cases
'''Importance:''' vital (it's basically part of the whole exercise)
'''Timeframe:''' F21 release / arguably, having the web site up ''is'' the
release. And it'd be nice to have earlier, like at the alpha and beta
'''Fedora Sub-Project/SIG:''' Websites
'''Cloud SIG owner:''' Joe Brockmeier
https://fedorahosted.org/fedora-websites/ticket/248
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/36>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
9 years, 8 months
[cloud] #16: rename cloud spin kickstart to distinguish the cloud base image
by Nobody
#16: rename cloud spin kickstart to distinguish the cloud base image
--------------------+--------------------------------
Reporter: mattdm | Owner:
Type: task | Status: new
Priority: minor | Milestone: Fedora 21 (Branch)
Component: --- | Keywords: meeting
--------------------+--------------------------------
I have been calling the new general purpose cloud image "Fedora Cloud
Base" to distinguish it from the Docker image, the Big Data image, and a
potential OpenShift image (if that turns out to not be the Docker one.)
I propose we officially call the general-purpose cloud image (currently,
the only one) "Fedora Cloud Base". And I'm tagging this with the meeting
keyword for ratification.
One behind-the-scenes complication is that the spins process involves
assembling kickstart fragments, one of which is suffixed with "-base.ks"
already, so there is a "cloud-image-base.ks", which would presumably
became "cloud-base-base.ks", which is... awesome? silly? One of those.
--
Ticket URL: <https://fedorahosted.org/cloud/ticket/16>
cloud <https://fedorahosted.org/cloud>
Fedora Cloud Working Group Ticketing System
10 years
Fedora.next QA planning: generic / Product-specific release criteria and blocker review issues
by Adam Williamson
Hi, folks. So continuing with the theme of setting up the Fedora.next QA
process, I thought before going too far with draft release criteria etc,
we could discuss a couple of important points that have come up since I
sent out the draft test plan.
There are two kind of similar issues in particular I'm thinking of.
First, at the QA meeting this week, tflink pointed out that we would
need to decide whether we will have sort of 'parallel' blocker/freeze
exception bug processes for each product. That is, do we have:
F21FinalBlocker
F21ServerFinalBlocker
F21WorkstationFinalBlocker
etc etc, and separate lists of blockers on
http://qa.fedoraproject.org/blockerbugs/current per product (and
non-Product-specific), and separate meetings? Or do we keep the
'unified' blocker nomination / review process, and just handle blocker
bugs for all Products within it?
At first blush I'd incline to keeping a single unified process, because
splitting them up seems like an awful lot of work and I'm not sure it
comes with a clear benefit. It also relies either on reporters correctly
determining what product their bug is relevant to, or on a triage step
for blocker nominations.
However, it's worth noting that if we allow the release schedules for
the Products to diverge in future, it would probably then be inevitable
that we'd need split blocker review (and release validation, for that
matter).
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_Relea... , https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Beta_Releas... , https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Cloud_Final_Relea... - 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).
Thoughts on the best approach for each of these issues would certainly
be appreciated! I thought it'd be best to take some time to think them
over before moving ahead with drafts and so on.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
10 years
Re: Fedora.next QA planning: generic / Product-specific release criteria and blocker review issues
by Matthew Miller
On Wed, May 28, 2014 at 10:59:31AM -0400, Stephen Gallagher wrote:
> >> I'm of the opinion that we should keep the blocker process
> >> unified until and unless that becomes impossible. The only
> >> benefit I can think of to separating them would be metrics, and I
> >> cannot measure the degree to which I don't care about metrics :)
> > I think we should care about metrics, and I think this would be
> > very useful to track, even though I agree it'd be better to combine
> > into one actual process at this point.
> I specifically meant "metrics about whether issues are specific to one
> Fedora release or another". I should probably start drinking coffee.
Coffee is delicious. But even in a highly caffeinated state, I'm curious why
you don't think this specific thing is interesting. Unless you are saying
that it's immeasurable because you *care so much*. :)
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
"Tepid change for the somewhat better!"
10 years
Re: Fedora.next QA planning: generic / Product-specific release criteria and blocker review issues
by Matthew Miller
On Wed, May 28, 2014 at 08:11:16AM -0400, Stephen Gallagher wrote:
> I'm of the opinion that we should keep the blocker process unified
> until and unless that becomes impossible. The only benefit I can think
> of to separating them would be metrics, and I cannot measure the
> degree to which I don't care about metrics :)
I think we should care about metrics, and I think this would be very useful
to track, even though I agree it'd be better to combine into one actual
process at this point.
--
Matthew Miller -- Fedora Project -- <mattdm(a)fedoraproject.org>
"Tepid change for the somewhat better!"
10 years
Re: Fedora.next QA planning: generic / Product-specific release criteria and blocker review issues
by Bruno Wolff III
On Wed, May 28, 2014 at 08:11:16 -0400,
Stephen Gallagher <sgallagh(a)redhat.com> wrote:
>-----BEGIN PGP SIGNED MESSAGE-----
>
>I'm of the opinion that we should keep the blocker process unified
>until and unless that becomes impossible. The only benefit I can think
>of to separating them would be metrics, and I cannot measure the
>degree to which I don't care about metrics :)
If the release dates of the products diverge, we might want to track
which specific products are being blocked. That isn't happening now,
but has been mentioned as a future possibility.
10 years
Draft Fedora 21 Test Plan
by Adam Williamson
Hi, folks! So, I quickly bashed out that draft F21 Test Plan I've been
threatening to write for the last month or so.
https://fedoraproject.org/wiki/User:Adamwill/Draft_Fedora_21_test_plan
So, what's the idea here?
Really, I'm just trying to come up with a starting point for all the
decisions we need to make and planning we need to do for Fedora 21
testing, especially release validation testing, especially as regards
Fedora.next. There's some mention of other stuff in there, but what I'm
really trying to think about is what we need to do to extend our test
processes to cover all the stuff that's coming as a part of .next.
I think the most interesting points are these:
* There are several practical implications from the test plan - just
Work We Need To Do. Most obviously, we need to draw up release criteria
and supporting test cases for the Fedora.next Products. We also will
need to adjust the
https://fedoraproject.org/wiki/QA/SOP_Release_Validation_Test_Event SOP
to include those cases/matrices as they're created, and adjust the
https://fedoraproject.org/wiki/Release_criteria page to refer to/include
the Product-specific release criteria as *they're* created.
* Responsibilities! Particularly, in this *draft* Test Plan, I've
suggested that creating the Product-specific criteria and test cases
should be the responsibility of the relevant Working Groups, with
assistance from the QA team. They would also be jointly responsible,
along with the QA team, for conducting Product-specific testing, on the
general principle that the more Product-specific a bit of testing is
(and the more domain-specific expertise it needs), the more it's the
WG's responsibility and the less it's QA's responsibility. Note that
(again, as a suggestion in this draft) the QA team is still responsible
for Fedora 21 testing *overall* - i.e. it's the QA team's responsibility
to make sure the WGs do the stuff assigned to them in the plan. If that
makes sense. Discussion welcome!
* Feasibility. This is, of course, one I really want to nail down. It
will require, though, that the Product-specific release criteria and
test cases / matrices get written. Once we have those, we can try and
make a realistic judgement as to whether we as a project - the QA team
and the WGs - actually have the resources to complete the minimal
necessary level of testing within the scope of the F21 schedule. If we
don't think that's going to be the case, we can take that to FESCo, and
we can decide what to do about it that way. In the meantime I've
provided a *very* vague 'Required resources' section just to sort of
flag this up in a modest way.
I'd really, really appreciate feedback on this draft from all interested
parties - QA folks, WG folks, FESCo, anyone at all reading this who has
an opinion. Please, bikeshed away. It all helps.
I'll aim to kick off discussion between the WGs and QA about creating
Product-specific release criteria and test cases next week. Obviously
that's *somewhat* subject to feedback on this very draft, but I can't
really envisage a world in which we aren't going to need those two
things to happen, and whoever's job we ultimately decide it is, I don't
*think* that me just kicking off an attempt to draft them can be a bad
thing.
Thanks folks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Twitter: AdamW_Fedora | XMPP: adamw AT happyassassin . net
http://www.happyassassin.net
10 years
