Hello!

There is two ways to ship security fixes to packages:

1. Update to a patched version if upstream provides one
2. Apply or backport individual patches to fix the issues in the
shipped version

Grafts are most reliable for 2. but there's cases where using 2. is
lots of work and we can't afford that right now. An example is
ImageMagick where not all security issues get a CVE so essentially the
only way of getting security fixes is to fetch master or get the latest
release.

There's also some types of packages where we are not sure whether we
can use grafting or not, such as Python ones.

For these reasons, I would like to propose a new branch called
security-updates that would be based on master where we queue security
fixes that introduce any arbitrary number of rebuilds without using
grafts.

We would merge the security-updates branch as soon as there is complete
substitute availability for the branch and it's future merged version
within master.

The downsides of this approach are that:

1. Substitutes availability does not mean we can ship the updates
quickly because this might mean hundreds of megabytes if not gigabytes
of new substitutes to fetch to actually get the update.
2. Users that don't use substitutes will suffer big rebuilds on each
security update shipped through this branch.

For these reasons, grafting should still be preferred when possible,
but there are cases where it cannot be used for technical reasons or
lack of resources reasons but we still must provide a fix quickly.

What do you think?

Léo