5 May
2020
5 May
'20
11:35 p.m.
Sebastian,
I tried to run the backport-create-issue script:
$ python3 src/script/backport-create-issue 44826
WARNING:root:Missing issues will be created in Backport tracker of the
relevant Redmine project
INFO:root:Redmine key was read from '~/.redmine_key'; using it
INFO:root:Processing issue list ->44826<-
INFO:root:Processing 1 issues with status Pending Backport
INFO:root:https://tracker.ceph.com/issues/44826 skipped because the
project Orchestrator does not have a Backport tracker
INFO:root:Processed 1 issues
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?
[1] https://github.com/ceph/ceph/pull/34438
--
Patrick Donnelly, Ph.D.
He / Him / His
Senior Software Engineer
Red Hat Sunnyvale, CA
GPG: 19F28A586F808C2402351B93C3301A3E258DD79D
6 May
6 May
12:20 a.m.
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.
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.
Still, I'd like to go back to the standard workflow for backport PRs
eventually, but we're not there yet.
Best,
Sebastian
[2]: https://github.com/sebastian-philipp/backport-cephadm-pr
--
SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, 90409 Nürnberg, Germany
(HRB 36809, AG Nürnberg). Geschäftsführer: Felix Imendörffer
12:34 a.m.
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:
Thanks for the explanation!
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. 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
1457
days inactive
1457
days old
2 comments
2 participants
participants (2)
-
Patrick Donnelly -
Sebastian Wagner