Re: [Test-Announce] 2011-07-15 @ 17:00 UTC - F16 Alpha blocker bug review #1
On Wed, 2011-07-13 at 20:58 +, Jóhann B. Guðmundsson wrote: On 07/13/2011 08:11 PM, James Laska wrote: Quite a bit smaller than the 100+ bugs on the list. Was that decision from a recent FESCO meeting? It's the one held on 15 June. See this thread on -devel [1] also note that FESCO accepted the feature [2] on the bases that native systemd unit files will be accepted up to beta after that no more native systemd service files will be introduced in the release during it's lifetime. Developers will need to convert the old sysvinit init scripts to native systemd ones and/or review and use ones that have been provided to them and package them as per packaging guidelines which can be found here http://fedoraproject.org/wiki/Packaging:Guidelines:Systemd with sample scriptlet snippet which can be found here http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd no later then beta for inclusions in the release. 1.http://lists.fedoraproject.org/pipermail/devel/2011-June/152780.html 2.http://fedoraproject.org/wiki/Features/SysVtoSystemd Thanks, that's all I could find too. I don't read that as meaning anything sysvinit-systemd gets a free ride as an automatic blocker. I read that as FESCO has approved the sysvinit-systemd feature to continue developing beyond the feature freeze. Thanks, James signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] 2011-07-15 @ 17:00 UTC - F16 Alpha blocker bug review #1
On Wed, 2011-07-13 at 18:36 -0700, Adam Williamson wrote: On Wed, 2011-07-13 at 19:25 +, Jóhann B. Guðmundsson wrote: On 07/13/2011 07:17 PM, James Laska wrote: Your ideas are consistent with how we've handled this before, I don't think I could have articulated nearly as well though:) My understanding is that FESCO is the right place to discuss whether a feature should block a release or not. They already did and decided that what's on core + base + base-x would become alpha blockers which later got extended to included services we ship on the live cd. I think we could still talk to them about tweaking that process, though. I could easily be misinterpreted here, so I'll try to be precise... We've set up this whole blocker bug process that works quite smoothly to achieve what it sets out to achieve: validate the quality of the release. We have the release criteria and the blocker bug SOP and the system of bugs and meetings to carry it all out. That's great. Ultimately what the process achieves is QA's sign-off on the release: if there are no blocker bugs we say 'this release meets Fedora's quality standards'. Now, it should always be true that if there are any blocker bugs, the release cannot go out. *But*, crucially, the converse is not true: it is not inevitably be the case that if there are _no_ blocker bugs, the release _must_ go out. All it means is that we - the QA group - sign off on the release and say as far as we're concerned, it's okay to go out. QA isn't the *only* group that signs off on releases. FESCo does too. As I see it, it'd be perfectly fine for FESCo to say 'well, even though it meets all the quality standards, we do not want to sign off on this release until Feature X is done'. As I see it, that's a _separate_ process from the blocker bug / release validation process. FESCo does not need to use the blocker bug process to manage its decision to sign off on the release, and I think it would actually be better if they didn't. I'm dancing on pin heads here to some extent - the practical result is going to be the same whether we use the blocker process to manage FESCo's decisions on the feature process or whether we decide to come up with a different process for that - but I think it helps to have processes that are clearly and strictly defined: I think if we use blocker bugs to manage some specific aspect of the feature process, it dilutes both processes. I fully agree. The net result is the same, I just don't think we should start tracking incomplete features as blocker bugs. I think it'd actually work out better if there were a separate mechanism by which FESCo managed its choice of whether or not to sign off on the release due to issues in the feature process. Thoughts? Should I talk to FESCo about this? Might be good to raise awareness, so they know we don't plan to automatically accept any features (delayed or approved) as blocker bugs. We do list a goal for the Alpha to Test accepted features of Fedora 16. While that may on the face seem to indicate we should hold the release for all accepted features, I believe we intentionally listed this as a goal, and not a requirement. To fit this into our existing criteria vernacular, I would probably suggest that FESCO agrees to delay acceptance of the SysVinit-systemd feature until after Alpha. Acceptance would be revisited after Alpha and would pertain only to the proposed livecd scope. If the proposed changes are completed at that time, the feature would be accepted. Anyway, like you said, semantics. I'm just trying to make sure we're true to our criteria. Long story short, I agree it makes sense to keep this separate from the blocker process. Thanks, James signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] 2011-07-15 @ 17:00 UTC - F16 Alpha blocker bug review #1
On 07/14/2011 11:16 AM, James Laska wrote: On Wed, 2011-07-13 at 20:58 +, Jóhann B. Guðmundsson wrote: On 07/13/2011 08:11 PM, James Laska wrote: Quite a bit smaller than the 100+ bugs on the list. Was that decision from a recent FESCO meeting? It's the one held on 15 June. See this thread on -devel [1] also note that FESCO accepted the feature [2] on the bases that native systemd unit files will be accepted up to beta after that no more native systemd service files will be introduced in the release during it's lifetime. Developers will need to convert the old sysvinit init scripts to native systemd ones and/or review and use ones that have been provided to them and package them as per packaging guidelines which can be found here http://fedoraproject.org/wiki/Packaging:Guidelines:Systemd with sample scriptlet snippet which can be found here http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd no later then beta for inclusions in the release. 1.http://lists.fedoraproject.org/pipermail/devel/2011-June/152780.html 2.http://fedoraproject.org/wiki/Features/SysVtoSystemd Thanks, that's all I could find too. I don't read that as meaning anything sysvinit-systemd gets a free ride as an automatic blocker. I read that as FESCO has approved the sysvinit-systemd feature to continue developing beyond the feature freeze. I never said it was a blocker what I said was that it was aggreed to that service in +core + base + base -X plus what service are on the live cd would be alpha blockers see the meeting logs and the the thread on devel for that discussion. Once we are passed alpha I will do assessment on the conversion process and discuss with Fesco what ( if any ) next goal should be ( potential beta blockers ) . JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] 2011-07-15 @ 17:00 UTC - F16 Alpha blocker bug review #1
On 07/14/2011 11:28 AM, James Laska wrote: Long story short, I agree it makes sense to keep this separate from the blocker process. Agreed as well The sysv to systemd feature is a special case and should not be mixed into the standard QA workflow. The QA community should be aware of how important that it is that we convert and ship as many native systemd unit in one release cycle and potential issues we have to deal with if we dont and should perhaps help things move along anyway that said it's up to Fesco to evaluate on per sysv legacy init script bases when the time comes if they should be blockers or not since there might be substantial code writing/rework that needs to be done to properly integrate that service to systemd which for example might be the case with Audit. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] 2011-07-15 @ 17:00 UTC - F16 Alpha blocker bug review #1
On Thu, 2011-07-14 at 11:31 +, Jóhann B. Guðmundsson wrote: On 07/14/2011 11:16 AM, James Laska wrote: On Wed, 2011-07-13 at 20:58 +, Jóhann B. Guðmundsson wrote: On 07/13/2011 08:11 PM, James Laska wrote: Quite a bit smaller than the 100+ bugs on the list. Was that decision from a recent FESCO meeting? It's the one held on 15 June. See this thread on -devel [1] also note that FESCO accepted the feature [2] on the bases that native systemd unit files will be accepted up to beta after that no more native systemd service files will be introduced in the release during it's lifetime. Developers will need to convert the old sysvinit init scripts to native systemd ones and/or review and use ones that have been provided to them and package them as per packaging guidelines which can be found here http://fedoraproject.org/wiki/Packaging:Guidelines:Systemd with sample scriptlet snippet which can be found here http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd no later then beta for inclusions in the release. 1.http://lists.fedoraproject.org/pipermail/devel/2011-June/152780.html 2.http://fedoraproject.org/wiki/Features/SysVtoSystemd Thanks, that's all I could find too. I don't read that as meaning anything sysvinit-systemd gets a free ride as an automatic blocker. I read that as FESCO has approved the sysvinit-systemd feature to continue developing beyond the feature freeze. I never said it was a blocker what I said was that it was aggreed to that service in +core + base + base -X plus what service are on the live cd would be alpha blockers see the meeting logs and the the thread on devel for that discussion. Perhaps I'm misinterpreting your use of the word blocker. Regardless, it sounds like we are all in agreement. We are concluding that they won't be considered as blocker *bugs* (alpha or otherwise). Unless of course the absence, or presence, of the updated systemd script does somehow cause any of the Alpha criteria to fail. They won't be considered blocker bugs, but FESCO has the right to delay release of any milestone (alpha, beta or final) should they decide a late/inprogress feature is a must for a particular milestone. Once we are passed alpha I will do assessment on the conversion process and discuss with Fesco what ( if any ) next goal should be ( potential beta blockers ) . To make sure I'm understanding, do you mean the next goal would be to determine the status of the SysV-systemd feature and whether it will be on track for a Beta TC1 target? If it isn't ... FESCO must decide whether to hold the release, or drop the feature. Thanks, James signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] 2011-07-15 @ 17:00 UTC - F16 Alpha blocker bug review #1
On 07/14/2011 12:11 PM, James Laska wrote: To make sure I'm understanding, do you mean the next goal would be to determine the status of the SysV-systemd feature and whether it will be on track for a Beta TC1 target? If it isn't ... FESCO must decide whether to hold the release, or drop the feature. Think more of it in milestone such as number of @groups have not been completely converted and or all legacy sysv init script we ship on the DVD or the milestone of converting every sysv init scripts etc... and Fesco deciding if it will hold off the release or rather the beta release since no unit files will be introduced into the release after beta. This feature wont be dropped per say but rather moved into next release and the work continued from there converting what we did not manage to convert during this release cycle. This feature is of completely different nature and magnitude then introducing a new component into the release. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] 2011-07-15 @ 17:00 UTC - F16 Alpha blocker bug review #1
On 07/13/2011 07:17 PM, James Laska wrote: Your ideas are consistent with how we've handled this before, I don't think I could have articulated nearly as well though:) My understanding is that FESCO is the right place to discuss whether a feature should block a release or not. They already did and decided that what's on core + base + base-x would become alpha blockers which later got extended to included services we ship on the live cd. JBG -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] 2011-07-15 @ 17:00 UTC - F16 Alpha blocker bug review #1
On Wed, 2011-07-13 at 19:25 +, Jóhann B. Guðmundsson wrote: On 07/13/2011 07:17 PM, James Laska wrote: Your ideas are consistent with how we've handled this before, I don't think I could have articulated nearly as well though:) My understanding is that FESCO is the right place to discuss whether a feature should block a release or not. They already did and decided that what's on core + base + base-x would become alpha blockers which later got extended to included services we ship on the live cd. Quite a bit smaller than the 100+ bugs on the list. Was that decision from a recent FESCO meeting? /me pulling up old meeting minutes Thanks, James signature.asc Description: This is a digitally signed message part -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] 2011-07-15 @ 17:00 UTC - F16 Alpha blocker bug review #1
On 07/13/2011 08:11 PM, James Laska wrote: Quite a bit smaller than the 100+ bugs on the list. Was that decision from a recent FESCO meeting? It's the one held on 15 June. See this thread on -devel [1] also note that FESCO accepted the feature [2] on the bases that native systemd unit files will be accepted up to beta after that no more native systemd service files will be introduced in the release during it's lifetime. Developers will need to convert the old sysvinit init scripts to native systemd ones and/or review and use ones that have been provided to them and package them as per packaging guidelines which can be found here http://fedoraproject.org/wiki/Packaging:Guidelines:Systemd with sample scriptlet snippet which can be found here http://fedoraproject.org/wiki/Packaging:ScriptletSnippets#Systemd no later then beta for inclusions in the release. 1.http://lists.fedoraproject.org/pipermail/devel/2011-June/152780.html 2.http://fedoraproject.org/wiki/Features/SysVtoSystemd -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
Re: [Test-Announce] 2011-07-15 @ 17:00 UTC - F16 Alpha blocker bug review #1
On Wed, 2011-07-13 at 19:25 +, Jóhann B. Guðmundsson wrote: On 07/13/2011 07:17 PM, James Laska wrote: Your ideas are consistent with how we've handled this before, I don't think I could have articulated nearly as well though:) My understanding is that FESCO is the right place to discuss whether a feature should block a release or not. They already did and decided that what's on core + base + base-x would become alpha blockers which later got extended to included services we ship on the live cd. I think we could still talk to them about tweaking that process, though. I could easily be misinterpreted here, so I'll try to be precise... We've set up this whole blocker bug process that works quite smoothly to achieve what it sets out to achieve: validate the quality of the release. We have the release criteria and the blocker bug SOP and the system of bugs and meetings to carry it all out. That's great. Ultimately what the process achieves is QA's sign-off on the release: if there are no blocker bugs we say 'this release meets Fedora's quality standards'. Now, it should always be true that if there are any blocker bugs, the release cannot go out. *But*, crucially, the converse is not true: it is not inevitably be the case that if there are _no_ blocker bugs, the release _must_ go out. All it means is that we - the QA group - sign off on the release and say as far as we're concerned, it's okay to go out. QA isn't the *only* group that signs off on releases. FESCo does too. As I see it, it'd be perfectly fine for FESCo to say 'well, even though it meets all the quality standards, we do not want to sign off on this release until Feature X is done'. As I see it, that's a _separate_ process from the blocker bug / release validation process. FESCo does not need to use the blocker bug process to manage its decision to sign off on the release, and I think it would actually be better if they didn't. I'm dancing on pin heads here to some extent - the practical result is going to be the same whether we use the blocker process to manage FESCo's decisions on the feature process or whether we decide to come up with a different process for that - but I think it helps to have processes that are clearly and strictly defined: I think if we use blocker bugs to manage some specific aspect of the feature process, it dilutes both processes. I think it'd actually work out better if there were a separate mechanism by which FESCo managed its choice of whether or not to sign off on the release due to issues in the feature process. Thoughts? Should I talk to FESCo about this? -- Adam Williamson Fedora QA Community Monkey IRC: adamw http://www.happyassassin.net -- test mailing list test@lists.fedoraproject.org To unsubscribe: https://admin.fedoraproject.org/mailman/listinfo/test
