Hi,
Thx for the extensive review!
On Wed, Feb 11, 2015 at 11:49:02PM +0100, intrigeri wrote:
> > We're already drafted some scenario's on:
> > https://tails.boum.org/blueprint/automated_builds_and_tests/autobuild_specs/
>
> I have a few concerns, though:
>
> * "Scenario 2 : developer" doesn't make it clear if branch T is
> build *after being locally merged into branch B*, or not.
> Given that's what we're really interested in, and given
> "Scenario 1 : reviewer" is clearer (answer is: yes), I guess the
> answer is yes here too, but this should be clarified.
IIRC that was something Alan had troubles with, as not being the way she
usually work on a feature branch, which I think was more close to "Work
work work on the branch, and then when the feature is ready, merge the base
branch in it." So she usually do not merge the base branch very often.
But I agree this is not the best way to go, so if Alan doesn't come up with
a block on this, I agree to add the clarification.
> * I see no statistics about how many ISOs we are *currently*
> building each day. So it's not clear to me if our current setup
> can support building N more branches, once a day each. It would be
> useful to have this number (e.g. raw number per day during the 1.3
> release cycle, and daily average). Of course we can fix that later
> (either by throwing more hardware at it, or by tweaking the branch
> selection algorithm a bit, or by decreasing the build frequency
> a bit for some branches based on some criteria), but if we can
> know *right now* that the designed plan cannot possibly work, then
> I would find it a bit sad to invest time into it.
That's a logical awesome idea I'm ashamed not to have had sooner.
Still, it seems that it comes too late, after some searching it appears
that our Jenkins don't keep much stats. I'll extend the jjb setting that
remove build logs after 1 day.
The Global build stats Jenkins plugin [1] seems interesting to display the
stats once more logs are kept. Shall I install it?
> * "Scenario 3 : RM" says "I need to know when a branch FTBFS", but
> I see no notification mechanism planned, so... how is the RM
> supposed to know. Also, whenever stalled topic branches start
> failing, this can imply an avalanche of daily email to the RM, who
> will of course start ignoring all email from Jenkins and then
> we've lost. I'm particularly worried about this topic since anonym
> (our RM most of the time) didn't comment on this proposal yet, and
> has already expressed concerns about this kind of issues.
I think anonym did comment on this proposal, he did a review of this
blueprint already.
But I agree the RM notification part is not very clear.
We could make it so that the RM is emailed when a daily build job fails,
the "build failed on git push" one being sent to the commit author anyway,
according to our scenarios. Of course the commit author would also be
notified for the daily ones too.
If that's still too much from the RM point of view, we could have the RM
notified only the first time a daily job fails.
That seems to make sense to me: the RM gets a notification in the mailbox
once a day for failed jobs, and then he/she either fix it, or ask someone
to work on that. To have a developer claiming to Jenkins he/she is now
responsible of that branch (and thus is getting the next notifications),
he/she would just have to do a dumb commit on the branch.
One thing that this question also raise is the fact that the RM is not
always the same person, so I'm wondering how to have jenkins notifying the
right email depending on who is the RM for the next release. First thing
that come in top of my mind is... a schleuder address. :)
> I assume these concerns (except the 2nd one probably) are not blocking
> wrt. starting to implement stuff, so: Go!
Great!
> To end with, I find two things confusing in the rest of the document:
>
> * Scenario numbering is reset in the "Future ideas" section, so one
> cannot simply refer to "scenario 2" unambiguously, without making
> it clear if they're speaking of "scenario 2 in the Scenarios
> section", or of "scenario 2 in the Future ideas section";
> I suggest you avoid assigning duplicated scenario identifiers.
Fixed.
> * The "tag T" notation (undefined) is somewhat conflicting with the
> "branch T" one that's defined earlier.
Fixed.
bert.
[1]
https://wiki.jenkins-ci.org/display/JENKINS/Global+Build+Stats+Plugin
