hi, bertagaz wrote (25 Jan 2015 12:14:21 GMT) : > While I think I could help with maintaining this profile when it breaks > the build, I'm not much comfortable with this option from my CI hat point > of view. It means that every devs would be notified of this breakage if/when > automatic builds will be deployed. I can see the mailbombing coming, and > devs and contributors ranting on the list.
I hear this concern. Thankfully it won't happen often, with two Debian torbrowser-launcher maintainers now committed to keep an eye on this before uploading new versions. Also note that we're already doing #1 for 5 files in /etc/apparmor.d/, by the way (see config/chroot_local-patches/apparmor-*). > If #1 is chosen, we could maybe have a dedicated jenkins jobs to test if > our Tails specific patches don't apply. ... and make this job a blocker of the automated ISO builds? Seems sensible at first glance. Whenever the patch can't be applied automatically, I guess the torbrowser-launcher/AppArmor people among us will be notified, as opposed to tails-dev@. Still, in this case we'll probably need a way for other tails-dev@ people to be aware that the rest of our ISO CI process is stalled, blocking on the Tor Browser profile patch to be repaired. Any idea how this can be conveyed? Can we have e.g.: * tails-dev@ notified once when the patch job fails, and once when it becomes stable again * torbrowser-launcher/AppArmor folks notified every time the patch job fails (just like tails-dev@ is currently notified every time an automated ISO build fails) ? > Maybe we could also make this build time automatic merge being less > destructive for the build: if the merge doesn't work, the build goes on > but notify that the apparmor profile is out of sync, and that the > torbrowser is probably broken. It seems to me that this would open a painful can of worms: we'll then have known-broken, 2nd class autobuilt ISOs, that will break automated tests and can't be used for some use cases we currently have for these ISOs. I'd rather avoid that. Either it builds successfully, or it doesn't. Anything in between is just too complicated (both conceptually and technically) and thus painful to deal with IMO. > So I'm not firmly opposed to #1, and I dislike #2, but would prefer #1 to > be a bit more gentle. Agreed. Cheers, -- intrigeri _______________________________________________ Tails-dev mailing list Tails-dev@boum.org https://mailman.boum.org/listinfo/tails-dev To unsubscribe from this list, send an empty email to tails-dev-unsubscr...@boum.org.