Greetings testers,
I've been playing with some ideas on how to allow secondary architectures to leverage the primary release criteria. I have some ideas/challenges that I'll send to the list for feedback later. However, in preparation for those ideas/concerns, I'd like to propose several changes to the release criteria.
The proposed changes are intended to make the existing criteria slightly more generic, without losing their meaning. Additionally, I've made a few other minor changes and added a few questions. Please take a few minutes to review the proposed changes (highlighted in red at the links below). If nothing alarming surfaces during review, I'll proceed with operation genericize [1] early next week.
https://fedoraproject.org/wiki/User:Jlaska/Draft_Alpha_criteria_revision https://fedoraproject.org/wiki/User:Jlaska/Draft_Beta_criteria_revision https://fedoraproject.org/wiki/User:Jlaska/Draft_Final_criteria_revision
Thanks, James
[1] Kudos to Adam for coining this gem!
On Thu, 2011-06-23 at 10:46 -0400, James Laska wrote:
Greetings testers,
I've been playing with some ideas on how to allow secondary architectures to leverage the primary release criteria. I have some ideas/challenges that I'll send to the list for feedback later. However, in preparation for those ideas/concerns, I'd like to propose several changes to the release criteria.
The proposed changes are intended to make the existing criteria slightly more generic, without losing their meaning. Additionally, I've made a few other minor changes and added a few questions. Please take a few minutes to review the proposed changes (highlighted in red at the links below). If nothing alarming surfaces during review, I'll proceed with operation genericize [1] early next week.
https://fedoraproject.org/wiki/User:Jlaska/Draft_Alpha_criteria_revision
I'm unclear on the addition of the word 'package' to 2: what does this clarify? What is the other type of install if not a 'package install'? Deleting CD, sure.
On the deletion of the 'primary architectures' mention from 4: we should probably replace this with something in the preamble, similar to what's there for 'release-blocking desktops'.
On 7: Not sure about this - I think booting from boot.iso and then using the DVD as a package source is explicitly supported, isn't it? Was this criterion meant to ensure that works?
10 seems to kind of fall between two stools, as it's still not very generic but now it looks a bit like we're supporting very obscure storage protocols on primary arches. I may be able to come up with something better here...how about:
"The installer must be able to complete an installation using any storage interface which is reasonably prevalent in general use" ? That was kind of the intention of the PATA, SATA, SCSI set for Intel.
https://fedoraproject.org/wiki/User:Jlaska/Draft_Beta_criteria_revision
Dropping 3: yup, it's not needed any more, good catch. Ditto 7.
https://fedoraproject.org/wiki/User:Jlaska/Draft_Final_criteria_revision
So for 4 we have the same problem as for Alpha, and it's a bit harder to re-write generically :/ So, we add iSCSI to the list for Intel, and zFCP (whatever that is) for another arch; is there anything in particular about these interfaces that we support? Is it just 'all interfaces for which anaconda actually has code' at this point?
15 and 17: not entirely sure what the question is here. The Alpha criterion specifically limits itself to the media, and the generic-* packages are not included on the media. It is acceptable for packages in the repository but not on the media to conflict.
Thanks for the feedback! Some follow-up below...
On Thu, 2011-06-23 at 09:12 -0700, Adam Williamson wrote:
On Thu, 2011-06-23 at 10:46 -0400, James Laska wrote:
Greetings testers,
I've been playing with some ideas on how to allow secondary architectures to leverage the primary release criteria. I have some ideas/challenges that I'll send to the list for feedback later. However, in preparation for those ideas/concerns, I'd like to propose several changes to the release criteria.
The proposed changes are intended to make the existing criteria slightly more generic, without losing their meaning. Additionally, I've made a few other minor changes and added a few questions. Please take a few minutes to review the proposed changes (highlighted in red at the links below). If nothing alarming surfaces during review, I'll proceed with operation genericize [1] early next week.
https://fedoraproject.org/wiki/User:Jlaska/Draft_Alpha_criteria_revision
I'm unclear on the addition of the word 'package' to 2: what does this clarify? What is the other type of install if not a 'package install'? Deleting CD, sure.
Yeah, deleting the CD's for one. It's technically not needed, but we have a lot of users that boot a DVD, and install from the online repositories. I was trying to articulate that this only applies to packages from the media. But perhaps that's redundant after saying "media-based install"?
On the deletion of the 'primary architectures' mention from 4: we should probably replace this with something in the preamble, similar to what's there for 'release-blocking desktops'.
I was hoping to avoid too much preamble, since for me, the eye really draws to the bullet list, and not the preamble. The deletion was going to be accompanied with my other ideas for secondary architecture handling. But I decided to break that up into two parts, so for now I'll back out that change.
Are we at the point where we need to create a section called 'Assumptions', which would include release-blocking desktops and primary architectures?
On 7: Not sure about this - I think booting from boot.iso and then using the DVD as a package source is explicitly supported, isn't it? Was this criterion meant to ensure that works?
Good discussion. I was trying to bring the criteria closer to what we actually test (fedora-qa) and maintain (anaconda-devel). Booting the boot.iso with askmethod, then installing from the DVD is a use case that we don't explicitly test and I wasn't intended with the original criteria, and we'd be hard-pressed to get fixes for.
I discussed this use case in #anaconda ... while we don't explicitly prevent a user from doing this, there is no logical use case to do this. They requested rephrasing the criteria to explicitly mention booting, and installing from, the DVD.
Per request, I'll hold off on filing a bug/patch to restrict CD/DVD askmethod install source selection until the UI redesign settles down.
10 seems to kind of fall between two stools, as it's still not very generic but now it looks a bit like we're supporting very obscure storage protocols on primary arches. I may be able to come up with something better here...how about:
"The installer must be able to complete an installation using any storage interface which is reasonably prevalent in general use" ? That was kind of the intention of the PATA, SATA, SCSI set for Intel.
I like that! Updated draft wiki, however refer to the Final criteria comments below.
https://fedoraproject.org/wiki/User:Jlaska/Draft_Beta_criteria_revision
Dropping 3: yup, it's not needed any more, good catch. Ditto 7.
https://fedoraproject.org/wiki/User:Jlaska/Draft_Final_criteria_revision
So for 4 we have the same problem as for Alpha, and it's a bit harder to re-write generically :/ So, we add iSCSI to the list for Intel, and zFCP (whatever that is) for another arch; is there anything in particular about these interfaces that we support? Is it just 'all interfaces for which anaconda actually has code' at this point?
Yeah, you nailed it. I was trying to make it generic, while still specific ... and failed. Without specific examples, I was having a hard time pinpointing the range of devices.
Originally we added this criteria to have a place to hang iSCSI support. I'd include zFCP (s390x fibre channel storage) in the same boat as iSCSI... important, but only critical for the final release.
What if we distinguish between the two Alpha and Final storage device criteria by differentiating between physically attached (Alpha), vs network (iSCSI) or SAN/fibre attached storage (zFCP/qLogic etc...)?
So alpha would be rewritten to cover (PATA, SATA, SCSI, eSATA) ... "The installer must be able to complete an installation using any locally connected storage interface (e.g. PATA, SATA, SCSI etc...)"
And final would add in the network component ... "The installer must be able to complete an installation using any networked storage devices (e.g. iSCSI, FCoE, Fibre Channel)"
How's that sound?
15 and 17: not entirely sure what the question is here. The Alpha criterion specifically limits itself to the media, and the generic-* packages are not included on the media. It is acceptable for packages in the repository but not on the media to conflict.
That's what I was hoping to get clarification on. Is it generally accepted that the phrasing "release repository" means the online +mirrored repos, not the media-based repos?
Thanks, James
On Thu, 2011-06-23 at 15:39 -0400, James Laska wrote:
On the deletion of the 'primary architectures' mention from 4: we should probably replace this with something in the preamble, similar to what's there for 'release-blocking desktops'.
I was hoping to avoid too much preamble, since for me, the eye really draws to the bullet list, and not the preamble. The deletion was going to be accompanied with my other ideas for secondary architecture handling. But I decided to break that up into two parts, so for now I'll back out that change.
Are we at the point where we need to create a section called 'Assumptions', which would include release-blocking desktops and primary architectures?
Basically, yes: the release criteria are explicitly intended to document the conditions which must be met *for Fedora to release*, and secondary architectures cannot block the release by definition. So we need to call this out *somewhere* on the page. Now you've brought it to the light, I think it actually makes more sense to do this in the preamble than just mentioning it in a couple of the criteria. But it does need to be explicitly mentioned. I think secondary arches can follow the non-blocking desktops model quite nicely, actually: call them out in the preamble and note that breakages of the criteria for secondary arches constitute NTH rather than blocker issues.
The preamble is getting a bit long, though, so we can probably reformat / reflow it a bit to look nicer and more readable.
On 7: Not sure about this - I think booting from boot.iso and then using the DVD as a package source is explicitly supported, isn't it? Was this criterion meant to ensure that works?
Good discussion. I was trying to bring the criteria closer to what we actually test (fedora-qa) and maintain (anaconda-devel). Booting the boot.iso with askmethod, then installing from the DVD is a use case that we don't explicitly test and I wasn't intended with the original criteria, and we'd be hard-pressed to get fixes for.
I discussed this use case in #anaconda ... while we don't explicitly prevent a user from doing this, there is no logical use case to do this. They requested rephrasing the criteria to explicitly mention booting, and installing from, the DVD.
Okay, then I agree with the change.
Per request, I'll hold off on filing a bug/patch to restrict CD/DVD askmethod install source selection until the UI redesign settles down.
10 seems to kind of fall between two stools, as it's still not very generic but now it looks a bit like we're supporting very obscure storage protocols on primary arches. I may be able to come up with something better here...how about:
"The installer must be able to complete an installation using any storage interface which is reasonably prevalent in general use" ? That was kind of the intention of the PATA, SATA, SCSI set for Intel.
I like that! Updated draft wiki, however refer to the Final criteria comments below.
https://fedoraproject.org/wiki/User:Jlaska/Draft_Beta_criteria_revision
Dropping 3: yup, it's not needed any more, good catch. Ditto 7.
https://fedoraproject.org/wiki/User:Jlaska/Draft_Final_criteria_revision
So for 4 we have the same problem as for Alpha, and it's a bit harder to re-write generically :/ So, we add iSCSI to the list for Intel, and zFCP (whatever that is) for another arch; is there anything in particular about these interfaces that we support? Is it just 'all interfaces for which anaconda actually has code' at this point?
Yeah, you nailed it. I was trying to make it generic, while still specific ... and failed. Without specific examples, I was having a hard time pinpointing the range of devices.
Originally we added this criteria to have a place to hang iSCSI support. I'd include zFCP (s390x fibre channel storage) in the same boat as iSCSI... important, but only critical for the final release.
What if we distinguish between the two Alpha and Final storage device criteria by differentiating between physically attached (Alpha), vs network (iSCSI) or SAN/fibre attached storage (zFCP/qLogic etc...)?
So alpha would be rewritten to cover (PATA, SATA, SCSI, eSATA) ... "The installer must be able to complete an installation using any locally connected storage interface (e.g. PATA, SATA, SCSI etc...)"
And final would add in the network component ... "The installer must be able to complete an installation using any networked storage devices (e.g. iSCSI, FCoE, Fibre Channel)"
How's that sound?
Sounds pretty good to me! Nice work.
15 and 17: not entirely sure what the question is here. The Alpha criterion specifically limits itself to the media, and the generic-* packages are not included on the media. It is acceptable for packages in the repository but not on the media to conflict.
That's what I was hoping to get clarification on. Is it generally accepted that the phrasing "release repository" means the online +mirrored repos, not the media-based repos?
I dunno, that was just the wording I came up with at the time, I think :) If we can clarify it, that's all to the good.
On Thu, 2011-06-23 at 13:00 -0700, Adam Williamson wrote:
On Thu, 2011-06-23 at 15:39 -0400, James Laska wrote:
On the deletion of the 'primary architectures' mention from 4: we should probably replace this with something in the preamble, similar to what's there for 'release-blocking desktops'.
I was hoping to avoid too much preamble, since for me, the eye really draws to the bullet list, and not the preamble. The deletion was going to be accompanied with my other ideas for secondary architecture handling. But I decided to break that up into two parts, so for now I'll back out that change.
Are we at the point where we need to create a section called 'Assumptions', which would include release-blocking desktops and primary architectures?
Basically, yes: the release criteria are explicitly intended to document the conditions which must be met *for Fedora to release*, and secondary architectures cannot block the release by definition. So we need to call this out *somewhere* on the page. Now you've brought it to the light, I think it actually makes more sense to do this in the preamble than just mentioning it in a couple of the criteria. But it does need to be explicitly mentioned. I think secondary arches can follow the non-blocking desktops model quite nicely, actually: call them out in the preamble and note that breakages of the criteria for secondary arches constitute NTH rather than blocker issues.
The preamble is getting a bit long, though, so we can probably reformat / reflow it a bit to look nicer and more readable.
Okay ... I'll ponder and propose if anything draft-worthy surfaces.
<snip>
10 seems to kind of fall between two stools, as it's still not very generic but now it looks a bit like we're supporting very obscure storage protocols on primary arches. I may be able to come up with something better here...how about:
"The installer must be able to complete an installation using any storage interface which is reasonably prevalent in general use" ? That was kind of the intention of the PATA, SATA, SCSI set for Intel.
I like that! Updated draft wiki, however refer to the Final criteria comments below.
https://fedoraproject.org/wiki/User:Jlaska/Draft_Beta_criteria_revision
Dropping 3: yup, it's not needed any more, good catch. Ditto 7.
https://fedoraproject.org/wiki/User:Jlaska/Draft_Final_criteria_revision
So for 4 we have the same problem as for Alpha, and it's a bit harder to re-write generically :/ So, we add iSCSI to the list for Intel, and zFCP (whatever that is) for another arch; is there anything in particular about these interfaces that we support? Is it just 'all interfaces for which anaconda actually has code' at this point?
Yeah, you nailed it. I was trying to make it generic, while still specific ... and failed. Without specific examples, I was having a hard time pinpointing the range of devices.
Originally we added this criteria to have a place to hang iSCSI support. I'd include zFCP (s390x fibre channel storage) in the same boat as iSCSI... important, but only critical for the final release.
What if we distinguish between the two Alpha and Final storage device criteria by differentiating between physically attached (Alpha), vs network (iSCSI) or SAN/fibre attached storage (zFCP/qLogic etc...)?
So alpha would be rewritten to cover (PATA, SATA, SCSI, eSATA) ... "The installer must be able to complete an installation using any locally connected storage interface (e.g. PATA, SATA, SCSI etc...)"
And final would add in the network component ... "The installer must be able to complete an installation using any networked storage devices (e.g. iSCSI, FCoE, Fibre Channel)"
How's that sound?
Sounds pretty good to me! Nice work.
Thanks, wiki drafts updated.
15 and 17: not entirely sure what the question is here. The Alpha criterion specifically limits itself to the media, and the generic-* packages are not included on the media. It is acceptable for packages in the repository but not on the media to conflict.
That's what I was hoping to get clarification on. Is it generally accepted that the phrasing "release repository" means the online +mirrored repos, not the media-based repos?
I dunno, that was just the wording I came up with at the time, I think :) If we can clarify it, that's all to the good.
Is it better/same/worse as follows ...
* The final branded release notes from the Documentation team must be present on ISO media and the appropriately versioned generic release notes must be available in the online release repository * A fedora-release package containing the correct names, information and repository configuration for a final Fedora release (as opposed to a pre-release) must be present on ISO media while the appropriately versioned generic-release package must be available in the online release repository </run-on>
Thanks, James
On Thu, 2011-06-23 at 16:52 -0400, James Laska wrote:
On Thu, 2011-06-23 at 13:00 -0700, Adam Williamson wrote:
On Thu, 2011-06-23 at 15:39 -0400, James Laska wrote:
There was one additional change made to the wiki that wasn't previously discussed. I removed the Beta criteria "The installer must be able to use the CD and DVD local package source options". Since we no longer provide CD images, and the DVD package repo is handled in the Alpha, this is no longer required.
I've migrated the changes into the Fedora 16 release criteria pages. Diffs linked below ...
* Alpha - https://fedoraproject.org/w/index.php?title=Fedora_16_Alpha_Release_Criteria... * Beta - https://fedoraproject.org/w/index.php?title=Fedora_16_Beta_Release_Criteria&... * Final - https://fedoraproject.org/w/index.php?title=Fedora_16_Final_Release_Criteria...
<snip>
15 and 17: not entirely sure what the question is here. The Alpha criterion specifically limits itself to the media, and the generic-* packages are not included on the media. It is acceptable for packages in the repository but not on the media to conflict.
That's what I was hoping to get clarification on. Is it generally accepted that the phrasing "release repository" means the online +mirrored repos, not the media-based repos?
I dunno, that was just the wording I came up with at the time, I think :) If we can clarify it, that's all to the good.
Is it better/same/worse as follows ...
* The final branded release notes from the Documentation team must be present on ISO media and the appropriately versioned generic release notes must be available in the online release repository * A fedora-release package containing the correct names, information and repository configuration for a final Fedora release (as opposed to a pre-release) must be present on ISO media while the appropriately versioned generic-release package must be available in the online release repository </run-on>
Any opinions on the above phrasing?
Thanks, James
On Wed, 2011-07-06 at 14:14 -0400, James Laska wrote:
I dunno, that was just the wording I came up with at the time, I think :) If we can clarify it, that's all to the good.
Is it better/same/worse as follows ...
* The final branded release notes from the Documentation team
must
be present on ISO media and the appropriately versioned
generic
release notes must be available in the online release
repository
* A fedora-release package containing the correct names, information and repository configuration for a final Fedora release (as opposed to a pre-release) must be present on ISO media while the appropriately versioned generic-release
package
must be available in the online release repository </run-on>
Any opinions on the above phrasing?
Discussed with Adam on #fedora-qa. I updated the wiki accordingly.
https://fedoraproject.org/w/index.php?title=Fedora_16_Final_Release_Criteria...
Thanks, James
On Thu, 2011-06-23 at 15:39 -0400, James Laska wrote:
Thanks for the feedback! Some follow-up below...
On Thu, 2011-06-23 at 09:12 -0700, Adam Williamson wrote:
On Thu, 2011-06-23 at 10:46 -0400, James Laska wrote:
Greetings testers,
I've been playing with some ideas on how to allow secondary architectures to leverage the primary release criteria. I have some ideas/challenges that I'll send to the list for feedback later. However, in preparation for those ideas/concerns, I'd like to propose several changes to the release criteria.
The proposed changes are intended to make the existing criteria slightly more generic, without losing their meaning. Additionally, I've made a few other minor changes and added a few questions. Please take a few minutes to review the proposed changes (highlighted in red at the links below). If nothing alarming surfaces during review, I'll proceed with operation genericize [1] early next week.
https://fedoraproject.org/wiki/User:Jlaska/Draft_Alpha_criteria_revision
I'm unclear on the addition of the word 'package' to 2: what does this clarify? What is the other type of install if not a 'package install'? Deleting CD, sure.
Yeah, deleting the CD's for one. It's technically not needed, but we have a lot of users that boot a DVD, and install from the online repositories. I was trying to articulate that this only applies to packages from the media. But perhaps that's redundant after saying "media-based install"?
On the deletion of the 'primary architectures' mention from 4: we should probably replace this with something in the preamble, similar to what's there for 'release-blocking desktops'.
I was hoping to avoid too much preamble, since for me, the eye really draws to the bullet list, and not the preamble. The deletion was going to be accompanied with my other ideas for secondary architecture handling. But I decided to break that up into two parts, so for now I'll back out that change.
Are we at the point where we need to create a section called 'Assumptions', which would include release-blocking desktops and primary architectures?
On 7: Not sure about this - I think booting from boot.iso and then using the DVD as a package source is explicitly supported, isn't it? Was this criterion meant to ensure that works?
Good discussion. I was trying to bring the criteria closer to what we actually test (fedora-qa) and maintain (anaconda-devel). Booting the boot.iso with askmethod, then installing from the DVD is a use case that we don't explicitly test and I wasn't intended with the original criteria, and we'd be hard-pressed to get fixes for.
I discussed this use case in #anaconda ... while we don't explicitly prevent a user from doing this, there is no logical use case to do this. They requested rephrasing the criteria to explicitly mention booting, and installing from, the DVD.
Then the default DVD install can cover this criteria or we need to add the askmethod, repo=[1] and graphically adding DVD repo[2] tests? I think it's very rare to use the latter options when already installing from DVD.
In addition, there's no criteria referring to 'preupgrade from order release test'[3] yet, should it be put into beta 11.[4] or the final criteria?
Thanks, Hurry
[1] https://fedoraproject.org/wiki/QA:Testcase_install_repository_DVD_variation
[2] https://fedoraproject.org/wiki/QA:Testcase_install_repository_DVD_graphical
[3] https://fedoraproject.org/wiki/QA:Testcase_Preupgrade_from_older_release
[4] https://fedoraproject.org/wiki/User:Jlaska/Draft_Beta_criteria_revision
On Fri, 2011-06-24 at 16:17 +0800, He Rui wrote:
In addition, there's no criteria referring to 'preupgrade from order release test'[3] yet, should it be put into beta 11.[4] or the final criteria?
I don't think so; so far we've considered this intentional, the test is purely informational: we want to know if upgrading from two releases ago works, and document any problems with it, but we won't hold the release if it's broken.
On 06/23/2011 10:46 AM, James Laska wrote:
Greetings testers,
I've been playing with some ideas on how to allow secondary architectures to leverage the primary release criteria. I have some ideas/challenges that I'll send to the list for feedback later. However, in preparation for those ideas/concerns, I'd like to propose several changes to the release criteria.
The proposed changes are intended to make the existing criteria slightly more generic, without losing their meaning. Additionally, I've made a few other minor changes and added a few questions. Please take a few minutes to review the proposed changes (highlighted in red at the links below). If nothing alarming surfaces during review, I'll proceed with operation genericize [1] early next week.
https://fedoraproject.org/wiki/User:Jlaska/Draft_Alpha_criteria_revision https://fedoraproject.org/wiki/User:Jlaska/Draft_Beta_criteria_revision https://fedoraproject.org/wiki/User:Jlaska/Draft_Final_criteria_revision
Thanks, James
[1] Kudos to Adam for coining this gem!
What should be done with nth bzs that were not resolved before 15 went to press and have not been resolved with an update and are now present in rawhide? Should they be moved up in priority and/or automatically added to the 16 blocker bz?
An example: https://bugzilla.redhat.com/show_bug.cgi?id=681582
(BTW: 681582 probably should have been in the 15 release notes.)
On Thu, 2011-06-23 at 13:07 -0400, Clyde E. Kunkel wrote:
On 06/23/2011 10:46 AM, James Laska wrote:
Greetings testers,
I've been playing with some ideas on how to allow secondary architectures to leverage the primary release criteria. I have some ideas/challenges that I'll send to the list for feedback later. However, in preparation for those ideas/concerns, I'd like to propose several changes to the release criteria.
The proposed changes are intended to make the existing criteria slightly more generic, without losing their meaning. Additionally, I've made a few other minor changes and added a few questions. Please take a few minutes to review the proposed changes (highlighted in red at the links below). If nothing alarming surfaces during review, I'll proceed with operation genericize [1] early next week.
https://fedoraproject.org/wiki/User:Jlaska/Draft_Alpha_criteria_revision https://fedoraproject.org/wiki/User:Jlaska/Draft_Beta_criteria_revision https://fedoraproject.org/wiki/User:Jlaska/Draft_Final_criteria_revision
Thanks, James
[1] Kudos to Adam for coining this gem!
What should be done with nth bzs that were not resolved before 15 went to press and have not been resolved with an update and are now present in rawhide? Should they be moved up in priority and/or automatically added to the 16 blocker bz?
I hesitate to bulk add any unresolved NTH from a previous release. Mainly because it feels a bit like moving around deck chairs. Unless conditions/criteria/understand changed enough to warrant a second look at a bug, I'm fine with leaving them where they are.
For your bug specifically, it sounds like there may still be interest in pursuing this. You can certainly add that to the appropriate F16 list, and also try to get this on the maintainer/upstream radar.
An example: https://bugzilla.redhat.com/show_bug.cgi?id=681582
(BTW: 681582 probably should have been in the 15 release notes.)
We can add that to Common_F15_Bugs if you like ... that's probably not a bad resolution for things folks feel will be "common" and remain unresolved.
Thanks, James
On Thu, 2011-06-23 at 13:07 -0400, Clyde E. Kunkel wrote:
What should be done with nth bzs that were not resolved before 15 went to press and have not been resolved with an update and are now present in rawhide? Should they be moved up in priority and/or automatically added to the 16 blocker bz?
An example: https://bugzilla.redhat.com/show_bug.cgi?id=681582
(BTW: 681582 probably should have been in the 15 release notes.)
At present we intentionally don't do anything automatic with them: I don't think this is noted in the SOP (bad Adam!) but we discussed it before and came to the conclusion it was best to leave them alone and let interested parties update them manually. The idea is that if you're still concerned about such a bug, and know it's still valid in Rawhide, for you to re-propose it as NTH or Blocker for the next release. So, go ahead and do that for the bug in question :)
On 06/23/2011 12:14 PM, Adam Williamson wrote:
On Thu, 2011-06-23 at 13:07 -0400, Clyde E. Kunkel wrote:
What should be done with nth bzs that were not resolved before 15 went to press and have not been resolved with an update and are now present in rawhide? Should they be moved up in priority and/or automatically added to the 16 blocker bz?
An example: https://bugzilla.redhat.com/show_bug.cgi?id=681582
(BTW: 681582 probably should have been in the 15 release notes.)
At present we intentionally don't do anything automatic with them: I don't think this is noted in the SOP (bad Adam!) but we discussed it before and came to the conclusion it was best to leave them alone and let interested parties update them manually. The idea is that if you're still concerned about such a bug, and know it's still valid in Rawhide, for you to re-propose it as NTH or Blocker for the next release. So, go ahead and do that for the bug in question :)
Ok, tho I wasn't really lobbying for my bug, but, rather, the concept in general. It just seems to me that any bugs deemed nth but not fixed in time for release and aren't fixed in updates or rawhide by branching should at least be starting points for the next release. I.e., the next release is better than the last, more reliable, more bug free, yada yada yada. Sure there would be some subjectivity, but that is why we get the big bucks or spend spend the time. :-)