Re: [Tails-dev] Automated builds specification

Supprimer ce message

Répondre à ce message
Auteur: intrigeri
Date:  
À: The Tails public development discussion list
Sujet: Re: [Tails-dev] Automated builds specification
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