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