Re: [Xen-devel] tags in backport commits

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 13.06.17 at 00:19, <sstabellini@xxxxxxxxxx> wrote:
> I think we should discuss and agree on a set of tags to use in our
> backports to stable trees.
> 
> Specifically, I would like to see a tag that specifies the id of the
> original commit, like "master commit" that Jan is using today. I would
> prefer if the tag didn't have any spaces, thus, I suggest
> master-commit-id or upstream-commit-id (that's what I use in the
> qemu-xen trees because it wouldn't be clear what "master" is in that
> context). Whatever is chosen should be documented under docs.

I'm not opposed to replacing the space I use with a dash. I don't
think though an "-id" tag would be overly useful, but if everyone
else thinks it is, so be it.

> Moreover, I think we should start using tags in our staging commits
> which specify to which trees a given commit should be backported to as
> soon as it passes the push gate.

But that's already a possibly controversial aspect: Some backports
better don't happen immediately, so the tagging shouldn't be tied
to when the backport is to occur, and hence ...

> I suggest to use something similar to
> the Linux kernel:
> 
>   CC: stable@xxxxxxxxxxxxxx [4.2+]
> or
>   CC: stable@xxxxxxxxxxxxxx # 4.2+
> 
> But anything else that allows us to specify a range of stable trees
> would be fine by me. This is the first step toward backport automation.

... I'm not convinced this will help much with backport automation
(which I'm not convinced is a good idea anyway - the risk of build
breakage in particular is just too high if no human intervention is
intended at all anymore before pushing to the respective stable
trees).

Furthermore - who would you mean to create these tags? In the
end I think it should be the person responsible for the respective
parts of the stable trees to decide if and how far such backports
ought to occur, so neither the person submitting the patch nor
the person committing the patch are in the position to give more
than a hint here (again speaking against using such tags for
automation).

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
https://lists.xen.org/xen-devel