Hey, folks. Some release criteria stuff!
I've created the F16 criteria pages, copied across from F15. I added some criteria we agreed on back in October 2010 to the Final page; somehow we managed not to add these onto the F15 page, but they're in there now. Those are:
* The final release notes (in both branded and generic form) from the Documentation team must be present in the release repository in packaged form * A spin-kickstarts package which contains the exact kickstart files used to build the release must be present in the release repository. The included kickstarts must define the correct set of release repositories * A fedora-release package and a generic-release package appropriately versioned and containing the correct names, information and repository configuration for a final Fedora release (as opposed to a pre-release) must be present in the release repository
I also added the recently-agreed logger criterion to the Alpha page:
* A system logging infrastructure must be available and enabled by default. It must provide at least basic local file-based logging of kernel messages, and allow other components to write log messages. This must be done in accordance with relevant standards accepted by the Project
Finally, I have a new proposal for the issue of 'supported' desktops, which is blocking another planned criterion that we've been meaning to add for a while. I'm now proposing the term 'release-blocking desktops': it's simple, it does what it says on the tin, and it doesn't imply any value judgments about the desktops in question. How does that sound?
So all current reference to 'desktop' or 'the desktop' would be replaced by 'release-blocking desktops', and the proposed image size criterion would read:
* The network installation image, DVD image, and live images for release-blocking desktops must meet current size requirements
Feedback please! :) For reference, the new F16 pages are:
https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria https://fedoraproject.org/wiki/Fedora_16_Beta_Release_Criteria https://fedoraproject.org/wiki/Fedora_16_Final_Release_Criteria
On 05/17/2011 10:40 PM, Adam Williamson wrote:
Finally, I have a new proposal for the issue of 'supported' desktops, which is blocking another planned criterion that we've been meaning to add for a while. I'm now proposing the term 'release-blocking desktops': it's simple, it does what it says on the tin, and it doesn't imply any value judgments about the desktops in question. How does that sound?
So all current reference to 'desktop' or 'the desktop' would be replaced by 'release-blocking desktops', and the proposed image size criterion would read:
- The network installation image, DVD image, and live images for
release-blocking desktops must meet current size requirements
Great :)
Now we just to have to decide which desktop spins are release blocking desktops.
Are we talking about all desktop spins we have?
If not which ones?
And does that include desktop spins that get introduced during the release cycle?
Any other gray areas we need to hash out on this topic or anyother ( best to get those done with as early as possible ).
JBG
On Tue, 2011-05-17 at 23:17 +0000, "Jóhann B. Guðmundsson" wrote:
On 05/17/2011 10:40 PM, Adam Williamson wrote:
Finally, I have a new proposal for the issue of 'supported' desktops, which is blocking another planned criterion that we've been meaning to add for a while. I'm now proposing the term 'release-blocking desktops': it's simple, it does what it says on the tin, and it doesn't imply any value judgments about the desktops in question. How does that sound?
So all current reference to 'desktop' or 'the desktop' would be replaced by 'release-blocking desktops', and the proposed image size criterion would read:
- The network installation image, DVD image, and live images for
release-blocking desktops must meet current size requirements
Great :)
Now we just to have to decide which desktop spins are release blocking desktops.
No, 'we' don't. For the tenth time, that is not a decision QA makes, nor is it a part of the release criteria process. I really wish you'd stop trying to expand these threads.
Are we talking about all desktop spins we have?
If not which ones?
Right now, the release-blocking desktops are GNOME (in its capacity as the default desktop) and KDE. It is not QA's job to decide this, and it's not the release criteria's job to quantify it.
On 05/17/2011 11:29 PM, Adam Williamson wrote:
On Tue, 2011-05-17 at 23:17 +0000, "Jóhann B. Guðmundsson" wrote:
On 05/17/2011 10:40 PM, Adam Williamson wrote:
Finally, I have a new proposal for the issue of 'supported' desktops, which is blocking another planned criterion that we've been meaning to add for a while. I'm now proposing the term 'release-blocking desktops': it's simple, it does what it says on the tin, and it doesn't imply any value judgments about the desktops in question. How does that sound?
So all current reference to 'desktop' or 'the desktop' would be replaced by 'release-blocking desktops', and the proposed image size criterion would read:
- The network installation image, DVD image, and live images for
release-blocking desktops must meet current size requirements
Great :)
Now we just to have to decide which desktop spins are release blocking desktops.
No, 'we' don't. For the tenth time, that is not a decision QA makes, nor is it a part of the release criteria process. I really wish you'd stop trying to expand these threads.
Are we talking about all desktop spins we have?
If not which ones?
Right now, the release-blocking desktops are GNOME (in its capacity asnot the default desktop) and KDE. It is not QA's job to decide this, and it's not the release criteria's job to quantify it.
I beg the differ we are entity within the project that is ultimatly responsable for overseeing the quality of the bits we ship and hand out to our userbase expecially when it comes to a media which gets handed out at various events or downloaded from our web site.
We exist to server all not a single SIG just like relese engineering and the design group.
We ( atleast me and you ) are at impass regarding this matter however I am supporting the changes you suggested since they will cover one or many desktops hence I say make them and point me to the party that you belive that is responsable for this and I can take it up with that party If..
A)
Wether this is upp for the QA community to decide and if not what else is and is not.
B)
If this is not for us to decide than they will decide it for us which desktop(s) are allowed to block a release and that party be ultimatly responsable for the quality of the other handout media or lack there of..
JBG
2011/5/17 "Jóhann B. Guðmundsson" johannbg@gmail.com:
On 05/17/2011 11:29 PM, Adam Williamson wrote:
On Tue, 2011-05-17 at 23:17 +0000, "Jóhann B. Guðmundsson" wrote:
On 05/17/2011 10:40 PM, Adam Williamson wrote:
Finally, I have a new proposal for the issue of 'supported' desktops, which is blocking another planned criterion that we've been meaning to add for a while. I'm now proposing the term 'release-blocking desktops': it's simple, it does what it says on the tin, and it doesn't imply any value judgments about the desktops in question. How does that sound?
So all current reference to 'desktop' or 'the desktop' would be replaced by 'release-blocking desktops', and the proposed image size criterion would read:
- The network installation image, DVD image, and live images for
release-blocking desktops must meet current size requirements
Great :)
Now we just to have to decide which desktop spins are release blocking desktops.
No, 'we' don't. For the tenth time, that is not a decision QA makes, nor is it a part of the release criteria process. I really wish you'd stop trying to expand these threads.
Are we talking about all desktop spins we have?
If not which ones?
Right now, the release-blocking desktops are GNOME (in its capacity asnot the default desktop) and KDE. It is not QA's job to decide this, and it's not the release criteria's job to quantify it.
I beg the differ we are entity within the project that is ultimatly responsable for overseeing the quality of the bits we ship and hand out to our userbase expecially when it comes to a media which gets handed out at various events or downloaded from our web site.
We exist to server all not a single SIG just like relese engineering and the design group.
We ( atleast me and you ) are at impass regarding this matter however I am supporting the changes you suggested since they will cover one or many desktops hence I say make them and point me to the party that you belive that is responsable for this and I can take it up with that party If..
I would take it to FESCO.
On Wed, 2011-05-18 at 00:13 +0000, "Jóhann B. Guðmundsson" wrote:
On 05/18/2011 12:07 AM, Stephen John Smoogen wrote:
I would take it to FESCO.
Fesco it is.
I will post the relevant ticket once I've filed it to this threat for other from QA community ( and any other interested party ) to cc themselves upon choose they to do so.
Thanks.
FESCo, and I believe spins sig also believes it should have a say.
QA does indeed provide services to the entire distro, but our responsibility is to provide the best QA we can for the things the project considers a) vital and then b) important, not to _define_ what the project considers vital and important. We can provide advice - for instance, if FESCo were to propose that every desktop ever could block the release, we might advise that it was likely to be very difficult to provide reasonable testing coverage for that - but we don't ultimately have the right to take the decision. If FESCo ultimately chose to go ahead anyway it would be our responsibility to do the best job we could with QAing every desktop in Fedora, but when we inevitably failed, we could point out that we'd told 'em so. =)
On 05/18/2011 12:21 AM, Adam Williamson wrote:
FESCo, and I believe spins sig also believes it should have a say.
QA does indeed provide services to the entire distro, but our responsibility is to provide the best QA we can for the things the project considers a) vital and then b) important, not to_define_ what the project considers vital and important. We can provide advice - for instance, if FESCo were to propose that every desktop ever could block the release, we might advise that it was likely to be very difficult to provide reasonable testing coverage for that - but we don't ultimately have the right to take the decision. If FESCo ultimately chose to go ahead anyway it would be our responsibility to do the best job we could with QAing every desktop in Fedora, but when we inevitably failed, we could point out that we'd told 'em so. =)
The project has long outgrown officially supporting and shipping a single desktop ( which is good ) however various processes like the design team and release engineering and us ( QA even thou I believe of those we are the once that are best prepared for it ) are falling behind the growth of the project which is bad.
Now I don't know if you remember when Red Hat just had hired you as their Fedora QA liaison or what ever your title officially is within Red Hat and you were first making your appearance here that I asked you to try to keeping things broad as possible ( And I do believe James as well ) cause the project had already then started to shown signs that would eventually head into this direction. ( as in expend in all direction as opposed to only in single one direction ).
Alot of ideas were being thrown back and forth between me James, Woods,Jeremy Jesse and others at that time before your arrival and at that time we decide to keep those relevant to build a strong QA foundation upon and set any other ideas especially those involving any future related topics to hold.
Where you lack faith and trust and see inevitable failure on QA community's behalf I see a worthy task to be solved a solution to be found and even during this release cycle I revived some of that ideas and discussed them loosely with James on irc which involved completely revisiting our process and I have full confident that we together ( QA Community ) can come up with and engineer a solution that not only will survive the past growth of the project but also any future growth that will happen in years to come.
The only inevatibly thing in this equation is that I will still be here when you or James have either move up and or move toward another position within Red Hat or quit for one reason or another that is if I will still be breathing before that time..
JBG
2011/5/17 "Jóhann B. Guðmundsson" johannbg@gmail.com:
On 05/18/2011 12:21 AM, Adam Williamson wrote:
FESCo, and I believe spins sig also believes it should have a say.
QA does indeed provide services to the entire distro, but our responsibility is to provide the best QA we can for the things the project considers a) vital and then b) important, not to_define_ what the project considers vital and important. We can provide advice - for instance, if FESCo were to propose that every desktop ever could block the release, we might advise that it was likely to be very difficult to provide reasonable testing coverage for that - but we don't ultimately have the right to take the decision. If FESCo ultimately chose to go ahead anyway it would be our responsibility to do the best job we could with QAing every desktop in Fedora, but when we inevitably failed, we could point out that we'd told 'em so. =)
The project has long outgrown officially supporting and shipping a single desktop ( which is good ) however various processes like the design team and release engineering and us ( QA even thou I believe of those we are the once that are best prepared for it ) are falling behind the growth of the project which is bad.
Could you drop this please. It is neither helpful or useful to the project.
On Wed, 2011-05-18 at 01:54 +0000, "Jóhann B. Guðmundsson" wrote:
Where you lack faith and trust and see inevitable failure on QA community's behalf I see a worthy task to be solved a solution to be found and even during this release cycle I revived some of that ideas and discussed them loosely with James on irc which involved completely revisiting our process and I have full confident that we together ( QA Community ) can come up with and engineer a solution that not only will survive the past growth of the project but also any future growth that will happen in years to come.
The only inevatibly thing in this equation is that I will still be here when you or James have either move up and or move toward another position within Red Hat or quit for one reason or another that is if I will still be breathing before that time..
I said it'd be an inevitable failure if we had to test every desktop in the world - it was just a silly exaggeration to make a point; that our job is to try and provide QA for the scope of Fedora _as defined by the appropriate group_, and we are not the group that defines the scope of the project. I'm not suggesting any particular vision of what that scope should be. I agree with many of your ideas - remember, I'm the one who first tried to propose that XFCE and LXDE should be able to block the release, and proposed the desktop validation process so that we now do organized testing on those desktops where we didn't before. I'm not saying that I don't think it would be a good idea for Fedora to consider more than a single desktop important; personally I think that _would_ be a good idea. All I'm saying is that we have to discuss and decide that on a wider level than the QA group.
On Tue, May 17, 2011 at 17:21:57 -0700, Adam Williamson awilliam@redhat.com wrote:
FESCo, and I believe spins sig also believes it should have a say.
Note that Spins SIG is still pretty dysfunctional.
On Tue, May 17, 2011 at 15:40:21 -0700, Adam Williamson awilliam@redhat.com wrote:
- A spin-kickstarts package which contains the exact kickstart files
used to build the release must be present in the release repository. The included kickstarts must define the correct set of release repositories
This is tricky to do, since the ks files can change during the freeze. This requires rebuilding the spin-kickstarts package and then getting it in to the package set without a lot of testing. spin-kickstarts is pretty safe to update so this probably isn't too risky. For F14, Jesse was doing rebuilds while doing RCs. For 15 there will be a zero day update. Since the freeze started only changes to some live images other than KDE or Desktop (Gnome) have been made. There has been one change to LXDE since RC3. There could potentially be changes for Soas before release as that live image hasn't been composed yet. I don't know if the LXDE people are planning to ask for a respin of their live image or not to get the xscreensaver-extras package installed before the release.
spin-kickstarts-0.15.6-1.fc15 has been built with the state used for RC3. It does not include the LXDE commit from after RC3. If a new LXDE is built before release then we should probably do another build before release. Same if SOAS has and ks changes before it is built. Otherwise I'll do another one a bit after the release to pick up the LXDE change.
spin-kickstarts-0.15.6-1.fc15 has been built with the state used for RC3. It does not include the LXDE commit from after RC3. If a new LXDE is built before release then we should probably do another build before release. Same if SOAS has and ks changes before it is built. Otherwise I'll do another one a bit after the release to pick up the LXDE change.
I know that SoaS will be changed here shortly. It will happen sooner if I can get off my butt and get some work done.
John Dulaney j_dulaney
On Tue, May 17, 2011 at 03:40:21PM -0700, Adam Williamson wrote: <SNIP>
Feedback please! :) For reference, the new F16 pages are:
https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria https://fedoraproject.org/wiki/Fedora_16_Beta_Release_Criteria https://fedoraproject.org/wiki/Fedora_16_Final_Release_Criteria
The additions look logical to me, +1
-AdamM
On Tue, 2011-05-17 at 15:40 -0700, Adam Williamson wrote:
Finally, I have a new proposal for the issue of 'supported' desktops, which is blocking another planned criterion that we've been meaning to add for a while. I'm now proposing the term 'release-blocking desktops': it's simple, it does what it says on the tin, and it doesn't imply any value judgments about the desktops in question. How does that sound?
So all current reference to 'desktop' or 'the desktop' would be replaced by 'release-blocking desktops', and the proposed image size criterion would read:
- The network installation image, DVD image, and live images for
release-blocking desktops must meet current size requirements
Since this part received generally positive feedback, I've gone ahead and implemented it for the Fedora 16 criteria. The Fedora 16 Beta criteria now include the image size criterion, and all three pages have been revised to use the 'release-blocking desktop' wording for desktop criteria.
https://fedoraproject.org/wiki/Fedora_16_Alpha_Release_Criteria https://fedoraproject.org/wiki/Fedora_16_Beta_Release_Criteria https://fedoraproject.org/wiki/Fedora_16_Final_Release_Criteria
I have also adjusted the preamble on each page (the bit under 'Final Release Requirements', before the actual criteria) to use a common template, so it can't get out of sync between the three pages, and added a definition of the term 'release-blocking desktops' to this preamble.
Thanks!
-
Adam Miller -
Adam Williamson -
Bruno Wolff III -
John Dulaney -
Jóhann B. Guðmundsson -
Stephen John Smoogen