I tried upgrading f12 to rawhide by adding rawhide as a software source. This was too big a task even with --skip-broken and the other suggested remedies.
Is it time for the images directory to reappear? In the past many problems with updated rawhides have been solved by doing a fresh install from boot.iso or pxeboot.
I tried upgrading f12 to rawhide by adding rawhide as a software source. This was too big a task even with --skip-broken and the other suggested remedies.
Is it time for the images directory to reappear?
The images directory is there as far as I know:
http://alt.fedoraproject.org/pub/alt/nightly-composes/
The only problem is that some of the daily isos failed to build :(, only few did and you may use them to install rawhide at any point.
In the past many problems with updated rawhides have been solved by doing a fresh install from boot.iso or pxeboot.
Fresh install is typically the best solution, but there are ways around getting through bad packages, like removing and reinstalling, but that may take a while :)
-- Chuck Forsberg
Regards,
Antonio
On Sun, Nov 29, 2009 at 15:30:57 -0800, Chuck Forsberg WA7KGX N2469R caf@omen.com wrote:
I tried upgrading f12 to rawhide by adding rawhide as a software source. This was too big a task even with --skip-broken and the other suggested remedies.
There are a number of broken deps in rawhide right now, as well as at least one file conflict. (File conflicts aren't detected in time for skip broken to work.)
If you work a bit you should be able to work things by looking at which packages are at the root of the problem and excluding them from the update. I was able to go from F12 to F13 a few weeks ago using yum.
On Sun, 2009-11-29 at 15:30 -0800, Chuck Forsberg WA7KGX N2469R wrote:
Is it time for the images directory to reappear? In the past many problems with updated rawhides have been solved by doing a fresh install from boot.iso or pxeboot.
From now on, Rawhide will not have install images. Rawhide is a never stopping never freezing repository of packages. To get to rawhide you'll need to start with say F12 and either point to the rawhide repo during install, or yum update to it post install.
https://fedoraproject.org/wiki/No_Frozen_Rawhide_Proposal
Jesse Keating said the following on 11/29/2009 10:52 PM Pacific Time:
On Sun, 2009-11-29 at 15:30 -0800, Chuck Forsberg WA7KGX N2469R wrote:
Is it time for the images directory to reappear? In the past many problems with updated rawhides have been solved by doing a fresh install from boot.iso or pxeboot.
From now on, Rawhide will not have install images. Rawhide is a never stopping never freezing repository of packages. To get to rawhide you'll need to start with say F12 and either point to the rawhide repo during install, or yum update to it post install.
The part about not making install images all the time is listed as a "discussion point", part of the official proposal: 'Do we always make install images for rawhide, or only make images for pending release tree?'
Big picture it seems like we've suddenly taken away access to a huge amount of potential nightly and periodic installer testing. Is this addressed somewhere in the proposal that I missed?
Are there particular reason for not creating the images any more that might help everyone understand more why this is a good idea?
Can you add something to the proposal explaining when, how often, and where install images will be created?
Thanks, John
Jesse Keating said the following on 11/29/2009 10:52 PM Pacific Time:
From now on, Rawhide will not have install images. Rawhide is a never stopping never freezing repository of packages. To get to rawhide you'll need to start with say F12 and either point to the rawhide repo during install, or yum update to it post install.
The wiki should be updated.
http://fedoraproject.org/wiki/Releases/Rawhide
Someone has kindly already posted Jesse's announcement on the forums, but, no doubt, we'll still be getting questions from people asking where is the rawhide boot.iso. :)
Scott Robbins said the following on 12/01/2009 08:30 AM Pacific Time:
Jesse Keating said the following on 11/29/2009 10:52 PM Pacific Time:
From now on, Rawhide will not have install images. Rawhide is a never stopping never freezing repository of packages. To get to rawhide you'll need to start with say F12 and either point to the rawhide repo during install, or yum update to it post install.
The wiki should be updated.
http://fedoraproject.org/wiki/Releases/Rawhide
Someone has kindly already posted Jesse's announcement on the forums, but, no doubt, we'll still be getting questions from people asking where is the rawhide boot.iso. :)
I guess that is part of the question I was trying to ask in my previous post... where did we clearly tell people the install images were being taken away? I was surprised myself.
Since we are changing the way we've been doing things for 12 releases have we considered getting the word out through some news article and blogs?
John
On Tue, 2009-12-01 at 09:11 -0800, John Poelstra wrote:
Scott Robbins said the following on 12/01/2009 08:30 AM Pacific Time:
Jesse Keating said the following on 11/29/2009 10:52 PM Pacific Time:
From now on, Rawhide will not have install images. Rawhide is a never stopping never freezing repository of packages. To get to rawhide you'll need to start with say F12 and either point to the rawhide repo during install, or yum update to it post install.
The wiki should be updated.
http://fedoraproject.org/wiki/Releases/Rawhide
Someone has kindly already posted Jesse's announcement on the forums, but, no doubt, we'll still be getting questions from people asking where is the rawhide boot.iso. :)
I guess that is part of the question I was trying to ask in my previous post... where did we clearly tell people the install images were being taken away? I was surprised myself.
Since we are changing the way we've been doing things for 12 releases have we considered getting the word out through some news article and blogs?
John
I'm going to translate this "we" into "you" here for you.
I've been talking about n-f-r quite a bit lately, in various venues. I don't believe I've sent something specifically about this to fedora-devel-announce, and I could. I also haven't blogged about it, I could also do that. If anybody wants to help me, they are welcome to it.
On 12/01/2009 12:11 PM, John Poelstra wrote:
Scott Robbins said the following on 12/01/2009 08:30 AM Pacific Time:
Jesse Keating said the following on 11/29/2009 10:52 PM Pacific Time:
From now on, Rawhide will not have install images. Rawhide is a never stopping never freezing repository of packages. To get to rawhide you'll need to start with say F12 and either point to the rawhide repo during install, or yum update to it post install.
The wiki should be updated. http://fedoraproject.org/wiki/Releases/Rawhide
Someone has kindly already posted Jesse's announcement on the forums, but, no doubt, we'll still be getting questions from people asking where is the rawhide boot.iso. :)
I guess that is part of the question I was trying to ask in my previous post... where did we clearly tell people the install images were being taken away? I was surprised myself.
Oh come on, you were even talking during the discussion.
From #fedora-meeting:
Nov 09 13:43:08 --- zodbot_ has changed the topic to: Fedora 13 (Meeting topic: Fedora Release Engineering) Nov 09 13:43:14 <Oxf13> notting: you had a question? Nov 09 13:43:33 <notting> sure. with respect to no frozen rawhide, should we turn off images for rawhide when we do the -> f13 switch? Nov 09 13:43:43 <Oxf13> notting: that's a great question Nov 09 13:44:55 <Oxf13> on one hand I think we should, as it gets us closer to NFR Nov 09 13:45:04 <Oxf13> on the other hand, I really wonder if we made the best choice there, not making install images Nov 09 13:45:29 <Oxf13> but *shrug* the time for that discussion as before, and in the future, so sure, lets turn off images Nov 09 13:45:50 <Oxf13> I do have one request from anaconda storage team to get a installable tree of F13 content up somewhere, so I can still do that Nov 09 13:46:05 <dgilmore> Oxf13: are we going to work on making nfr happen at fudcon? Nov 09 13:46:09 <notting> Oxf13: ok. that's going to require coordination when we do the switch, as the only way to do that right now is to edit the script Nov 09 13:46:15 <Oxf13> #proposal Disable image creation in F13 rawhide, as part of No Frozen Rawhide Nov 09 13:46:28 <Oxf13> dgilmore: before and at fudcon yes Nov 09 13:46:35 <dgilmore> Oxf13: :) awesome Nov 09 13:46:42 <Oxf13> dgilmore: I'd like to have some planning sessions before fudcon so that we spend more of fudcon doing instead of planning Nov 09 13:46:58 <dgilmore> Oxf13: that sounds sane Nov 09 13:47:09 <notting> Oxf13: above and beyond the next 3 releng meetings? Nov 09 13:47:54 <notting> (i just mean that we can co-opt them for planning if we want) Nov 09 13:47:57 <Oxf13> notting: maybe. I still can't really see over the F12 wall, so I'm not good at this right now Nov 09 13:48:11 <Oxf13> yeah, we'll at least use the releng meetings, but I might call some IRC hackfest sessions Nov 09 13:48:35 <dgilmore> Oxf13: so do we essentially see it as enabling F-13 in bodhi. and pushing out a F-13 tree as well as the rawhide tree? Nov 09 13:48:57 <dgilmore> the f-13 tree having images etc Nov 09 13:49:02 <Oxf13> dgilmore: once we've branched F-13 yes Nov 09 13:49:08 <Oxf13> that branching won't happen until Alpha timeframe Nov 09 13:49:20 <Oxf13> once we branch F-13 for alpha, rawhide moves on to F14 Nov 09 13:49:45 <poelcat> Oxf13: i'll volunteer to help set up planning sessions for FUDCon if you like Nov 09 13:50:09 <Oxf13> poelcat: ok, we can talk. I really want to get F12 out the door though and breath for a day or so Nov 09 13:50:18 <dgilmore> Oxf13: ok. i guess i missed something. since i thought there would be a bodhi controlled f13 stream as soon as we switch nfr on Nov 09 13:50:20 <poelcat> Oxf13: ok, let me know Nov 09 13:50:27 <dgilmore> ill go back and reread the proposal Nov 09 13:50:30 <Oxf13> dgilmore: no, that only happens once we branch Nov 09 13:50:52 <Oxf13> does anybody disagree with enacting the no images in rawhide part of NFR for F13 rawhide? Nov 09 13:51:18 <dgilmore> Oxf13: i dont, because anyone wanting an image can make there own Nov 09 13:51:49 <warren> what kind of images? Nov 09 13:51:54 <Oxf13> install.img Nov 09 13:51:56 <dgilmore> warren: all images Nov 09 13:51:59 <warren> oh Nov 09 13:52:03 <Oxf13> rawhide == just a repo of packages Nov 09 13:53:35 <pjones> by "no images", he means "don't run pungi on it" Nov 09 13:53:48 <Oxf13> yep Nov 09 13:53:57 <Oxf13> hi pjones (: Nov 09 13:54:01 <pjones> hello. Nov 09 13:54:04 <Oxf13> pjones: your still on board with this idea right? Nov 09 13:54:24 <pjones> I don't see a big issue with it; running pungi is easy enough once you drive some policy rules about how to do it into your head. Nov 09 13:54:42 <pjones> (always remove the whole pungi directory ahead of time, etc.) Nov 09 13:55:03 <Oxf13> pjones: wonder if I could make that better by automatically blowing away things unless you pass --no-clean Nov 09 13:55:17 <dgilmore> Oxf13: likely Nov 09 13:55:47 <Oxf13> #agreed F-13 rawhide will be just a repo of packages, as per no frozen rawhide
Since we are changing the way we've been doing things for 12 releases have we considered getting the word out through some news article and blogs?
Yeah, that's a fair point.
On Tue, 2009-12-01 at 11:30 -0500, Scott Robbins wrote:
The wiki should be updated.
I updated this page.
I assumed Rawhide boot.iso files, when they become available, will be available on a mirror accessible from: http://mirrors.fedoraproject.org/publiclist/Fedora/development/
Oh, and a quick question: why do we distribute identical files as Fedora-12-i386-netinst.iso and os/images/boot.iso ?
On Sun, 2009-11-29 at 22:52 -0800, Jesse Keating wrote:
To get to rawhide you'll need to start with say F12 and either point to the rawhide repo during install, or yum update to it post install.
It's my understanding that Live images will still be made available on a daily basis, and this installer can still be tested even if the non-Live installer can't. The Live installer method can thus be used to install Rawhide without needing to upgrade from a previous release (or to test directly without actually installing to hard drive). All the ways I could think of how to install Rawhide are documented on that wiki page; corrections and expansion welcome.
-B.
On Thu, 2009-12-03 at 05:06 -0500, Christopher Beland wrote:
Oh, and a quick question: why do we distribute identical files as Fedora-12-i386-netinst.iso and os/images/boot.iso ?
They are hardlinked to each other. We want to use the new name, netinst.iso, however libvirt and other systems were expecting a "boot.iso" name.
On Tue, 2009-12-01 at 08:16 -0800, John Poelstra wrote:
The part about not making install images all the time is listed as a "discussion point", part of the official proposal: 'Do we always make install images for rawhide, or only make images for pending release tree?'
It was a discussion point, and I've discussed it at multiple venues, FUDCons, IRC, in person with installer team, other meetings, releng meetings, etc.. We decided to enact that part of no frozen rawhide at the start of the Fedora 13 cycle. We also covered this in our recent Fedora Talk meeting and subsequent summary I sent out.
Big picture it seems like we've suddenly taken away access to a huge amount of potential nightly and periodic installer testing. Is this addressed somewhere in the proposal that I missed?
Yes, the installer team seems to agree that in the early stages of rawhide, that is before we branch, nightly testing is largely a wash, as too many things are in flux and bugs found are generally bugs ignored as development moves on. We will be working with the install team to create test day images when they feel that they have code that is worthy of testing and getting bugs on. I suspect we'll have a number of these images created leading up to the feature freeze and subsequent branch. Once branched, images will be produced nightly as we are in polish mode and all bugs matter.
Are there particular reason for not creating the images any more that might help everyone understand more why this is a good idea?
The images just aren't ready for use. There is no point in testing something that will be ignored, rewritten, obsoleted by further changes, etc... We're just not ready at this point in the development cycle to create install images for nightly consumption. Rawhide is now and will carry on being just a repo of packages.
Can you add something to the proposal explaining when, how often, and where install images will be created?
Yes, I still need to work the summary from our fedora talk meeting into the wiki page (anybody want to help with that?). I'm still trying to catch up with everything that got pushed off my plate in order to make F12 land.
On Tue, 2009-12-01 at 09:22 -0800, Jesse Keating wrote:
On Tue, 2009-12-01 at 08:16 -0800, John Poelstra wrote:
The part about not making install images all the time is listed as a "discussion point", part of the official proposal: 'Do we always make install images for rawhide, or only make images for pending release tree?'
It was a discussion point, and I've discussed it at multiple venues, FUDCons, IRC, in person with installer team, other meetings, releng meetings, etc.. We decided to enact that part of no frozen rawhide at the start of the Fedora 13 cycle. We also covered this in our recent Fedora Talk meeting and subsequent summary I sent out.
Big picture it seems like we've suddenly taken away access to a huge amount of potential nightly and periodic installer testing. Is this addressed somewhere in the proposal that I missed?
Yes, the installer team seems to agree that in the early stages of rawhide, that is before we branch, nightly testing is largely a wash, as too many things are in flux and bugs found are generally bugs ignored as development moves on. We will be working with the install team to create test day images when they feel that they have code that is worthy of testing and getting bugs on. I suspect we'll have a number of these images created leading up to the feature freeze and subsequent branch. Once branched, images will be produced nightly as we are in polish mode and all bugs matter.
Are there particular reason for not creating the images any more that might help everyone understand more why this is a good idea?
The images just aren't ready for use. There is no point in testing something that will be ignored, rewritten, obsoleted by further changes, etc... We're just not ready at this point in the development cycle to create install images for nightly consumption. Rawhide is now and will carry on being just a repo of packages.
Can you add something to the proposal explaining when, how often, and where install images will be created?
Yes, I still need to work the summary from our fedora talk meeting into the wiki page (anybody want to help with that?). I'm still trying to catch up with everything that got pushed off my plate in order to make F12 land.
I could use some additional clarification on this point. Daily rawhide install images might not have been the ideal/best mechanism for testing the installer during pre-alpha, but it was our only mechanism. Has there been any thought as to what mechanism or process will replace the use of rawhide install images for providing test feedback to the anaconda-devel team?
How do you envision install images being created in the new world of NFR? Who will be handling the image build process, and who decides when to build them?
Thanks, James
On Tue, 2009-12-01 at 15:28 -0500, James Laska wrote:
I could use some additional clarification on this point. Daily rawhide install images might not have been the ideal/best mechanism for testing the installer during pre-alpha, but it was our only mechanism. Has there been any thought as to what mechanism or process will replace the use of rawhide install images for providing test feedback to the anaconda-devel team?
How do you envision install images being created in the new world of NFR? Who will be handling the image build process, and who decides when to build them?
As I stated in my earlier mail, we can use test days or on-demand image creation when the installer team is ready to get feedback. rel-eng can produce images and either place them in that day's rawhide tree, or store them somewhere else that is accessible. The main idea here is that the anaconda team tells us when they are ready for widespread testing. Until that time, they have the tools and skills to produce images locally for whatever development testing they are working on.
On Tue, 2009-12-01 at 12:43 -0800, Jesse Keating wrote:
As I stated in my earlier mail, we can use test days or on-demand image creation when the installer team is ready to get feedback. rel-eng can produce images and either place them in that day's rawhide tree, or store them somewhere else that is accessible. The main idea here is that the anaconda team tells us when they are ready for widespread testing. Until that time, they have the tools and skills to produce images locally for whatever development testing they are working on.
I believe I remember you stating this some time during F12 development but I can't remember when. I believe it was stated that if you want to run rawhide and need to do an install, you'll either install F12 and yum update to rawhide from there (maybe after doing a completed update first?) or if in development in middle of a cycle, you install the beta/rc/whatever and update to rawhide from that.
(obviously if test images are created that goes to this as well)
Does that sound about correct?
On Tue, 2009-12-01 at 16:32 -0600, Mike Chambers wrote:
I believe I remember you stating this some time during F12 development but I can't remember when. I believe it was stated that if you want to run rawhide and need to do an install, you'll either install F12 and yum update to rawhide from there (maybe after doing a completed update first?) or if in development in middle of a cycle, you install the beta/rc/whatever and update to rawhide from that.
(obviously if test images are created that goes to this as well)
Does that sound about correct?
That's right. A small wrinkle is that you might even be able to use the F12 installer images, but point to rawhide as your install source and then you would install all the rawhide packages directly skipping the update step.
On Tue, Dec 1, 2009 at 5:49 PM, Jesse Keating jkeating@redhat.com wrote:
On Tue, 2009-12-01 at 16:32 -0600, Mike Chambers wrote:
I believe I remember you stating this some time during F12 development but I can't remember when. I believe it was stated that if you want to run rawhide and need to do an install, you'll either install F12 and yum update to rawhide from there (maybe after doing a completed update first?) or if in development in middle of a cycle, you install the beta/rc/whatever and update to rawhide from that.
(obviously if test images are created that goes to this as well)
Does that sound about correct?
That's right. A small wrinkle is that you might even be able to use the F12 installer images, but point to rawhide as your install source and then you would install all the rawhide packages directly skipping the update step.
How will Anaconda get tested if the version in Rawhide is never used?
On Tue, 2009-12-01 at 20:24 -0600, Todd wrote:
On Tue, Dec 1, 2009 at 5:49 PM, Jesse Keating jkeating@redhat.com wrote:
On Tue, 2009-12-01 at 16:32 -0600, Mike Chambers wrote:
I believe I remember you stating this some time during F12 development but I can't remember when. I believe it was stated that if you want to run rawhide and need to do an install, you'll either install F12 and yum update to rawhide from there (maybe after doing a completed update first?) or if in development in middle of a cycle, you install the beta/rc/whatever and update to rawhide from that.
(obviously if test images are created that goes to this as well)
Does that sound about correct?
That's right. A small wrinkle is that you might even be able to use the F12 installer images, but point to rawhide as your install source and then you would install all the rawhide packages directly skipping the update step.
How will Anaconda get tested if the version in Rawhide is never used?
I think what Jesse (and whomever else) is saying, is when anaconda is ready for testing, something will be done so that it can. Otherwise, it will be getting worked on and they (the anaconda developers) will know what the status is already on their own. I'm sure they know what it's status is most of the time and when they need to find out something or need more eyes, then we will get to try it and keep them informed.
On Tue, 2009-12-01 at 20:33 -0600, Mike Chambers wrote:
On Tue, 2009-12-01 at 20:24 -0600, Todd wrote:
On Tue, Dec 1, 2009 at 5:49 PM, Jesse Keating jkeating@redhat.com wrote:
On Tue, 2009-12-01 at 16:32 -0600, Mike Chambers wrote:
I believe I remember you stating this some time during F12 development but I can't remember when. I believe it was stated that if you want to run rawhide and need to do an install, you'll either install F12 and yum update to rawhide from there (maybe after doing a completed update first?) or if in development in middle of a cycle, you install the beta/rc/whatever and update to rawhide from that.
(obviously if test images are created that goes to this as well)
Does that sound about correct?
That's right. A small wrinkle is that you might even be able to use the F12 installer images, but point to rawhide as your install source and then you would install all the rawhide packages directly skipping the update step.
How will Anaconda get tested if the version in Rawhide is never used?
I think what Jesse (and whomever else) is saying, is when anaconda is ready for testing, something will be done so that it can. Otherwise, it will be getting worked on and they (the anaconda developers) will know what the status is already on their own. I'm sure they know what it's status is most of the time and when they need to find out something or need more eyes, then we will get to try it and keep them informed.
I don't disagree with the rational for dropping image creation. I understand how one could theoretically install rawhide packages using previously built install images and a rawhide yum repository.
QA requires a bit more clarity on the process by which images will be requested and built ... and we'll then need to update the schedule to reflect these changes. I'm not comfortable hand-waving this process until later.
Thanks, James
On 12/02/2009 04:01 PM, James Laska wrote:
On Tue, 2009-12-01 at 20:33 -0600, Mike Chambers wrote:
On Tue, 2009-12-01 at 20:24 -0600, Todd wrote:
On Tue, Dec 1, 2009 at 5:49 PM, Jesse Keating jkeating@redhat.com wrote:
On Tue, 2009-12-01 at 16:32 -0600, Mike Chambers wrote:
I believe I remember you stating this some time during F12 development but I can't remember when. I believe it was stated that if you want to run rawhide and need to do an install, you'll either install F12 and yum update to rawhide from there (maybe after doing a completed update first?) or if in development in middle of a cycle, you install the beta/rc/whatever and update to rawhide from that.
(obviously if test images are created that goes to this as well)
Does that sound about correct?
That's right. A small wrinkle is that you might even be able to use the F12 installer images, but point to rawhide as your install source and then you would install all the rawhide packages directly skipping the update step.
How will Anaconda get tested if the version in Rawhide is never used?
I think what Jesse (and whomever else) is saying, is when anaconda is ready for testing, something will be done so that it can. Otherwise, it will be getting worked on and they (the anaconda developers) will know what the status is already on their own. I'm sure they know what it's status is most of the time and when they need to find out something or need more eyes, then we will get to try it and keep them informed.
I don't disagree with the rational for dropping image creation. I understand how one could theoretically install rawhide packages using previously built install images and a rawhide yum repository.
QA requires a bit more clarity on the process by which images will be requested and built ... and we'll then need to update the schedule to reflect these changes. I'm not comfortable hand-waving this process until later.
I personally vote against any removal of the nightly composed images and think it's an step backwards in Fedora QA process if we do.
What's the general feel of the testers community about this do you want to keep the nightly composed images or dont you mind dropping it?
JBG
On 12/02/2009 08:01 AM, James Laska wrote:
On Tue, 2009-12-01 at 20:33 -0600, Mike Chambers wrote:
On Tue, 2009-12-01 at 20:24 -0600, Todd wrote:
On Tue, Dec 1, 2009 at 5:49 PM, Jesse Keatingjkeating@redhat.com wrote:
On Tue, 2009-12-01 at 16:32 -0600, Mike Chambers wrote:
I believe I remember you stating this some time during F12 development but I can't remember when. I believe it was stated that if you want to run rawhide and need to do an install, you'll either install F12 and yum update to rawhide from there (maybe after doing a completed update first?) or if in development in middle of a cycle, you install the beta/rc/whatever and update to rawhide from that.
(obviously if test images are created that goes to this as well)
Does that sound about correct?
That's right. A small wrinkle is that you might even be able to use the F12 installer images, but point to rawhide as your install source and then you would install all the rawhide packages directly skipping the update step.
How will Anaconda get tested if the version in Rawhide is never used?
I think what Jesse (and whomever else) is saying, is when anaconda is ready for testing, something will be done so that it can. Otherwise, it will be getting worked on and they (the anaconda developers) will know what the status is already on their own. I'm sure they know what it's status is most of the time and when they need to find out something or need more eyes, then we will get to try it and keep them informed.
I don't disagree with the rational for dropping image creation. I understand how one could theoretically install rawhide packages using previously built install images and a rawhide yum repository.
QA requires a bit more clarity on the process by which images will be requested and built ... and we'll then need to update the schedule to reflect these changes. I'm not comfortable hand-waving this process until later.
Looking at the original proposal and last meeting notes I didn't see any discussion about this, but maybe I missed it.... "last known good" images?
I would think we'd want to have at a bare minimum a canonical location for the "last known good" rawhide installer images. It seems really strange to me that we would really tell people to go as far back as the Fedora 12 GA image.
John
On 12/02/2009 12:10 PM, John Poelstra wrote:
I would think we'd want to have at a bare minimum a canonical location for the "last known good" rawhide installer images. It seems really strange to me that we would really tell people to go as far back as the Fedora 12 GA image.
Hrm. Yeah, that's not a bad suggestion.
On Wed, 2009-12-02 at 15:02 -0500, Peter Jones wrote:
On 12/02/2009 12:10 PM, John Poelstra wrote:
I would think we'd want to have at a bare minimum a canonical location for the "last known good" rawhide installer images. It seems really strange to me that we would really tell people to go as far back as the Fedora 12 GA image.
Hrm. Yeah, that's not a bad suggestion.
-- Peter
Old MacDonald had an agricultural real-estate tax abatement.
This can be easily accomplished by a wiki page. The wiki page contents can be updated as we move on from "just after release" to having a test day image or three created, to being after the branch. Bonus points for linking to this page from israwhidebroken.com
On Wed, 2009-12-02 at 09:10 -0800, John Poelstra wrote:
I would think we'd want to have at a bare minimum a canonical location for the "last known good" rawhide installer images. It seems really strange to me that we would really tell people to go as far back as the Fedora 12 GA image.
You can install off nightly live cd spins if going back to F12 is too hard for you.
On Wed, 2009-12-02 at 11:01 -0500, James Laska wrote:
QA requires a bit more clarity on the process by which images will be requested and built ... and we'll then need to update the schedule to reflect these changes. I'm not comfortable hand-waving this process until later.
Currently the Installer team knows to ask me (email, irc, bat signal) to produce images when they are ready for test. Many of that team know how to produce images on their own for local testing, and thus far I have only been contacted once, and that was for semi-private testing, not wide scale testing.
Going forward, I would propose that we use the existing Test Day framework to schedule and deliver images. Of course, test day is mostly geared around live images, but our deliverable would be even smaller, boot.iso. Hypothetically we can store this test day image in a path that can remain live for a period of time, and be a reference for the latest install images produced.
Obviously there needs to be consensus between the installer team and the QA team about how this will work out, and I apologize for the arm waving to date. John Poelstra created https://fedoraproject.org/wiki/No_Frozen_Rawhide_Implementation last night which will help coordinate and document our execution of the proposal. A point about coordinating test images prior to branch needs to be added to the wiki. I will get to it at some point today unless somebody gets there first.
On 12/02/2009 06:01 PM, Jesse Keating wrote:
On Wed, 2009-12-02 at 11:01 -0500, James Laska wrote:
QA requires a bit more clarity on the process by which images will be requested and built ... and we'll then need to update the schedule to reflect these changes. I'm not comfortable hand-waving this process until later.
Currently the Installer team knows to ask me (email, irc, bat signal) to produce images when they are ready for test. Many of that team know how to produce images on their own for local testing, and thus far I have only been contacted once, and that was for semi-private testing, not wide scale testing.
Cant we use a "known to work" anaconda version to distribute with the nightly-created live images or are we going to have to schedule test day's around anaconda working that day or not?
Going forward, I would propose that we use the existing Test Day framework to schedule and deliver images. Of course, test day is mostly geared around live images, but our deliverable would be even smaller, boot.iso. Hypothetically we can store this test day image in a path that can remain live for a period of time, and be a reference for the latest install images produced.
I propose we keep producing nightly-composes live iso and just use a working anaconda installer or remove the option to install out of those images then just install or the switch out that installer if the anaconda team wants some install testing done...
Reducing the number of test days or having the ability for each SIG pointing to a live iso to conduct some testing on their own is not the way to go and certainly not making test days depended on the "installer" working or not.
These images serve more purpose then just to check or test the installer....
JBG
On Wed, 2009-12-02 at 18:28 +0000, "Jóhann B. Guðmundsson" wrote:
Cant we use a "known to work" anaconda version to distribute with the nightly-created live images or are we going to have to schedule test day's around anaconda working that day or not?
When using live images to test parts of the OS, it doesn't matter if the installer is functional or not, as you aren't installing. You're booting the live image and running the application(s) in question.
Going forward, I would propose that we use the existing Test Day framework to schedule and deliver images. Of course, test day is mostly geared around live images, but our deliverable would be even smaller, boot.iso. Hypothetically we can store this test day image in a path that can remain live for a period of time, and be a reference for the latest install images produced.
I propose we keep producing nightly-composes live iso and just use a working anaconda installer or remove the option to install out of those images then just install or the switch out that installer if the anaconda team wants some install testing done...
When the anaconda team wants install testing done, they're going to be more interested in the non-live case (or at least equally interested). We'll need to produce boot.iso.
Reducing the number of test days or having the ability for each SIG pointing to a live iso to conduct some testing on their own is not the way to go and certainly not making test days depended on the "installer" working or not.
Who's proposing we reduce the number of test days? I'm certainly not. Each SIG can point to whatever test day image they want, provided the image contains the software they wish to test, or the ability to install said software in the live environment. Installation of said live environment to the local machine is not really critical to the test day (unless of course the test day is to cover said installation)
These images serve more purpose then just to check or test the installer....
I think you're confused. Nobody that I can see is suggesting we stop producing or produce less test day live images.
On Wed, 2009-12-02 at 10:40 -0800, Jesse Keating wrote:
These images serve more purpose then just to check or test the installer....
I think you're confused. Nobody that I can see is suggesting we stop producing or produce less test day live images.
Right, this is what I was going to point out. Johann, we're not talking about nightly live images here, we're talking about the installer in the Rawhide mirror tree. Nightly live images will still be produced and will still contain the latest version of anaconda in the repos at that time, with no guarantee as to whether it works or not.
On 12/02/2009 06:40 PM, Jesse Keating wrote:
On Wed, 2009-12-02 at 18:28 +0000, "Jóhann B. Guðmundsson" wrote:
Cant we use a "known to work" anaconda version to distribute with the nightly-created live images or are we going to have to schedule test day's around anaconda working that day or not?
When using live images to test parts of the OS, it doesn't matter if the installer is functional or not, as you aren't installing. You're booting the live image and running the application(s) in question.
Well we possible get a bit anaconda gui testing for the few that actually install from those images..
When the anaconda team wants install testing done, they're going to be more interested in the non-live case (or at least equally interested). We'll need to produce boot.iso.
Ofcourse. Can we identify which non gui related Anaconda testing require a human interaction and try focusing on automating the rest ( if we dont more or less cover that already ?
I think you're confused. Nobody that I can see is suggesting we stop producing or produce less test day live images.
Yes I apologize I somehow had gotten it through my thick skull that we were going to stop producing nightly-composes.
JBG
On Wed, 2009-12-02 at 10:01 -0800, Jesse Keating wrote:
Currently the Installer team knows to ask me (email, irc, bat signal) to produce images when they are ready for test. Many of that team know how to produce images on their own for local testing, and thus far I have only been contacted once, and that was for semi-private testing, not wide scale testing.
Going forward, I would propose that we use the existing Test Day framework to schedule and deliver images. Of course, test day is mostly geared around live images, but our deliverable would be even smaller, boot.iso. Hypothetically we can store this test day image in a path that can remain live for a period of time, and be a reference for the latest install images produced.
One of the rather important bits of test days is follow-up - we have people show up, test, file a bunch of bugs. Great. Now what happens? Hopefully, the bugs get worked on, and a proposed fix is landed in the affected component (anaconda). Then what? How does the reporter test that the fix works? We have another test day?
The main test day track tends to get overloaded anyway; do we have a regular anaconda test day track for each release? Anaconda test days every two weeks?
On Wed, 2009-12-02 at 10:52 -0800, Adam Williamson wrote:
One of the rather important bits of test days is follow-up - we have people show up, test, file a bunch of bugs. Great. Now what happens? Hopefully, the bugs get worked on, and a proposed fix is landed in the affected component (anaconda). Then what? How does the reporter test that the fix works? We have another test day?
How about a "verification day" ? But yes, I think that's the idea, either a follow up test day, updates.img files passed around via bugs, or the next snapshot, it all depends at what point we are in the development process.
The main test day track tends to get overloaded anyway; do we have a regular anaconda test day track for each release? Anaconda test days every two weeks?
Good questions. I think it's about time we are able to handle multiple test subjects on given days, as your testing crowd will be both different and similar. Is that possible?
On Wed, 2009-12-02 at 11:29 -0800, Jesse Keating wrote:
On Wed, 2009-12-02 at 10:52 -0800, Adam Williamson wrote:
One of the rather important bits of test days is follow-up - we have people show up, test, file a bunch of bugs. Great. Now what happens? Hopefully, the bugs get worked on, and a proposed fix is landed in the affected component (anaconda). Then what? How does the reporter test that the fix works? We have another test day?
How about a "verification day" ? But yes, I think that's the idea, either a follow up test day, updates.img files passed around via bugs, or the next snapshot, it all depends at what point we are in the development process.
That would be workable. It doesn't seem _better_ than the current situation, honestly, but it seems workable.
The main test day track tends to get overloaded anyway; do we have a regular anaconda test day track for each release? Anaconda test days every two weeks?
Good questions. I think it's about time we are able to handle multiple test subjects on given days, as your testing crowd will be both different and similar. Is that possible?
Possible, yes, obviously as long as different people are running each event. It may not be optimal sometimes, but we have done it before (main track and fitnfinish test days have overlapped), there's no reason it can't happen.
On 12/02/2009 10:01 AM, Jesse Keating wrote:
On Wed, 2009-12-02 at 11:01 -0500, James Laska wrote:
QA requires a bit more clarity on the process by which images will be requested and built ... and we'll then need to update the schedule to reflect these changes. I'm not comfortable hand-waving this process until later.
Currently the Installer team knows to ask me (email, irc, bat signal) to produce images when they are ready for test. Many of that team know how to produce images on their own for local testing, and thus far I have only been contacted once, and that was for semi-private testing, not wide scale testing.
I think James' point was missed. He didn't say anything about the Installer team. He was speaking for what the *QA Team* needed.
This seems like the introduction of a new testing model in Fedora whereby no testing happens until the maintainer requests that it happen. It would be great to hear directly from the Installer team directly how this changes their testing needs and how we can all best help them.
John
On 12/02/2009 02:20 PM, John Poelstra wrote:
On 12/02/2009 10:01 AM, Jesse Keating wrote:
On Wed, 2009-12-02 at 11:01 -0500, James Laska wrote:
QA requires a bit more clarity on the process by which images will be requested and built ... and we'll then need to update the schedule to reflect these changes. I'm not comfortable hand-waving this process until later.
Currently the Installer team knows to ask me (email, irc, bat signal) to produce images when they are ready for test. Many of that team know how to produce images on their own for local testing, and thus far I have only been contacted once, and that was for semi-private testing, not wide scale testing.
I think James' point was missed. He didn't say anything about the Installer team. He was speaking for what the *QA Team* needed.
I think Jesse spoke to that need, really. He's saying that the current plan is for us (the anaconda team) to proactively ask for a compose and set up a test day when we think testing from non-developers is worthwhile, and that we (the anaconda team) are versed in building our own test images, or one-offs for to hand off to specific testers, for when we think we need them.
We're also perfectly happy to coordinate with QA to create images for a) milestones, or b) if they feel we haven't had a test day recently enough, or c) we haven't spun a test tree for automated test systems recently enough, or even all of these.
This seems like the introduction of a new testing model in Fedora whereby no testing happens until the maintainer requests that it happen. It would be great to hear directly from the Installer team directly how this changes their testing needs and how we can all best help them.
This is exactly what we discussed on #f-m. You were there.
On 12/01/2009 09:33 PM, Mike Chambers wrote:
On Tue, 2009-12-01 at 20:24 -0600, Todd wrote:
On Tue, Dec 1, 2009 at 5:49 PM, Jesse Keatingjkeating@redhat.com wrote:
On Tue, 2009-12-01 at 16:32 -0600, Mike Chambers wrote:
I believe I remember you stating this some time during F12 development but I can't remember when. I believe it was stated that if you want to run rawhide and need to do an install, you'll either install F12 and yum update to rawhide from there (maybe after doing a completed update first?) or if in development in middle of a cycle, you install the beta/rc/whatever and update to rawhide from that.
(obviously if test images are created that goes to this as well)
Does that sound about correct?
That's right. A small wrinkle is that you might even be able to use the F12 installer images, but point to rawhide as your install source and then you would install all the rawhide packages directly skipping the update step.
How will Anaconda get tested if the version in Rawhide is never used?
I think what Jesse (and whomever else) is saying, is when anaconda is ready for testing, something will be done so that it can. Otherwise, it will be getting worked on and they (the anaconda developers) will know what the status is already on their own. I'm sure they know what it's status is most of the time and when they need to find out something or need more eyes, then we will get to try it and keep them informed.
Reading the anaconda list, I see a very large number of changes coming down the road, all significant and probably as complex as the storage rewrite. I bet the anaconda developers would appreciate the widest possible testing as soon as changes hit rawhide.
If rawhide is to be frozen, can a mechanism to test anaconda, at a minimum, be provided? Testing the rest of rawhide is easy and has been well documented.
Thanks, from a cheerful anaconda tester who may now be tearful.
On Thu, 2009-12-03 at 11:45 -0500, Clyde E. Kunkel wrote:
Reading the anaconda list, I see a very large number of changes coming down the road, all significant and probably as complex as the storage rewrite. I bet the anaconda developers would appreciate the widest possible testing as soon as changes hit rawhide.
If rawhide is to be frozen, can a mechanism to test anaconda, at a minimum, be provided? Testing the rest of rawhide is easy and has been well documented.
Thanks, from a cheerful anaconda tester who may now be tearful.
Well, if you read the posts from Peter Jones, that's actually *not* what they want. They say they want to move to model where they provide images for testing anaconda when they're ready to.
On 12/03/2009 02:21 PM, Adam Williamson wrote:
On Thu, 2009-12-03 at 11:45 -0500, Clyde E. Kunkel wrote:
Reading the anaconda list, I see a very large number of changes coming down the road, all significant and probably as complex as the storage rewrite. I bet the anaconda developers would appreciate the widest possible testing as soon as changes hit rawhide.
If rawhide is to be frozen, can a mechanism to test anaconda, at a minimum, be provided? Testing the rest of rawhide is easy and has been well documented.
Thanks, from a cheerful anaconda tester who may now be tearful.
Well, if you read the posts from Peter Jones, that's actually *not* what they want. They say they want to move to model where they provide images for testing anaconda when they're ready to.
Then why put updates in rawhide? For the live isos? I know there is a way with updages.img files to test, but creating them is beyond me. Also, I guess we could use Mr. Keating's pungi method.
It is too bad that the good old days of easily testing the cool changes being made in anaconda are over.
On 12/03/2009 03:03 PM, Clyde E. Kunkel wrote:
On 12/03/2009 02:21 PM, Adam Williamson wrote:
On Thu, 2009-12-03 at 11:45 -0500, Clyde E. Kunkel wrote:
Reading the anaconda list, I see a very large number of changes coming down the road, all significant and probably as complex as the storage rewrite. I bet the anaconda developers would appreciate the widest possible testing as soon as changes hit rawhide.
If rawhide is to be frozen, can a mechanism to test anaconda, at a minimum, be provided? Testing the rest of rawhide is easy and has been well documented.
Thanks, from a cheerful anaconda tester who may now be tearful.
Well, if you read the posts from Peter Jones, that's actually *not* what they want. They say they want to move to model where they provide images for testing anaconda when they're ready to.
Then why put updates in rawhide? For the live isos? I know there is a way with updages.img files to test, but creating them is beyond me. Also, I guess we could use Mr. Keating's pungi method.
It is too bad that the good old days of easily testing the cool changes being made in anaconda are over.
I think this is a severe mischaracterization. I really think that this change should actually make testing /less/ difficult - in that the thing you're testing will be something we at least think /should/ work.
Think of this as a plan to make testable images flow pretty often, but to limit /untestable/ images.
On 12/03/2009 03:27 PM, Peter Jones wrote:
On 12/03/2009 03:03 PM, Clyde E. Kunkel wrote:
On 12/03/2009 02:21 PM, Adam Williamson wrote:
On Thu, 2009-12-03 at 11:45 -0500, Clyde E. Kunkel wrote:
Reading the anaconda list, I see a very large number of changes coming down the road, all significant and probably as complex as the storage rewrite. I bet the anaconda developers would appreciate the widest possible testing as soon as changes hit rawhide.
If rawhide is to be frozen, can a mechanism to test anaconda, at a minimum, be provided? Testing the rest of rawhide is easy and has been well documented.
Thanks, from a cheerful anaconda tester who may now be tearful.
Well, if you read the posts from Peter Jones, that's actually *not* what they want. They say they want to move to model where they provide images for testing anaconda when they're ready to.
Then why put updates in rawhide? For the live isos? I know there is a way with updages.img files to test, but creating them is beyond me. Also, I guess we could use Mr. Keating's pungi method.
It is too bad that the good old days of easily testing the cool changes being made in anaconda are over.
I think this is a severe mischaracterization. I really think that this change should actually make testing /less/ difficult - in that the thing you're testing will be something we at least think /should/ work.
Think of this as a plan to make testable images flow pretty often, but to limit /untestable/ images.
Actually, I was looking forward to trying my hand some python coding and trying some things. Steep learning curve since my old IBM systems programming days on 360/370.
BTW, what is/was the rationale for having untestable versions of anaconda in rawhide?
On Thu, 2009-12-03 at 21:52 -0500, Clyde E. Kunkel wrote:
Actually, I was looking forward to trying my hand some python coding and trying some things. Steep learning curve since my old IBM systems programming days on 360/370.
BTW, what is/was the rationale for having untestable versions of anaconda in rawhide?
Well, they're not 'untestable', you'll be able to use them from the nightly live composes.
On 12/04/2009 12:05 AM, Adam Williamson wrote:
On Thu, 2009-12-03 at 21:52 -0500, Clyde E. Kunkel wrote:
Actually, I was looking forward to trying my hand some python coding and trying some things. Steep learning curve since my old IBM systems programming days on 360/370.
BTW, what is/was the rationale for having untestable versions of anaconda in rawhide?
Well, they're not 'untestable', you'll be able to use them from the nightly live composes.
True, but there seemed to be some discussion that the anaconda team didn't want the triage hassle of dealing with bugs they knew were present. Seems they will still get them from users testing with the nightly live composes.
Oh, well. In the day we would just say, "I'll shut up now and just color in my coloring book."
On 12/01/2009 11:16 AM, John Poelstra wrote:
Jesse Keating said the following on 11/29/2009 10:52 PM Pacific Time:
On Sun, 2009-11-29 at 15:30 -0800, Chuck Forsberg WA7KGX N2469R wrote:
Is it time for the images directory to reappear? In the past many problems with updated rawhides have been solved by doing a fresh install from boot.iso or pxeboot.
From now on, Rawhide will not have install images. Rawhide is a never stopping never freezing repository of packages. To get to rawhide you'll need to start with say F12 and either point to the rawhide repo during install, or yum update to it post install.
The part about not making install images all the time is listed as a "discussion point", part of the official proposal: 'Do we always make install images for rawhide, or only make images for pending release tree?'
Big picture it seems like we've suddenly taken away access to a huge amount of potential nightly and periodic installer testing. Is this addressed somewhere in the proposal that I missed?
I'm not sure how you figure we've taken away access - we've made it so an individual tester, working alone, has to do a compose themself, which is admittedly a higher barrier to entry. But the side effect is that people aren't testing trees we don't expect to work, and we've done that without adding a serious communication overhead ("hey guys, will the tree work today?")
Are there particular reason for not creating the images any more that might help everyone understand more why this is a good idea?
Usually it's a waste of time and energy, especially early in the rawhide cycle where we (the the anaconda team) are doing heavy development.
Can you add something to the proposal explaining when, how often, and where install images will be created?
Maybe we ought to have sortof a fire-drill test day sometime soon where we spin an anaconda we think will work and do some smoke-test composes and installs, and then do a compose for the test day just to get in the habit of the new process.
On Wed, 2009-12-02 at 14:37 -0500, Peter Jones wrote:
On 12/01/2009 11:16 AM, John Poelstra wrote:
Jesse Keating said the following on 11/29/2009 10:52 PM Pacific Time:
On Sun, 2009-11-29 at 15:30 -0800, Chuck Forsberg WA7KGX N2469R wrote:
Is it time for the images directory to reappear? In the past many problems with updated rawhides have been solved by doing a fresh install from boot.iso or pxeboot.
From now on, Rawhide will not have install images. Rawhide is a never stopping never freezing repository of packages. To get to rawhide you'll need to start with say F12 and either point to the rawhide repo during install, or yum update to it post install.
The part about not making install images all the time is listed as a "discussion point", part of the official proposal: 'Do we always make install images for rawhide, or only make images for pending release tree?'
Big picture it seems like we've suddenly taken away access to a huge amount of potential nightly and periodic installer testing. Is this addressed somewhere in the proposal that I missed?
I'm not sure how you figure we've taken away access - we've made it so an individual tester, working alone, has to do a compose themself, which is admittedly a higher barrier to entry. But the side effect is that people aren't testing trees we don't expect to work, and we've done that without adding a serious communication overhead ("hey guys, will the tree work today?")
It's an interesting difference between the two styles here.
Having testing tightly coupled with development. Versus, more formalized boundaries between devel start/stop ... qa start/stop. Different projects/teams decide on different approaches, so there isn't a right answer here. However, at the pace at which we move in Fedora ... a tight coupling between development and testing seems to fit best. The alternative is QA bombards development with defects well after they have context switched out of that code.
Are there particular reason for not creating the images any more that might help everyone understand more why this is a good idea?
Usually it's a waste of time and energy, especially early in the rawhide cycle where we (the the anaconda team) are doing heavy development.
During this time ... should new packages be landing that are expected not to work? There's been talk for a while that installer development and testing would happen off to the side ... and then be tagged appropriately so that it lands in rawhide after it passes some level of verification. I'm certainly open to helping that succeed.
Is that the problem we are attempting to address by removing rawhide install images?
Can you add something to the proposal explaining when, how often, and where install images will be created?
Maybe we ought to have sortof a fire-drill test day sometime soon where we spin an anaconda we think will work and do some smoke-test composes and installs, and then do a compose for the test day just to get in the habit of the new process.
Using the current schedule [1], we have the following milestones where QA will need install images for testing.
= Alpha = 2010-02-04 - Pre-compose install testing [2] 2010-02-11 - Test Alpha 'Test Compose' (boot media testing) 2010-02-18 - Test Alpha Candidate
= Beta = 2010-03-11 - Pre-compose install testing [2] 2010-03-18 - Test Beta 'Test Compose' (boot media testing) 2010-03-25 - Test Beta Candidate
= Final = 2010-04-15 - Pre-compose install testing [2] 2010-04-22 - Test RC 'Test Compose' (boot media testing) 2010-04-29 - Test RC Candidate
This model assumes that rawhide install images were available for anyone to test at anytime. As Adam points out elsewhere in the thread, where this helps us is so people can verify bug fixes. We also benefit from community testing against rawhide leading up to these milestones.
If I'm summarizing the pain correctly ... the push back seems to come from providing testing before development is ready to accept bug reports?
Does this only happen during early development? Meaning, after Alpha/Beta is having nightly built rawhide install images still a problem? When in the schedule [1] would be an acceptable time to start providing test feedback?
Another point, I think we can't limit the discussion to just anaconda-devel. There are a *lot* of other critical components pulled into the install images that are developed outside that group.
[1] http://poelstra.fedorapeople.org/schedules/f-13/f-13-releng-tasks.html [2] Not yet present in the scheduled, but mirrors F-12
On Wed, 2009-12-02 at 15:16 -0500, James Laska wrote:
Using the current schedule [1], we have the following milestones where QA will need install images for testing.
= Alpha = 2010-02-04 - Pre-compose install testing [2] 2010-02-11 - Test Alpha 'Test Compose' (boot media testing) 2010-02-18 - Test Alpha Candidate = Beta = 2010-03-11 - Pre-compose install testing [2] 2010-03-18 - Test Beta 'Test Compose' (boot media testing) 2010-03-25 - Test Beta Candidate = Final = 2010-04-15 - Pre-compose install testing [2] 2010-04-22 - Test RC 'Test Compose' (boot media testing) 2010-04-29 - Test RC CandidateThis model assumes that rawhide install images were available for anyone to test at anytime. As Adam points out elsewhere in the thread, where this helps us is so people can verify bug fixes. We also benefit from community testing against rawhide leading up to these milestones.
If I'm summarizing the pain correctly ... the push back seems to come from providing testing before development is ready to accept bug reports?
Does this only happen during early development? Meaning, after Alpha/Beta is having nightly built rawhide install images still a problem? When in the schedule [1] would be an acceptable time to start providing test feedback?
Nightly install images will be created once we branch rawhide. The branch event is scheduled for the Feature Freeze, which is a week before the Alpha freeze. So you'll have images for all the above listed milestones automatically, and leading up to those milestones you'll have images when the installer team requests them, and when we hit certain dates like test composes.
On 12/02/2009 03:18 PM, Jesse Keating wrote:
On Wed, 2009-12-02 at 15:16 -0500, James Laska wrote:
Does this only happen during early development? Meaning, after Alpha/Beta is having nightly built rawhide install images still a problem? When in the schedule [1] would be an acceptable time to start providing test feedback?
Nightly install images will be created once we branch rawhide. The branch event is scheduled for the Feature Freeze, which is a week before the Alpha freeze. So you'll have images for all the above listed milestones automatically, and leading up to those milestones you'll have images when the installer team requests them, and when we hit certain dates like test composes.
Oh, right, I didn't even think to mention that. So yeah, there are still going to be nightly composes in alpha/beta timeframe.
On 12/02/2009 03:16 PM, James Laska wrote:
If I'm summarizing the pain correctly ... the push back seems to come from providing testing before development is ready to accept bug reports?
Does this only happen during early development?
No. In fact, a part of this *is* due the difficulty in testing loader changes. Pretty often the (current) workflow goes like:
1) joe writes a loader change that's complex 2) joe compile tests it, tries to unit test code snippets isolated into their own tiny (transient) test harnesses where possible (which it often is not). 3) joe fixes whatever problems are found 4) joe submits the change for review on a-d-l 5) a-d-l review finds some problems, misses others 6) if a-d-l review finds problems, joe goes back to step 2 7) else, joe commits the change 8) 0 or more days later a build gets done by joe or somebody else 9) rawhide composes with the new build 10) rawhide is broken because of one character in a string someplace being wrong! 11) bob comes in in the morning and does a test install with rawhide 12) bob fixes the error, goes through steps 1-7 again (or maybe just commits a trivial change, but generally not these days) 13) pile-o-bug-reports arrives, almost all of them after the bug is fixed 14) mike spends 8 hours triaging bug reports that are completely irrelevant
Note how there's no set schedule on step 8.
This happens at all times during development. We can alleviate some of the problem by writing/improving tools, for example to build/update anaconda's initrd.img, but I don't honestly believe that will cut down more than, say, half of this problem. It also doesn't really help with of the /combined/ tree (that is, with changes other developers are working on), with arches that aren't what we're using on the desktop, or with e.g. CD media. For those, there's not much you can do without just building it in koji and punging up a tree. And we don't really feel it's worth pushing to testers, no matter what quality of tester or test methodology, until we've done some simple trials first.
The new way, including some feedback from this thread, is more like this:
1) steps 1-8 from above happen 9) somebody on the anaconda team composes a tree[1] 10) we (the anaconda team) smoke test it and go through steps 11 and 12 above 13) one of us asks for a tree to be composed for testing 14) we (I guess rel-eng does this bit) put some images somewhere for testing [details needed here] 15) if they're not catastrophic we replace the LNG images with those 16) we (the anaconda team) go back to step 1.
[1]: I'm most likely going to automate this so we automatically get x86_64 and i386 trees composed on cutlet (our local mirror) any time it sees a new anaconda package in rawhide.
Meaning, after Alpha/Beta is having nightly built rawhide install images still a problem? When in the schedule [1] would be an acceptable time to start providing test feedback?
I think maybe after beta could work if we feel it's really necessary; it's not wholly unreasonable to expect us (the anaconda team) to be a bit more rigorous in composing our own trees and testing before (and after) step 7. But you've got to realize that that's basically just reverting to the original process above, which still has step 8 with no set schedule. So it's not like that's really different - you're just seeing the same installer over and over.
Another point, I think we can't limit the discussion to just anaconda-devel. There are a *lot* of other critical components pulled into the install images that are developed outside that group.
We didn't ever limit this discussion to anaconda-devel. Actually, I don't think we've discussed this there at all.
On Wed, 2009-12-02 at 15:47 -0500, Peter Jones wrote:
On 12/02/2009 03:16 PM, James Laska wrote:
If I'm summarizing the pain correctly ... the push back seems to come from providing testing before development is ready to accept bug reports?
Does this only happen during early development?
No. In fact, a part of this *is* due the difficulty in testing loader changes. Pretty often the (current) workflow goes like:
- joe writes a loader change that's complex
- joe compile tests it, tries to unit test code snippets isolated into their own tiny (transient) test harnesses where possible (which it often is not).
- joe fixes whatever problems are found
- joe submits the change for review on a-d-l
- a-d-l review finds some problems, misses others
- if a-d-l review finds problems, joe goes back to step 2
- else, joe commits the change
- 0 or more days later a build gets done by joe or somebody else
- rawhide composes with the new build
- rawhide is broken because of one character in a string someplace being wrong!
- bob comes in in the morning and does a test install with rawhide
- bob fixes the error, goes through steps 1-7 again (or maybe just commits a trivial change, but generally not these days)
- pile-o-bug-reports arrives, almost all of them after the bug is fixed
- mike spends 8 hours triaging bug reports that are completely irrelevant
Note how there's no set schedule on step 8.
This happens at all times during development. We can alleviate some of the problem by writing/improving tools, for example to build/update anaconda's initrd.img, but I don't honestly believe that will cut down more than, say, half of this problem. It also doesn't really help with of the /combined/ tree (that is, with changes other developers are working on), with arches that aren't what we're using on the desktop, or with e.g. CD media. For those, there's not much you can do without just building it in koji and punging up a tree. And we don't really feel it's worth pushing to testers, no matter what quality of tester or test methodology, until we've done some simple trials first.
The new way, including some feedback from this thread, is more like this:
- steps 1-8 from above happen
- somebody on the anaconda team composes a tree[1]
- we (the anaconda team) smoke test it and go through steps 11 and 12 above
- one of us asks for a tree to be composed for testing
- we (I guess rel-eng does this bit) put some images somewhere for testing [details needed here]
- if they're not catastrophic we replace the LNG images with those
- we (the anaconda team) go back to step 1.
This is great, thanks for taking the time to outline the detailed steps. The above procedure sounds like a solid plan. In addition to the above process, during the initial F-13 rollout of NFR, might I request a few additions?
First, that we continue having rawhide install images available at all times. However, they aren't images that are pungi'd every night ... they are simply be the images built and tested from the last time through step#15 above. So for now in the F-13 cycle, they would be the LNG (last known good) of F-12. This seems to have the best of both worlds by allowing us to work the kinks out of this new process, while keeping up expectations/messaging around rawhide image availability.
Second, that we choose a few dates where we will attempt to walk through the 16 steps prior to the freeze. My worry with not planning ahead would be we wait until our pre-alpha verification step ... and it's a train wreck.
[1]: I'm most likely going to automate this so we automatically get x86_64 and i386 trees composed on cutlet (our local mirror) any time it sees a new anaconda package in rawhide.
Let's talk @ FUDCon. Will Woods and David Cantrell have some interesting ideas on how AutoQA might be used to respond to certain events and provide test feedback for you. Presently, it will detect new rawhide install images and run through a basic install. The image detection mechanism and the desired tests can be adjusted as needed.
Meaning, after Alpha/Beta is having nightly built rawhide install images still a problem? When in the schedule [1] would be an acceptable time to start providing test feedback?
I think maybe after beta could work if we feel it's really necessary; it's not wholly unreasonable to expect us (the anaconda team) to be a bit more rigorous in composing our own trees and testing before (and after) step 7. But you've got to realize that that's basically just reverting to the original process above, which still has step 8 with no set schedule. So it's not like that's really different - you're just seeing the same installer over and over.
Another point, I think we can't limit the discussion to just anaconda-devel. There are a *lot* of other critical components pulled into the install images that are developed outside that group.
We didn't ever limit this discussion to anaconda-devel. Actually, I don't think we've discussed this there at all.
Sorry, didn't meant to imply that discussion was only taking place on anaconda-devel-list. Just meant there may be other development teams who rely on the rawhide install images for test feedback.
Thanks, James
On Wed, 2009-12-02 at 17:01 -0500, James Laska wrote:
First, that we continue having rawhide install images available at all times. However, they aren't images that are pungi'd every night ... they are simply be the images built and tested from the last time through step#15 above. So for now in the F-13 cycle, they would be the LNG (last known good) of F-12. This seems to have the best of both worlds by allowing us to work the kinks out of this new process, while keeping up expectations/messaging around rawhide image availability.
That's a sound suggestion. Would you be willing to add it to either the N-F-R proposal page, or the implementation page? ( https://fedoraproject.org/wiki/No_Frozen_Rawhide_Implementation )
Second, that we choose a few dates where we will attempt to walk through the 16 steps prior to the freeze. My worry with not planning ahead would be we wait until our pre-alpha verification step ... and it's a train wreck.
Again sound suggestion, and again please add it to the implementation page so that it doesn't get lost in a long email thread.
James Laska said the following on 12/02/2009 02:01 PM Pacific Time:
On Wed, 2009-12-02 at 15:47 -0500, Peter Jones wrote:
On 12/02/2009 03:16 PM, James Laska wrote:
If I'm summarizing the pain correctly ... the push back seems to come from providing testing before development is ready to accept bug reports?
Does this only happen during early development?
No. In fact, a part of this *is* due the difficulty in testing loader changes. Pretty often the (current) workflow goes like:
- joe writes a loader change that's complex
- joe compile tests it, tries to unit test code snippets isolated into their own tiny (transient) test harnesses where possible (which it often is not).
- joe fixes whatever problems are found
- joe submits the change for review on a-d-l
- a-d-l review finds some problems, misses others
- if a-d-l review finds problems, joe goes back to step 2
- else, joe commits the change
- 0 or more days later a build gets done by joe or somebody else
- rawhide composes with the new build
- rawhide is broken because of one character in a string someplace being wrong!
- bob comes in in the morning and does a test install with rawhide
- bob fixes the error, goes through steps 1-7 again (or maybe just commits a trivial change, but generally not these days)
- pile-o-bug-reports arrives, almost all of them after the bug is
fixed
- mike spends 8 hours triaging bug reports that are completely irrelevant
Note how there's no set schedule on step 8.
This happens at all times during development. We can alleviate some of the problem by writing/improving tools, for example to build/update anaconda's initrd.img, but I don't honestly believe that will cut down more than, say, half of this problem. It also doesn't really help with of the /combined/ tree (that is, with changes other developers are working on), with arches that aren't what we're using on the desktop, or with e.g. CD media. For those, there's not much you can do without just building it in koji and punging up a tree. And we don't really feel it's worth pushing to testers, no matter what quality of tester or test methodology, until we've done some simple trials first.
The new way, including some feedback from this thread, is more like
this:
- steps 1-8 from above happen
- somebody on the anaconda team composes a tree[1]
- we (the anaconda team) smoke test it and go through steps 11 and 12 above
- one of us asks for a tree to be composed for testing
- we (I guess rel-eng does this bit) put some images somewhere for testing [details needed here]
- if they're not catastrophic we replace the LNG images with those
- we (the anaconda team) go back to step 1.
This is great, thanks for taking the time to outline the detailed steps. The above procedure sounds like a solid plan. In addition to the above process, during the initial F-13 rollout of NFR, might I request a few additions?
First, that we continue having rawhide install images available at all times. However, they aren't images that are pungi'd every night ... they are simply be the images built and tested from the last time through step#15 above. So for now in the F-13 cycle, they would be the LNG (last known good) of F-12. This seems to have the best of both worlds by allowing us to work the kinks out of this new process, while keeping up expectations/messaging around rawhide image availability.
I really like this. Then we don't need a separate canonical location for 'LNG' because we only update the install images in 'rawhide' if they have gone through some level of sanity testing?'
Would there be any downside to continuing to do this even after NFR is an established part of our process?
Second, that we choose a few dates where we will attempt to walk through the 16 steps prior to the freeze. My worry with not planning ahead would be we wait until our pre-alpha verification step ... and it's a train wreck.
If you want to propose these dates (see other schedule) email I can put them in now so we have a working draft to discuss at FUDCon.
John
-
"Jóhann B. Guðmundsson" -
Adam Williamson -
Antonio Olivares -
Bruno Wolff III -
Christopher Beland -
Chuck Forsberg WA7KGX -
Clyde E. Kunkel -
James Laska -
Jesse Keating -
Jesse Keating -
John Poelstra -
Matthias Clasen -
Mike Chambers -
Peter Jones -
Scott Robbins -
Todd