Re: Draft Fedora 21 Test Plan
On Fri, May 23, 2014 at 06:02:07PM -0700, Adam Williamson wrote: 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? Psshh -- so much for your claim of not doing any real work. This looks great! I'll put discussing it on our next Cloud WG meeting. * 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 Mike has some drafted up for cloud at https://fedoraproject.org/wiki/User:Roshi/QA/Cloud_Docs/Test_Plan#Test_Pass.2FFail_Criteria. It'll need a bit more by way of specifics. * 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, This seems like the right way to me, too. 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! Yeah. If something isn't working, do you think the best path is QA-WG directly, or should it be QA says something to FESCo, FESCo works with WG? Since parts of this are new to all of us, and other parts new to a lot of us, maybe it'd be good to put suggested/reasonable deadlines on some parts of the responsibilities? That helps put in focus what needs to be done. -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! ___ 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: [cloud] #59: Process for determining when and why Docker trusted images need to be rebuilt
#59: Process for determining when and why Docker trusted images need to be rebuilt +- Reporter: scollier| Owner: Type: task| Status: new Priority: normal | Milestone: Future Component: Docker (Other) | Resolution: Keywords: meeting | +- Changes (by jzb): * cc: jzb@… (added) -- Ticket URL: https://fedorahosted.org/cloud/ticket/59#comment:3 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: Draft Fedora 21 Test Plan
On Tue, May 27, 2014 at 7:58 AM, Matthew Miller mat...@fedoraproject.org wrote: On Fri, May 23, 2014 at 06:02:07PM -0700, Adam Williamson wrote: 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! Yeah. If something isn't working, do you think the best path is QA-WG directly, or should it be QA says something to FESCo, FESCo works with WG? If you want a collaborative effort, then the WGs and QA should be working directly together. Encouraging one party to tattle to FESCo on the other (either way) isn't setting things up for success. This will be hard at times. The two groups need to work through those issues mostly on their own or people are going to be disenfranchised that the WGs are actually in control of their products at all. josh ___ 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: Draft Fedora 21 Test Plan
On Tue, May 27, 2014 at 12:58:12PM -0700, Adam Williamson wrote: As with all the others who've weighed in so far, I agree that the optimal path is just for us all to talk to each other. I generally prefer workflows that assume everyone's happy to work positively together to a consensus solution over ones that assume everything will be oppositional and must therefore go through a higher authority. So, yep, IMO we should just talk to each other, and FESCo should only be invoked to resolve irreconcilable disputes (of which we hope there won't be any). Yeah, and especially with the way Josh put it, this approach seems obviously better. Let's just pretend I didn't suggest the other way. :) Ideally I'd like to work fairly rapidly and get, say, the initial release criteria ready by the end of next week, and then get the required test cases and matrices written between then and branching (which is 'no earlier than July 8' on current schedule). As someone who is not actually volunteering to do much more than cheerlead for this particular bit of writing, that schedule sounds good to _me_ -- Matthew Miller-- Fedora Project--mat...@fedoraproject.org Tepid change for the somewhat better! ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
Fedora.next QA planning: generic / Product-specific release criteria and blocker review issues
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_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). 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 ___ cloud mailing list cloud@lists.fedoraproject.org https://admin.fedoraproject.org/mailman/listinfo/cloud Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
