Re: [Tails-dev] Automated builds specification

Delete this message

Reply to this message
Author: intrigeri
Date:  
To: The Tails public development discussion list
Subject: Re: [Tails-dev] Automated builds specification
hi,

bertagaz wrote (27 Feb 2015 10:07:03 GMT) :
> On Thu, Feb 26, 2015 at 08:46:17PM +0100, bertagaz wrote:
>> On Thu, Feb 26, 2015 at 05:21:23PM +0100, anonym wrote:
>> > On 11/01/15 20:07, Jurre van Bergen wrote:
>> > > Developers should be able to trigger automatic builds for a branch
>> > > whose build was dropped (eg. last commit too old) by pushing a dumb
>> > > commit on a timestamp file in that branch.
>> >
>> > Can't we make builds trigger via signed email too? Polluting the Git
>> > repo like that seems ugly to me.

[...]
> While discussing last night about this interesting point you raised, we
> thought of an easy and obvious fix to that history pollution.


> In fact, that's even already implemented in the way we often work: after a
> release, people working on a topic branch often merge stable or testing
> back in it. So there *will* be new commits on their branches.


> Does that sound better to you?


At least it does sound better to me: the problem at hand is detecting
the transition of a branch between inactive and active state.

When coming back to a branch after not having worked on it since 6+
weeks, the first thing I do is indeed to make the branch up-to-date
wrt. changes that happened in the last 6+ weeks, then making sure it
still builds locally, and after that I would push the branch and it
will become active again (from Jenkins' perspective), as
bertagaz explained.

bertagaz, DrWhax: please explain this on the blueprint -- you now
have two proposed wordings already so it should be easy :)

Cheers,
--
intrigeri