Hi, anonym wrote (26 Jan 2015 12:17:22 GMT) : > While I appreciate #1 forcing us to track upstream, I think these build > failures that depend on things external to Tails (e.g. fetching from APT > repos outside of our control) are quite problematic:
> * They further complicate things for potential Tails contributors and > adds the impression that Tails building is a fragile black art > (rightfully so, actually!). > * I worry that excessive build failure notifications will result in some > kind of "the boy who cried wolf" syndrome for us, or at least that they > become a nuisance we tend to ignore or delay, instead of something we > appreciate. OK. Indeed, a build failure notification is not the nicest possible way to tell us we have work to do. > IMHO we already expose ourselves too much to these kind of externally > triggered build issues, and without a 24/7 on call developer that will > fix them ASAP, I think we need less of them, not more. Sure. > Besides, we already require manual intervention for upgrading the Tor > Browser, so why not adding "upgrade the apparmor profile" to those > instructions? Because we also need less manual steps in our dev and release process, not more? :) (Note, in case there was a misunderstanding, that the "upstream" AppArmor profile we're talking of here does *not* live in the Tor Browser Git tree, but in the torbrowser-launcher one.) The main problem I see with this approach is that it requires coordination very late in the release process, between the current release manager, and the ones of us who are best skilled at AppArmor magics. And then, it requires the latter to be available exactly at the right time once the Tor Browser has been updated. Given how we already have a hard time coordinating between the RM and the ones who "run" the manual test suite, I'm unconvinced that we can sanely add one more synchronization point along the way. Now, of course is the RM is skilled enough at AppArmor, everything becomes simpler, but that's not our current situation AFAIK. What do you think? My current preferred solution is: 1. Set up a Git repository forked off upstream torbrowser-launcher's. 2. Set up a daily Jenkins job that tries to merge upstream torbrowser-launcher's master branch into our own one. Have the ones of us who volunteered to maintain our AppArmor profile patch be notified on failure. 3. At ISO build time, download "upstream" profile from Debian *testing* (as opposed to directly from upstream's Git or from Debian unstable), and apply Tails-specific patch. I believe that #1 + #2 should drastically reduce the chances of #3 failing, and most importantly, put us a more relaxed situation whenever it happens: * #3 cannot fail due to upstream changes directly, since we get them proxied from Debian * the people who are most likely to update the torbrowser-launcher package in Debian will be aware when it's going to break the Tails build due to our patch not applying anymore once the package migrates from sid to testing * we have 5 days (migration time) to resolve the merge the conflict on our side, and then import the updated patch as soon as the new torbrowser-launcher package has propagated to Debian testing; granted, there can still be build failures, but the solution will be "merge the branch that has already been prepared", rather than "OMG we have to resolve this merge conflict in a hurry", which should be more relaxed * once we have our own mirror of the Debian APT archive, we can do even better: we'll control exactly when we get the new torbrowser-launcher package, and then we can coordinate it with importing the updated patch, so that no breakage happens at all Good enough? Shall we try that and see? I've implemented #3 already, and can do #1 and #2 for Tails 1.3.1. The main problem with this approach is that if a Tor Browser update requires changes in the AppArmor profile, then our build will be broken until a new torbrowser-launcher is released, uploaded, and then migrates to Debian testing. Once Tor Browser upstream itself ships AppArmor profiles, the situation will be entirely different, though, so hopefully all this discussion is about the current, temporary situation. Cheers! -- intrigeri _______________________________________________ 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].
