[pkg-apparmor] Bug#888244: apparmor: Convert quilt patch series to per-topic subdirectories managed by gbp-pq

[intrigeri]

Hi,

Simon McVittie:
> On Wed, 24 Jan 2018 at 09:23:16 +0100, intrigeri at debian.org wrote:
> I also use a version of this for dbus and the bubblewrap/ostree/flatpak
> group of packages. The difference in those packages is that I use
> "topic 1.2.3" for patches that have been successfully upstreamed and
> were released in 1.2.3 or are expected to be released in a future 1.2.3;
> the empty topic contains patches that have been sent upstream (or could
> in principle be sent upstream) but have not been accepted or rejected yet.

> For packages where you stay close to upstream that's perhaps unnecessary
> complexity, but I've found it useful with upstreams where Debian is unable
> to follow the latest upstream releases (like policykit-1), and for dbus
> packages in a Debian derivative where I was following the upstream stable
> branch but importing a few large features from the development branch.

Interesting idea. I think we stay close enough to upstream in
src:apparmor to hopefully not need that and I'm not sure we are in
a good position to benefit from the main pro I see:

 - advantage: when importing a new upstream release (say, 2.12.1), we
   can simply drop all patches from the 2.12.1 topic;

 - drawback: we're back to having to maintain the "have been
   successfully upstreamed and were released in 1.2.3 or are expected
   to be released in a future 1.2.3" vs. "not sent or
   accepted/rejected upstream yet" information. We've not been good at
   it so far and if we don't get this right, the aforementioned
   advantage vanishes in great part.

But I'll definitely keep this idea in mind. It can be useful later, be
it for this package or another one :)

> One more thing that I'd suggest: sort the patch series by "closest to
> upstream", upstreamed patches < upstreamable patches < Debian-local
> changes < derivatives' changes, so that rebasing on a new upstream
> consists of dropping a prefix of the patch series (and replacing it with
> a new upstream that already contains those commits), and upstreamable
> patches have the maximum chance of being directly applicable upstream and
> not becoming entangled in downstream changes. apparmor in Debian has not
> historically done this: Debian- and Ubuntu-specific patches come before
> upstreamed and upstreamable patches, which always seemed strange to me.

Absolutely. I didn't mention it in my proposal but I planned to do
that in the PoC branch. This being said, how do you do that in a gbp
pq workflow? Is it merely a matter of manually ensuring all
debian/master..patch-queue/debian/master commits are in the right
order? I guess we could add a check for that in debian/rules but
perhaps the gbp pq workflow provides a better way to guarantee
that ordering?

Thanks for your valuable input!

Cheers,
-- 
intrigeri