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
