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. bert. _______________________________________________ Tails-dev mailing list [email protected] https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to [email protected].
