Hi,
bertagaz wrote (16 Feb 2015 14:32:57 GMT) :
> On Wed, Feb 11, 2015 at 11:49:02PM +0100, intrigeri wrote:
>> 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.
Most of us (including me) do the same as Alan, but IMO that's almost
irrelevant to the topic at hand. This same scenario reads:
And I need to know if my branch build is broken by something else
possibly weeks after my last commit (by e.g Debian changes,
changes in branch B, ...)
^^^^^^^^^^^^^^^^^^^
... and we cannot possibly get this without locally merging the topic
branch F into B before building.
The important point here may be the *locally* word. This merge would
only be done in Jenkins own temporary Git checkout, and wouldn't
affect how we're handling our branches' Git history.
> 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.
OK. But apparently, either I misunderstood why Alan had trouble with
this idea, or Alan has misunderstood the idea, so IMO it would be good
to have his opinion now that I've clarified what I think we should do,
and why. Alan?
>> * 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.
As discussed on IRC, we have about 10 days of logs on the filesystem
currently, so you can still retrieve recent stats about it.
The earlier, the better, as we're frozen and the more we wait, the
less the numbers will be meaningful.
> The Global build stats Jenkins plugin [1] seems interesting to display the
> stats once more logs are kept. Shall I install it?
Let's give it a try, yes.
>> * "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.
OK. Let's keep in mind that he may not have thought of this potential
problem yet.
Now, I wonder if we could solve this quite simply by having the RM be
notified for *base* branch build failure only. The RM doesn't care
about topic branches that haven't been submitted for merging
yet, right?
(So I'm skipping the rest of the discussion, that may actually
be moot.)
> 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. :)
Indeed, that's the kind of aliases the RMs can trivially update
themselves, without asking the infra team to do anything.
Cheers,
--
intrigeri
