[cinder] How to post multiple patches.
Alan Bishop
abishop at redhat.com
Tue Apr 13 15:56:37 UTC 2021
On Mon, Apr 12, 2021 at 6:47 PM Jay Bryant <jungleboyj at gmail.com> wrote:
>
> On 4/12/2021 11:18 AM, Brian Rosmaita wrote:
> > On 4/12/21 12:52 AM, 野村和正 / NOMURA,KAZUMASA wrote:
> >> Hi everyone,
> >>
> >> Hitachi has developed the out-of-tree driver as Cinder driver. But
> >> wewant to deprecate the out-of-tree driver and support only the
> >> in-treedriver.
> >>
> >> We need to submit about ten more patches(*1) for full features which
> >> theout-of-tree driver has such as Consistency Group and Volume
> >> Replication.
> >>
> >> In that case, we have two options:
> >>
> >> 1. Submit two or three patches at once. In other words, submit two
> >> orthree patches to Xena, then submit another two or three patches
> >> afterprevious patches were merged, and so on. This may give reviewers
> >> thefeeling of endless.
>
I just want to add that you are not limited to submitting a single batch of
patches in a cycle. If you can get the first batch accepted in Xena, you
are free to submit other batches in Xena. Just continue to bear in mind the
date for freezing driver patches. The bottom line is the sooner you submit
patches and work on resolving reviewer feedback, the sooner you can propose
additional patches.
Alan
>>
> >> 2. Submit all patches at once to Xena. This will give reviewers
> >> theinformation how many patches remains from the beginning, but many
> >> pathesmay bother them.
> >>
> >> Does anyone have an opinion as to which option is better?
> >
> > My opinion is that option #1 is better, because as the initial patches
> > are reviewed, issues will come up in review that you will be able to
> > apply proactively to later patches on your own without reviewers
> > having to bring them up, which will result in a better experience for
> > all concerned.
> >
> > Also, we can have an idea of how many patches to expect (without your
> > filing them all at once) if you file blueprints in Launchpad for each
> > feature. Please name them 'hitachi-consistency-group-support',
> > 'hitachi-volume-replication', etc., so it's easy to see what driver
> > they're for. The blueprint doesn't need much detail; it's primarily
> > for tracking purposes. You can see some examples here:
> > https://blueprints.launchpad.net/cinder/wallaby
> >
> >
> I concur with Brian. I think doing a few at a time will be less likely
> to overwhelm the review team and it will help to prevent repeated
> comments in subsequent patches if you are able to proactively fix the
> subsequent patches before they are submitted.
>
> Thanks for seeking input on this!
>
> Jay
>
> > cheers,
> > brian
> >
> >>
> >> Thanks,
> >>
> >> Kazumasa Nomura
> >>
> >> E-mail:
> >> kazumasa.nomura.rx at hitachi.com<mailto:kazumasa.nomura.rx at hitachi.com>
> >>
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20210413/09bf89ad/attachment.html>
More information about the openstack-discuss
mailing list