Avoiding fragmentation with a rolling release

[Steve Langasek]

On Fri, Mar 01, 2013 at 12:39:58AM +0100, Oliver Grawert wrote:
> hi,
> On Do, 2013-02-28 at 20:14 +0000, Matthew Paul Thomas wrote:

> > So, I'm all in favor of having two-yearly releases. But for the same
> > reasons as six-monthly releases are bad, monthly snapshots and/or a
> > rolling release would be much worse -- unless we are careful to
> > communicate that they are for contributors only, not for end users or
> > ISVs.

> the problem here is currently that we only keep the last three images
> around for space reasons. 
> if a fatal installer bug goes unnoticed for three days you don't have
> any working install media. for this case it is good to have a last known
> good image around (we were exactly bitten by such a case right before
> the recent desktop team sprint where nexus7 images were discovered to be
> nonfunctional on Friday evening before the sprint started).

> while i appreciate that we want to have each and every image installable
> all the time, it is unrealistic to expect 100% coverage here. if we
> don't want to have monthly milestones that get a manual sign off from
> testers, we need to keep a larger amount (1 week, 10 days) of images
> around to make sure to cover such cases.

I think the solution Martin pointed out in his mail addresses this much
better:

> I also think we need to integrate our daily image smoketests better to
> avoid publishing a built image on cdimage.u.c. as /current if it fails
> the tests. /current should always point to the last one which is
> working IMHO.

The broken images in question did not / would not pass daily smoke testing.
So if this was wired up in a feedback loop to cdimage, we wouldn't have to
worry about the last good image falling off.

-- 
Steve Langasek                   Give me a lever long enough and a Free OS
Debian Developer                   to set it on, and I can move the world.
Ubuntu Developer                                    http://www.debian.org/
slangasek at ubuntu.com                                     vorlon at debian.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <https://lists.ubuntu.com/archives/ubuntu-devel/attachments/20130228/b8ad7add/attachment.pgp>