ubuntu-phone team mailing list archive

[Oliver Grawert <ogra@xxxxxxxxxx>]

hi,
On Fr, 2013-11-29 at 15:43 +0100, Alexander Sack wrote:
> >
> > And the archive is always open, besides the landing team syncing the
> > landings first in a ppa and then in proposed, so we should always have
> > an automated job that creates such snapshots.
> 
> The fact that the archive uploads are in a separate process makes
> things hairy, yes. However, that doesn't means that we should add
> another decoupled process (cronjob based image production) and hope
> that things will be better....
> 
no, the fact that you ignore that we have a properly established, well
tested and proven process for image production that covers both, uploads
and CI landings since several years makes things hairy. 

the proposed archive migration is exactly that, a tool to completely
decouple landings of any kind from image builds. despite that we have
worked fine with that process and nearly all valuable developers in the
team have said (in the side IRC discussion to this mail thread as well
as in person and at several occurrences during sprints) that it would
make sense to not artificially duplicate this process by wasting rare
manpower ...

> >
> > We should all work against the schedule, not against the will of the
> > landing team to trigger a new image (as that's not really a CI), and
> > please, we're engineers :-)
> 
> Note that the current proposal is to have a schedule. Not a point
> schedule through a cronjob, but a smart, time window schedule.
> 
> How is such approach still an issue for you?

it creates another artificial waste of of manpower until that magical
schedule is implemented. 
as you explained on IRC to me you wanted cron disabled to make sure that
a landing does not land by accident 10 minutes after the cron job
started so that the landing has to wait for 2 hours ...
this stems from a time where our image builds actually took 2h ... 
nowadays the rootfs build takes exactly 30 minutes, if your landing
missed that window by 10 minutes you can immediately trigger a new build
manually, it will be queued up and start in 20 min, so you just get your
landing in the next image, nothing is lost ... (and if this specific
case happens more than twice a month I would be surprised)

because someone made a law in 1880 it doesn't mean that this law is
still based on valid grounds in 1990 ... while I consider the above a
valid argument (and to me it is the only valid one I have heard
"pro-manual-scheduling") it is based on a last decades law ... 

anyway, since I see that it is pointless to bring up valid arguments or
to show how much reluctancy to this waste is there across the board, I
will rest my case, lets do manual builds until a magic automated
schedule drops in our lap (from wherever) ...

one final point though ... there were big words made in advance to the
client sprint that such things would be discussed and solutions would be
worked out, I was not speaking up prior to the sprint (to which I had
wished I would have been invited to bring these topics up) because I
trusted these words.

effectively exactly nothing changed after the sprint ... 
... this is majorly disappointing ...

ciao
	oli

Attachment: signature.asc
Description: This is a digitally signed message part