6:58 a.m.
Hi, everyone. So we partly used the proposed new nice-to-have bug
tracking system during the F14 Beta process, and it seemed to go well.
In a quick burst of airport productivity, I've quickly written up a
bunch of proposed new wiki pages and modifications to existing ones to
document the nice-to-have process (and, incidentally, extend
documentation of the blocker process, since we don't seem to have much
of it beyond the blocker meeting SOP right now). All the pages can be
found here:
https://fedoraproject.org/wiki/Category:NTH_adjustment_drafts
it should be pretty obvious which are new and which are modifications of
existing pages. I hope this is mostly straightforward and
non-controversial.
A quick five-minute summary is that we will now have (in fact, we
already do) trackers for nice-to-have bugs for Alpha, Beta and Final
releases as well as trackers for blocker bugs. Bugs on these NTH lists
will be given priority after blocker bugs for QA, devel and releng work
for releases. Fixes for these bugs - and *only* these bugs, if a fix is
to be taken through a freeze, there must be a matching accepted NTH bug
- will be taken through release freezes. Proposing, reviewing and
monitoring NTH bugs will work exactly as it does for blocker bugs, and
mostly happen in the blocker meetings, but of course after consideration
of the blocker lists.
In practice this is a formalization of existing procedure - until F14
Beta, QA and releng did much the same process but entirely informally,
we just kept lists of bugs we'd take fixes for either in our heads or in
the RC creation trac tickets. This process is meant to be more robust,
documented and discoverable.
Some releng SOP pages may require minor updates, I figured I'd leave
that to releng. The process for creating blocker trackers should also be
updated to cover creating NTH trackers (I couldn't find that; poelcat,
where is it?)
Comments, questions, suggestions welcome!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
3:22 p.m.
On Thu, 2010-09-23 at 12:58 +0100, Adam Williamson wrote:
Hi, everyone. So we partly used the proposed new nice-to-have bug
tracking system during the F14 Beta process, and it seemed to go well.
In a quick burst of airport productivity, I've quickly written up a
bunch of proposed new wiki pages and modifications to existing ones to
document the nice-to-have process (and, incidentally, extend
documentation of the blocker process, since we don't seem to have much
of it beyond the blocker meeting SOP right now). All the pages can be
found here:
https://fedoraproject.org/wiki/Category:NTH_adjustment_drafts
Thanks for providing draft wiki edits with the proposal. I've made a
few _minor_ tweaks to the wiki pages.
it should be pretty obvious which are new and which are modifications
of
existing pages. I hope this is mostly straightforward and
non-controversial.
A quick five-minute summary is that we will now have (in fact, we
already do) trackers for nice-to-have bugs for Alpha, Beta and Final
releases as well as trackers for blocker bugs. Bugs on these NTH lists
will be given priority after blocker bugs for QA, devel and releng work
for releases. Fixes for these bugs - and *only* these bugs, if a fix is
to be taken through a freeze, there must be a matching accepted NTH bug
- will be taken through release freezes. Proposing, reviewing and
monitoring NTH bugs will work exactly as it does for blocker bugs, and
mostly happen in the blocker meetings, but of course after consideration
of the blocker lists.
I like the idea of formalizing the 'nice-to-have' process. I recall
tension during the F-13-RC phase regarding the decision making process
that allowed a selection of non-Blocker fixes into the release. I hope
that this process helps clarify the acceptable exceptions to the blocker
process.
In practice this is a formalization of existing procedure - until
F14
Beta, QA and releng did much the same process but entirely informally,
we just kept lists of bugs we'd take fixes for either in our heads or in
the RC creation trac tickets. This process is meant to be more robust,
documented and discoverable.
Perhaps the pending rel-eng SOP documents would cover this, but I'm
unclear how FXX-accepted bugs are treated during at compose time. For
our current Blocker bug process, it's established that if the
appropriate blocker bug list is not empty, we can't compose. With
non-blocker nice-to-have (NTH) bugs, how would that fix get into a
compose?
Guessing ...
* The fix would have to be packaged and available in bodhi
updates-testing
* The bodhi update has received the required karma
* The accepted bug is in VERIFIED state?
To summarize, what instructions can we provide maintainers with so they
can be confident an tested, packaged and approved nice-to-have fix will
be pulled into any (re)compose? Perhaps, more of a question for the
release-engineering team.
Different topic ...
In the days of using *only* Blocker bugs, it's now somewhat confusing to
look at the F14Beta-accepted tracker, after we started mirroring
F14Beta, and see 12 open bugs (some trackers) [1]. I don't think this
is a bad thing, but perhaps another item to manage based on the result
of the go/no-go meeting ... move any pending FXX-accepted bugs into the
next milestone (so open FXXBeta-accepted bugs would move to
FXX-accepted)?
[1]
https://bugzilla.redhat.com/showdependencytree.cgi?id=F14Beta-accepted&am...
Some releng SOP pages may require minor updates, I figured I'd
leave
that to releng. The process for creating blocker trackers should also be
updated to cover creating NTH trackers (I couldn't find that; poelcat,
where is it?)
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers
I assume "User:Adamwill/QA:SOP_blocker_bug_meeting_nth_draft" is
intended to replace "QA:SOP_Blocker_Bug_Meeting", and not define an
additional blocker review meeting?
I've queued
https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_nth_process_nth_draft up for some
additional reading, I'll reply later with any additional comments.
Thanks,
James
5:44 p.m.
On Fri, 2010-09-24 at 16:22 -0400, James Laska wrote:
> In practice this is a formalization of existing procedure -
until F14
> Beta, QA and releng did much the same process but entirely informally,
> we just kept lists of bugs we'd take fixes for either in our heads or in
> the RC creation trac tickets. This process is meant to be more robust,
> documented and discoverable.
Perhaps the pending rel-eng SOP documents would cover this, but I'm
unclear how FXX-accepted bugs are treated during at compose time. For
our current Blocker bug process, it's established that if the
appropriate blocker bug list is not empty, we can't compose. With
non-blocker nice-to-have (NTH) bugs, how would that fix get into a
compose?
Guessing ...
* The fix would have to be packaged and available in bodhi
updates-testing
* The bodhi update has received the required karma
* The accepted bug is in VERIFIED state?
To summarize, what instructions can we provide maintainers with so they
can be confident an tested, packaged and approved nice-to-have fix will
be pulled into any (re)compose? Perhaps, more of a question for the
release-engineering team.
So far, we haven't been that strict; the process has been that I've
listed any builds currently available in Koji which address nth issues
in the RC compose request ticket, and then it's been up to rel-eng to
take them or not. I agree we should nail this down a little better, and
your list seems reasonable (though I'd probably say it's not necessary
that the build be *available* in updates-testing, just that it have been
*submitted* there; waiting for an updates-testing compose is an
arbitrary limitation). Indeed this is probably something to co-ordinate
with releng's SOPs on.
Different topic ...
In the days of using *only* Blocker bugs, it's now somewhat confusing to
look at the F14Beta-accepted tracker, after we started mirroring
F14Beta, and see 12 open bugs (some trackers) [1]. I don't think this
is a bad thing, but perhaps another item to manage based on the result
of the go/no-go meeting ... move any pending FXX-accepted bugs into the
next milestone (so open FXXBeta-accepted bugs would move to
FXX-accepted)?
Yes, I meant to include that and forgot about it. Indeed this should be
the process.
[1]
https://bugzilla.redhat.com/showdependencytree.cgi?id=F14Beta-accepted&am...
> Some releng SOP pages may require minor updates, I figured I'd leave
> that to releng. The process for creating blocker trackers should also be
> updated to cover creating NTH trackers (I couldn't find that; poelcat,
> where is it?)
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Trackers
I assume "User:Adamwill/QA:SOP_blocker_bug_meeting_nth_draft" is
intended to replace "QA:SOP_Blocker_Bug_Meeting", and not define an
additional blocker review meeting?
Yes. I considered creating a separate page detailing a 'nice-to-have
review meeting' and noting that in practice it could be combined with
the blocker meeting, but that just felt like over-engineering.
I've queued
https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_nth_process_nth_draft up for some
additional reading, I'll reply later with any additional comments.
Thanks!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
12:32 p.m.
On Thu, 2010-09-23 at 12:58 +0100, Adam Williamson wrote:
Hi, everyone. So we partly used the proposed new nice-to-have bug
tracking system during the F14 Beta process, and it seemed to go well.
In a quick burst of airport productivity, I've quickly written up a
bunch of proposed new wiki pages and modifications to existing ones to
document the nice-to-have process (and, incidentally, extend
documentation of the blocker process, since we don't seem to have much
of it beyond the blocker meeting SOP right now). All the pages can be
found here:
https://fedoraproject.org/wiki/Category:NTH_adjustment_drafts
Thanks to James for his feedback on this. I haven't had much feedback
from anyone else. However, given that in practice everyone involved in
the release review process has been happy using the NTH system drafted
here so far, I intend to make the draft changes final (with
modifications to reflect James' feedback) by the end of the week, so if
you have any feedback you've been sitting on, now would be the perfect
time to send it :) Thanks everyone!
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
1:58 p.m.
Adam Williamson said the following on 10/06/2010 01:32 PM Pacific Time:
On Thu, 2010-09-23 at 12:58 +0100, Adam Williamson wrote:
> Hi, everyone. So we partly used the proposed new nice-to-have bug
> tracking system during the F14 Beta process, and it seemed to go well.
> In a quick burst of airport productivity, I've quickly written up a
> bunch of proposed new wiki pages and modifications to existing ones to
> document the nice-to-have process (and, incidentally, extend
> documentation of the blocker process, since we don't seem to have much
> of it beyond the blocker meeting SOP right now). All the pages can be
> found here:
>
> https://fedoraproject.org/wiki/Category:NTH_adjustment_drafts
Thanks to James for his feedback on this. I haven't had much feedback
from anyone else. However, given that in practice everyone involved in
the release review process has been happy using the NTH system drafted
here so far, I intend to make the draft changes final (with
modifications to reflect James' feedback) by the end of the week, so if
you have any feedback you've been sitting on, now would be the perfect
time to send it :) Thanks everyone!
Can you be more specific as to which page we are actually giving
feedback on? There are five of them there and they almost all look the
same.
John
2:32 p.m.
On Wed, 2010-10-06 at 14:58 -0400, John Poelstra wrote:
Adam Williamson said the following on 10/06/2010 01:32 PM Pacific
Time:
> On Thu, 2010-09-23 at 12:58 +0100, Adam Williamson wrote:
>> Hi, everyone. So we partly used the proposed new nice-to-have bug
>> tracking system during the F14 Beta process, and it seemed to go well.
>> In a quick burst of airport productivity, I've quickly written up a
>> bunch of proposed new wiki pages and modifications to existing ones to
>> document the nice-to-have process (and, incidentally, extend
>> documentation of the blocker process, since we don't seem to have much
>> of it beyond the blocker meeting SOP right now). All the pages can be
>> found here:
>>
>> https://fedoraproject.org/wiki/Category:NTH_adjustment_drafts
>
> Thanks to James for his feedback on this. I haven't had much feedback
> from anyone else. However, given that in practice everyone involved in
> the release review process has been happy using the NTH system drafted
> here so far, I intend to make the draft changes final (with
> modifications to reflect James' feedback) by the end of the week, so if
> you have any feedback you've been sitting on, now would be the perfect
> time to send it :) Thanks everyone!
Can you be more specific as to which page we are actually giving
feedback on? There are five of them there and they almost all look the
same.
All of them. They're mostly modifications of existing pages. I'm not
quite sure how you get that they look the same, they're very different.
https://fedoraproject.org/wiki/User:Adamwill/Draft_desktop_results_nth_ad... is a
proposed change to https://fedoraproject.org/wiki/QA:Desktop_validation_results_template
.
https://fedoraproject.org/wiki/User:Adamwill/Draft_desktop_validation_nth... is a
proposed change to https://fedoraproject.org/wiki/QA:Desktop_validation_testing .
https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_blocker_bug_meeting_n... is a
proposed change to https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting .
https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_blocker_bug_process_n... is a
proposed new page; it's not particularly specific to the nice-to-have proposal,
actually, it just became apparent while I was doing this that we have no page which
explains the entire blocker bug review process, and we should have one. This is it.
https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_nth_process_nth_draft is a proposed
new page which covers the whole nice-to-have review process much as the above proposed
page covers the blocker review process.
I included a summary of the whole proposed NTH process in my initial
review request mail. These are the wiki changes necessary to document
that process.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
10:07 a.m.
On Wed, 2010-10-06 at 12:32 -0700, Adam Williamson wrote:
On Wed, 2010-10-06 at 14:58 -0400, John Poelstra wrote:
> Adam Williamson said the following on 10/06/2010 01:32 PM Pacific Time:
> > On Thu, 2010-09-23 at 12:58 +0100, Adam Williamson wrote:
> >> Hi, everyone. So we partly used the proposed new nice-to-have bug
> >> tracking system during the F14 Beta process, and it seemed to go well.
> >> In a quick burst of airport productivity, I've quickly written up a
> >> bunch of proposed new wiki pages and modifications to existing ones to
> >> document the nice-to-have process (and, incidentally, extend
> >> documentation of the blocker process, since we don't seem to have much
> >> of it beyond the blocker meeting SOP right now). All the pages can be
> >> found here:
> >>
> >> https://fedoraproject.org/wiki/Category:NTH_adjustment_drafts
> >
> > Thanks to James for his feedback on this. I haven't had much feedback
> > from anyone else. However, given that in practice everyone involved in
> > the release review process has been happy using the NTH system drafted
> > here so far, I intend to make the draft changes final (with
> > modifications to reflect James' feedback) by the end of the week, so if
> > you have any feedback you've been sitting on, now would be the perfect
> > time to send it :) Thanks everyone!
>
> Can you be more specific as to which page we are actually giving
> feedback on? There are five of them there and they almost all look the
> same.
All of them. They're mostly modifications of existing pages. I'm not
quite sure how you get that they look the same, they're very different.
General note ... There are a few broken links on this page. I didn't
inspect *all* of them, but it looks like they will resolve once you've
moved the documents into their proposed locations. So probably not a
big deal, I can understand the desire to not change the links before and
after moving the pages into their final location.
https://fedoraproject.org/wiki/User:Adamwill/Draft_desktop_results_nth_ad... is a
proposed change to https://fedoraproject.org/wiki/QA:Desktop_validation_results_template .
Good stuff.
https://fedoraproject.org/wiki/User:Adamwill/Draft_desktop_validation_nth... is a
proposed change to https://fedoraproject.org/wiki/QA:Desktop_validation_testing .
Same as above, equally as wholesome :)
https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_blocker_bug_meeting_n... is a
proposed change to https://fedoraproject.org/wiki/QA:SOP_Blocker_Bug_Meeting .
https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_blocker_bug_process_n... is a
proposed new page; it's not particularly specific to the nice-to-have proposal,
actually, it just became apparent while I was doing this that we have no page which
explains the entire blocker bug review process, and we should have one. This is it.
Funny how when you've been involved in a process for a while, you forget
which parts aren't clearly documented/described for others to engage.
Nice addition.
https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_nth_process_nth_draft is a proposed
new page which covers the whole nice-to-have review process much as the above proposed
page covers the blocker review process.
My first reaction looking at the proposed blocker and nth process SOP
pages was that they should be combined into a single page, since there
is a lot of duplicate document structure/format. But I can't think of
any good proposals to offer at the moment that make it better (not
worse). It seems you've already been down this route too.
Perhaps a reflection on my visual learning habit, I've been playing
around with some minor edits of the 2 previous wiki pages that make it a
bit easier for me to rapidly locate/grok information without too much
reading. Of course, let me know if the edits are too invasive or
detract from your intended message.
I included a summary of the whole proposed NTH process in my initial
review request mail. These are the wiki changes necessary to document
that process.
Thanks,
James
12:24 p.m.
On Thu, 2010-10-07 at 11:07 -0400, James Laska wrote:
> All of them. They're mostly modifications of existing pages.
I'm not
> quite sure how you get that they look the same, they're very different.
General note ... There are a few broken links on this page. I didn't
inspect *all* of them, but it looks like they will resolve once you've
moved the documents into their proposed locations. So probably not a
big deal, I can understand the desire to not change the links before and
after moving the pages into their final location.
Yeah, they'll work after the pages are all put live.
>
https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_nth_process_nth_draft is a proposed
new page which covers the whole nice-to-have review process much as the above proposed
page covers the blocker review process.
My first reaction looking at the proposed blocker and nth process SOP
pages was that they should be combined into a single page, since there
is a lot of duplicate document structure/format. But I can't think of
any good proposals to offer at the moment that make it better (not
worse). It seems you've already been down this route too.
Yeah, I went back and forth. If you make them one page some of the
phrasing gets very long and clunky and possibly hard to parse, I was
happier with it as two pages.
Perhaps a reflection on my visual learning habit, I've been
playing
around with some minor edits of the 2 previous wiki pages that make it a
bit easier for me to rapidly locate/grok information without too much
reading. Of course, let me know if the edits are too invasive or
detract from your intended message.
Thanks, I'll revert them all later ;)
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
6:12 a.m.
Adam Williamson said the following on 10/07/2010 01:24 PM Pacific Time:
>>
https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_nth_process_nth_draft is a proposed
new page which covers the whole nice-to-have review process much as the above proposed
page covers the blocker review process.
Thanks for doing all this Adam.
The "Nice-to-have bug principles" guidelines feels a little mushy and
subjective to me, though after thinking about it for a while I can't
propose anything better--you've done a good job putting some structure
around what they might be.
And since they can't block the release they won't be able to cause that
many problems. I suppose if NTH bugs were to ever become a big
distraction from addressing blocker bugs we could re-evaluate.
On the other hand it has taken us a *long* time to get to the place
where we are today where churn in RC has been reduced to a bare minimum.
I still subscribe to the theory (realizing some in Fedora don't) that
every additional change adds a level of risk of delaying the release.
So my hope is that by formalizing the NTH we aren't encouraging an
increased amount of churn.
I DO think this is an important section in the guidelines that will help
cover this concern:
"In general, nice-to-have bugs are usually bugs for which an update is
not an optimal solution, and for which the fix is reasonably small and
testable (this consideration becomes progressively more important as a
release nears, so bugs may be downgraded from nice-to-have status late
in the release process if it transpires that the fix is complex and hard
to test)."
Would it be overkill to put more explicit testing sign-off around NTH bugs?
John
10:23 a.m.
On Fri, 2010-10-08 at 07:12 -0400, John Poelstra wrote:
Adam Williamson said the following on 10/07/2010 01:24 PM Pacific
Time:
>>> https://fedoraproject.org/wiki/User:Adamwill/QA:SOP_nth_process_nth_draft is
a proposed new page which covers the whole nice-to-have review process much as the above
proposed page covers the blocker review process.
Thanks for doing all this Adam.
The "Nice-to-have bug principles" guidelines feels a little mushy and
subjective to me, though after thinking about it for a while I can't
propose anything better--you've done a good job putting some structure
around what they might be.
And since they can't block the release they won't be able to cause that
many problems. I suppose if NTH bugs were to ever become a big
distraction from addressing blocker bugs we could re-evaluate.
On the other hand it has taken us a *long* time to get to the place
where we are today where churn in RC has been reduced to a bare minimum.
I still subscribe to the theory (realizing some in Fedora don't) that
every additional change adds a level of risk of delaying the release.
So my hope is that by formalizing the NTH we aren't encouraging an
increased amount of churn.
I DO think this is an important section in the guidelines that will help
cover this concern:
"In general, nice-to-have bugs are usually bugs for which an update is
not an optimal solution, and for which the fix is reasonably small and
testable (this consideration becomes progressively more important as a
release nears, so bugs may be downgraded from nice-to-have status late
in the release process if it transpires that the fix is complex and hard
to test)."
Would it be overkill to put more explicit testing sign-off around NTH bugs?
I don't see why not. I think this topic came up in a previous mail.
I'd propose that NTH bugs must be tested and have appropriate bodhi
karma for them to be included. But as noted in a previous mail, I
*think* this might be something that release engineering will need to
specify on their documentation regarding how to compose release
candidates (jkeating or dgilmore can correct me here). Is there an SOP
for that process now?
Another distinction to consider
1. Using the language you noted earlier that "[NTH] bugs are
usually bugs for which an update is not an optimal solution".
To me this implicitly states that NTH packages must be on the
media. If it's not on the media, it's not eligible.
2. Extending the above ... I wonder if it's reasonable that NTH
cannot be accepted for critical path components. For critical
path, it's a blocker or not, let's not fiddle with critpath if a
respin is needed to address blocker issues.
Thanks,
James
10:27 a.m.
On Fri, 2010-10-08 at 07:12 -0400, John Poelstra wrote:
On the other hand it has taken us a *long* time to get to the place
where we are today where churn in RC has been reduced to a bare minimum.
I still subscribe to the theory (realizing some in Fedora don't) that
every additional change adds a level of risk of delaying the release.
So my hope is that by formalizing the NTH we aren't encouraging an
increased amount of churn.
I hope so too, that's not the aim of the proposal, just to formalize
what we're doing already.
I DO think this is an important section in the guidelines that will
help
cover this concern:
"In general, nice-to-have bugs are usually bugs for which an update is
not an optimal solution, and for which the fix is reasonably small and
testable (this consideration becomes progressively more important as a
release nears, so bugs may be downgraded from nice-to-have status late
in the release process if it transpires that the fix is complex and hard
to test)."
Would it be overkill to put more explicit testing sign-off around NTH bugs?
Hard to be sure. On the one hand, they have more attention from more
people than most bugs. On the other hand, the whole point is the
compressed timescale involved. So it's kinda 50/50.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
2:42 p.m.
On Fri, 2010-10-08 at 11:23 -0400, James Laska wrote:
> Would it be overkill to put more explicit testing sign-off
around NTH bugs?
I don't see why not. I think this topic came up in a previous mail.
I'd propose that NTH bugs must be tested and have appropriate bodhi
karma for them to be included. But as noted in a previous mail, I
*think* this might be something that release engineering will need to
specify on their documentation regarding how to compose release
candidates (jkeating or dgilmore can correct me here). Is there an SOP
for that process now?
As noted in the meeting, for final release, all fixes (blocker and NTH)
have to go through testing and be pushed to stable, we do not use a side
repo for the final composes. This is necessary to ensure that final
images match the final published repos.
Another distinction to consider
1. Using the language you noted earlier that "[NTH] bugs are
usually bugs for which an update is not an optimal solution".
To me this implicitly states that NTH packages must be on the
media. If it's not on the media, it's not eligible.
That's probably true.
2. Extending the above ... I wonder if it's reasonable that
NTH
cannot be accepted for critical path components. For critical
path, it's a blocker or not, let's not fiddle with critpath if a
respin is needed to address blocker issues.
I disagree with this. It just doesn't match practice. Both before
implementing the formal NTH process this release and after, many - in
fact, I think most - NTH bugs have been in critpath components.
Especially given that many of them will be anaconda or X driver or
kernel issues, I don't think this would make any sense.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
4:05 p.m.
On Fri, 2010-10-08 at 12:42 -0700, Adam Williamson wrote:
On Fri, 2010-10-08 at 11:23 -0400, James Laska wrote:
> > Would it be overkill to put more explicit testing sign-off around NTH bugs?
>
> I don't see why not. I think this topic came up in a previous mail.
> I'd propose that NTH bugs must be tested and have appropriate bodhi
> karma for them to be included. But as noted in a previous mail, I
> *think* this might be something that release engineering will need to
> specify on their documentation regarding how to compose release
> candidates (jkeating or dgilmore can correct me here). Is there an SOP
> for that process now?
As noted in the meeting, for final release, all fixes (blocker and NTH)
have to go through testing and be pushed to stable, we do not use a side
repo for the final composes. This is necessary to ensure that final
images match the final published repos.
> Another distinction to consider
> 1. Using the language you noted earlier that "[NTH] bugs are
> usually bugs for which an update is not an optimal solution".
> To me this implicitly states that NTH packages must be on the
> media. If it's not on the media, it's not eligible.
That's probably true.
> 2. Extending the above ... I wonder if it's reasonable that NTH
> cannot be accepted for critical path components. For critical
> path, it's a blocker or not, let's not fiddle with critpath if a
> respin is needed to address blocker issues.
I disagree with this. It just doesn't match practice. Both before
implementing the formal NTH process this release and after, many - in
fact, I think most - NTH bugs have been in critpath components.
Especially given that many of them will be anaconda or X driver or
kernel issues, I don't think this would make any sense.
Oh your right. Lemme rethink if there is a better way to articulate my
thoughts. I was searching for a generic way to say, potentially
disruptive changes to core packages aren't a good fit for NTH. The NTH
xorg bug#596557 discussed during the blocker meeting [1] being a good
example.
I'll see if there's a way to rephrase my proposal to be more accurate.
Thanks,
James
[1]
http://meetbot.fedoraproject.org/fedora-bugzappers/2010-10-08/fedora-bugz...
5:20 p.m.
On Fri, 2010-10-08 at 17:05 -0400, James Laska wrote:
Oh your right. Lemme rethink if there is a better way to articulate
my
thoughts. I was searching for a generic way to say, potentially
disruptive changes to core packages aren't a good fit for NTH. The NTH
xorg bug#596557 discussed during the blocker meeting [1] being a good
example.
I'll see if there's a way to rephrase my proposal to be more accurate.
The principles already mention this:
"and for which the fix is reasonably small and testable (this
consideration becomes progressively more important as a release nears,
so bugs may be downgraded from nice-to-have status late in the release
process if it transpires that the fix is complex and hard to test)"
it's always been a trade-off between how much benefit we get from taking
the fix and how complex and potentially dangerous the fix is; I tried to
encapsulate that in the principles.
--
Adam Williamson
Fedora QA Community Monkey
IRC: adamw | Fedora Talk: adamwill AT fedoraproject DOT org
http://www.happyassassin.net
4942
days inactive
4957
days old
13 comments
3 participants
participants (3)
-
Adam Williamson -
James Laska -
John Poelstra