On Tue, May 5, 2020 at 2:20 PM Sebastian Wagner <swagner(a)suse.com> wrote:
Hey Patrick,
Am 05.05.20 um 22:35 schrieb Patrick Donnelly:
Sebastian,
I tried to run the backport-create-issue script:
$ python3 src/script/backport-create-issue 44826
...snip...
project Orchestrator does not have a Backport tracker
and got the above error. It seems batch backports are being done
instead [1] manually. I couldn't find an explanation for this policy
in the email archives. Why is the orchestrator being treated
differently from the rest of the Ceph project?
Right, we've disabled the Backport tracker (temporarily) for the
Orchestrator (mainly cephadm) project.
There were a two reasons for that.
- I'd like to keep master and octopus aligned for now. That's mainly
because cephadm is a fairly new project and a release cycle of one year
is way too large. Taking ceph-volume as an example here, but less
strict. Right now, this would mean a high volume of backport PRs.
- Also, we have a high volume of inter-dependent PRs flowing into
master, which makes it important to keep the order of commits when
backporting to octopus. Unfortunately, our existing backport workflow
doesn't really cope with inter-dependent backport-PRs.
Thanks for the explanation!
That's why I've created my own little script
for creating those
batch-PRs: [2] . It searches in GitHub for cephadm PRs that needs
backporting without duplicating the status of GitHub PRs in the tracker.
Using this little script, I can keep track of all PRs that still need
backporting and maintain the correct order of PRs at the same time.
Are you also closing the "Pending backport" tickets on redmine too?
Still, I'd like to go back to the standard
workflow for backport PRs
eventually, but we're not there yet.
ACK
--
Patrick Donnelly, Ph.D.
He / Him / His
Senior Software Engineer
Red Hat Sunnyvale, CA
GPG: 19F28A586F808C2402351B93C3301A3E258DD79D