Hi, Simon Deziel: > I think we ended up with the current situation because merge > proposals in apparmor-profiles are not reviewed quickly enough > (and/or I'm not patient enough).
Understood! But that should not be a blocker, see below. > On 2017-09-03 03:01 AM, intrig...@debian.org wrote: >> I see two options to fix this confusing situation. >> >> A. Use lp:apparmor-profiles as the upstream [...] >> B. Use Simon's repository as the upstream [...] > I'm OK with A and wouldn't mind sending any new rules to the official > repo. Excellent, thanks a lot :) > My only concern is what to do when those new rules are stalled > waiting on review? Could they be integrated to the Debian version while > waiting for the official merge? If yes, I think that's the best of both > worlds. For the record I generally don't wait for upstream to review'n'merge before I apply fixes to AppArmor policy in Debian packages I maintain: the "upstream first" moto does matter to me, but in practice I define it as "submit upstream first and then upload to Debian" rather than as "wait for upstream to ACK my proposed changes before fixing the problem our users are complaining about". So yeah, I think we can definitely have the best of both worlds :) Now, wrt. Thunderbird specifically: so far, AFAIK the maintainers of src:icedove in Debian haven't bothered taking stuff from upstream's apparmor-profiles.git directly. Instead, they are kind enough to apply any reasonable update we (= mostly Ulrike, but I'm sure she would not mind if you and I gave her a hand) ask them to take. So I would suggest we forward them any update we think should go in Debian, as soon as we've submitted it upstream, without waiting for upstream to review. Now, let's keep in mind that these changes will go straight to Debian *stable* in the next security upload — if I'm not mistaken). So perhaps a little bit of peer-review would be in order. For example, assuming one of us three sends a merge request to Launchpad, as soon as any of the other two ACKs it, we ask the src:icedove maintainers to take it. I.e. we piggy pack on the existing upstream review process and tools and save some paperwork. Deal? Cheers, -- intrigeri
