On Fri, Mar 15, 2019 at 02:25:24PM +0100, Alexey Tikhonov wrote:
> > +1 for separate PRs for backports (for CI checks)
> Do you think it would be acceptable for whoever pushes the patch to
> master to also create the backport PR?
It depends on who decides if patch should be backported at all.
Anyone can propose a patch to be backported, but normally this is driven
by downstreams.
If PR author is pretty sure patch needs to be backported, then why
not?
But it is good to link those PRs so the person who makes review of one
of PRs would be aware about second.
Yes, that seems like an overhead, but what would be the other way to
run CI tests (taking into an account we are planning to stop using
internal CI at all)?
> Otherwise I'm worried that backports might always be delayed. I try to
> push patches in the evening so that the internal CI processes the
> patches overnight. If we require the same developer who opened the PR
> against master to also open the PR against a stable branch, then there
> would be a day of delay..
Sorry, not sure if I understood.
What is the source of "day of delay"? And is it delay you worry about?
Yeah, I don't think we understood each other.
What I'm proposing is:
- you submit PR for master
- I review it and push to master, close the original PR
- I also apply the patches locally to sssd-1-16 and open another PR
- if the backport PR passes CI, I also push it
The delay I didn't like was:
- you submit PR for master
- I review it and push to master, close the original PR
- ..then I ask you to open a sssd-1-16 PR
I don't think the second way is needed because frankly I wouldn't do any
more review then checking the CI boxes are green.
The second way is applicable if the PR does not apply cleanly and needs
some rework.