[07:13] <green7> If during testing I find a new bug, should I file a new bug and then fill the bug number in the report?
=== trijntje_ is now known as trijntje
[08:42] <smartboyhw> Hi!
=== smartboyhw is now known as smartboyhw_away
=== smartboyhw_away is now known as smartboyhw
[12:38] <smartboyhw> Hi!
[14:11] <stlsaint> is anyone getting duplicate source.list entires in latest precise 12.04.1 iso's or is this a already filed bug?
[14:11] <stlsaint> I even downloaded precise release iso and run apt-get update and duplicate entires
[14:11] <smartboyhw> Hi stlsaint
[14:12] <stlsaint> smartboyhw: o/
[14:12] <smartboyhw> That should be a new bug
[14:12] <stlsaint> well i have seen bugs dating back to march but no fix and i would like to ensure im not tripping and that others are seeing this before i go filing bugs
[14:13] <smartboyhw> No fix = no fix
[14:15] <stlsaint> it adds in the Debcdrom entries multiple times
[14:16] <smartboyhw> Actually, ask that in #ubuntu-bugs
[15:49] <smartboyhw> BYE!
[16:49] <balloons> ping phillw
[16:49] <phillw> balloons: pong
[16:49] <balloons> phillw, got your email string
[16:49] <balloons> :-)
[16:49] <phillw> okies.
[16:49] <balloons> hehe
[16:49] <balloons> I'm going to go through and reply
[16:50] <balloons> just thought I'd let you know it might take me a bit to do so
[16:52] <phillw> there's no mad rush :)
[16:53] <balloons> phillw, the short story is that yes cadence testing is not well supported tool wish
[16:53] <balloons> *wise
[16:54] <balloons> and it looks like you may have found the original conversation that triggered us undertakng it
[16:54] <phillw> wel, karl did... he's been getting himself upto speed on it so better to understand it.
[16:55] <phillw> and in so doing, has helped me understand things better :)
[16:55] <balloons> I'll write more in my reply, but as you likely saw in the email, our original plan for the cycle was to test milestones, starting a few days early to help lower respins and give devs more time to finalize before the milestone
[16:56] <balloons> the basic idea was, during the milestone we have to exhaustively test all the images and then re-test when there are re-spins
[16:56] <balloons> that's no fun to have a respin
[16:56] <balloons> so if we take a little time to find the serious bugs but running a test or two before we generate the iso's during the milestone we can avoid this
[16:56] <phillw> I know, it does stress the testers!
[16:57] <balloons> in other words, when we spin a milestone iso, we should have every reason to believe it will pass all the tests
[16:57] <balloons> we test it and release it.. no respins
[16:59] <phillw> as long as you keep your fingers crossed for the installer ;)
[16:59] <balloons> this overall in my mind should have reduced the stress and respin count.. since we were NOT going to exhaustively test the daily before the actual milestone testing, it should have been less work. and if we found a bug, the devs could take a few days and fix it before pushing an image
[16:59] <balloons> again, if you push a milestone image and you want testing on it.. me finding a bug should be an exception, not a normal event
[17:00] <balloons> especially one large enough to cause a respin
[17:00] <balloons> tis but one opinion :-)
[17:01] <phillw> the freeze to qa seems to have consistently been late. This reduces the time for testing / bug fixing. If we say 5 days before a milestone, then doing it 3 days before is not right.
=== yofel_ is now known as yofel