Autor: bertagaz Data: Para: The Tails public development discussion list Assunto: Re: [Tails-dev] Automated builds specification
On Thu, Feb 12, 2015 at 12:22:45AM +0100, intrigeri wrote: > Here's one more: the proposed notification mechanism makes sense to me
> for topic branches. But for "base" branches, it's more complicated:
>
> * when building after a Git push, it does make sense to notify the
> committer on failure -- that is, in theory, the person who merged
> something into the branch, and apparently forgot to make sure it
> builds before pushing
>
> * when building daily, on failure I don't see how it can be useful to
> notify the last person who merged something to into a base branch;
> so, who is responsible to keep these branches in a buildable state?
> In practice, quite often, by default it's me -- and I never
> volunteered to do that. I'd rather see this formally put on the
> release manager's plate, since these branches are only useful to
> prepare the next release. So, IMO the RM should be notified in
> this case.
>
> Now, if it's too complicated, implementation-wise, to differenciate
> these two situations, and we have to choose between committer, RM, and
> tails-dev@, then I'd be in favour of notifying either the RM or
> tails-dev@, who are more likely to be/feel responsible for the failure
> than the last committer.
>
> Thoughts?
Agree with that as stated in my previous email. I think it is doable to
differenciate them, by splitting the daily and on git push job definiton
maybe. Having a look at plugins might help, as well as how other projects
do that (as you stated elsewhere).
For consistency with our roles, I think it make more sense to have the RM
notified, but don't block on the tails-dev choice.