Hi,
> We're already drafted some scenario's on:
> https://tails.boum.org/blueprint/automated_builds_and_tests/autobuild_specs/
I've finally looked at it. I've pushed minor typo/formatting fixes and
rephrasing, nothing important.
I'm very happy with basically everything in the "2. Scenarios"
section, which seems to be the most important one. Yay!
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.
* 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.
* "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 assume these concerns (except the 2nd one probably) are not blocking
wrt. starting to implement stuff, so: Go!
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.
* The "tag T" notation (undefined) is somewhat conflicting with the
"branch T" one that's defined earlier.
Cheers,
--
intrigeri
