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 (18 Jan 2015 16:39:28 GMT) :
> 0. Do we think we might also need or want a mechanism to blacklist a branch,
> or we should just assume that our algos will only select the right ones
> and not hit any corner cases?


I think this is a good question, that deserves more thought.

Unfortunately I've not found any discussion about it on the blueprint
nor on the list, not even an example use case for such a blacklist, so
right now — sorry to be harsh — it looks like a technical idea that's
looking for a problem it might help solving.

So, what would be the use cases? I can think of a few potential ones:

1. A branch that satisfies the criteria for automatic builds, but
starts failing continuously, e.g. because its developer is on
vacation for 2 weeks.

=> as far as I understood, only that branch's developer is nagged
by failure notifications, so... who cares if it fails to build for
2 weeks?

2. Branches that modify only the doc or website

=> indeed, at first glance it seems a bit sad to spend CPU cycles
on building and potentially testing such branches. OTOH, these
branches, like any other, must not break the build, otherwise
they're not fit for merging, so it makes sense to build an ISO
(yes, an ISO, not only the website: we have quite a few things in
the ISO build process that somewhat depend on the website, run `git
grep usr/share/doc/tails/website -- config' if unconvinced).
And they must not break functionality either, so IMO it makes sense
to run the automated test suite on it too (again, we have quite
a few runtime functionality that depends on the bundled static
website).

bertagaz, any other use case you were thinking of?

Cheers!