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! _______________________________________________ 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].
