On Wed, Feb 11, 2015 at 11:29:45PM +0100, intrigeri wrote:
> 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.
It's just that, something that did pop up in my head while writing the
blueprint, but I didn't find much corresponding branches while watching
the unmerged ones during the 1.3 release cycle.
> 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).
Ack, sounds reasonable. However from what I've seen, it sometimes means a
lot of branches so I wonder if we scaled our infra enough for that, as we
didn't include this branches in our maths since the beginning of the
discussion.
> bertagaz, any other use case you were thinking of?
Not really at the moment.
bert.
