Avoiding fragmentation with a rolling release

[Oliver Grawert]

hi,
On Do, 2013-02-28 at 17:51 -0800, Steve Langasek wrote:
> 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.
yes, but in a world where we target mobile "devices" (vs mobile
developer boards with all their bells and whistles as we did until now)
the technical challenges here are huge ... (robots to press power
buttons on devices etc ?)

> 
> 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.
> 
fully agreed, *if* we manage to make these devices work in our
infrastructure...

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-devel/attachments/20130301/b258bce0/attachment.pgp>