Releasing Alphas and Betas without "freezing"

[Oliver Grawert]

hi,
Am Donnerstag, den 21.06.2012, 18:52 +0200 schrieb Rick Spencer:
> On Thu, Jun 21, 2012 at 6:43 PM, Jono Bacon <jono at ubuntu.com>
> >
> > The Kubuntu team are welcome to determine whatever milestones they
> > want - no one is suggesting anything needs to change for the flavors
> > in their testing cadence. I am purely stating how Nick will be
> > working: the only output of this work is assured mandatory test case
> > testing and this testing uncovering any bugs. As I said earlier, this
> > work is independent of whether we remove milestones or not.
> 
> I think the terminology here is the source of some confusion. I think
> when you (Jono) say "milestones" people hear specifically the already
> defined "alpha and beta" Milestones.  I don't think you mean that. I
> think you are using the term "milestones" differently, to just mean
> "chosen dates for testing".

i would like to not actually see them as chosen dates for testing but
also as work flow helpers, if i milestone a bug assigned to me the
submitter will expect it to be fixed by the milestone ... same goes for
work items etc... if you look at the upload frequency on the
$release-changes ML you will see a massive increase in uploads of
package sets right before a milestone and/or freeze, they are a virtual
deadline many of us use to schedule their work. i think milestones on
the release schedule should persist as they are (including alphas) so
that we have our data points for bugs work item tracking and uploaders.

milestones as iso images are beyond the testing purpose also a very
important marketing instrument. i'm pretty sure you see increases in iso
downloads right after a milestone was announced to the press, we will
lose these testers that only download and test the isos because their
favorite news site just had a note about them ... 
i'm not sure how many useful bug reports we get from this kind of drive
by users, but there are likely some among them with hardware we cant
even imagine to run ubuntu on and for which we would never get any bugs
until its to late (post release) without that broader testing. also the
announcement alone gets us free promotion we will lose when dropping
this process.

while i'm all in the camp of dropping milestones (just the images
though !), we cant really make sure to cover all hardware combinations
out there in our automated setup and will still need manual testing if
we want to stay a general purpose distro ... is there any planning in
canonical management that covers to compensate this (events, press
releases that call for testers, gifts from the canonical shop for great
achievements in HW testing etc) ?

also once we gain spare time from dropping the testing, how about doing
"community wide virtual topic sprints" as a replacement ...

the foundations team does them regular (we recently had an installer
sprint as well as  a python3 porting sprint) and we are really
successful with that ... 
i could imagine instead of having the milestone business we could pick
certain features we want to fix (or have certain transitions) that also
span across multiple (or even all) teams and have a virtual sprint where
everyone lines up to certain timezone based teams and everyone works
with a particular focus ... 
i know this happens already in terms of i.e. transitions, but it usually
ends up with one or two persons actually doing it and working their
butts off and a few additional contributors that submit one or the other
small fix.

i think it would be a good idea to use the free developer time we gain
from dropping milestone testing for such kind of scheduled sprints where
also the community is deeply involved.

ciao
	oli
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part
URL: <https://lists.ubuntu.com/archives/ubuntu-release/attachments/20120621/6ed7a19b/attachment.pgp>