← Back to team overview

ubuntu-phone team mailing list archive

Re: A new Image release Proposal

 

On Fri, Nov 29, 2013 at 4:27 PM, Oliver Grawert <ogra@xxxxxxxxxx> wrote:
> 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.

I hope to see this scheduled time window approach getting implemented
very soon. Hopefully we can announce the schedule on monday and start
following that as early as Tuesday. Didrocks will follow up with
details I am sure...


> 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 ...

Well, I am working towards a trigger based approach and you want to go
to a cronjob based approach... what concept of that is 1990 and what
is 2014 is hard to proof, but for some it might be easy to guess :)
... (sorry, couldn't resist to make that punt)

Let's really fold this discussion till Monday. Personally, I think we
made good progress towards a reasonable next step and your
mail/complains really helped us to find a way to improve things
without cron (even if you feel you didnt get exactly what you wanted).


>
> 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 ...


This you rightly complain about. Unfortunately, I can't state the
reasons for the delay in a public forum, but I will work with the CI
team during next week to see how we can tackle the urgent actions
agreed during the sprint very soon...

>
> ciao
>         oli

Have a great weekend!

 - Alexander

>
>


References