Hi, Rosmaita and Bryant, Alan, Thanks for your advices. I will do it that way. Kazumasa Nomura On Mon, Apr 12, 2021 at 6:47 PM Jay Bryant <jungleboyj@gmail.com<mailto:jungleboyj@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<https://secure-web.cisco.com/1ZmxdQeHI4BdBsz4BVH6-MlaDOO3BRS2B_HjC7kvwLl7WxXgim79ZbpCWZi6Hz3nG0AU0_ZIiWyF1G2E5enmw7KsI37EWTEYvXSMFSMDCCAJBnYcVcqlLUD6BW92-qQRnTd-IbbsGdC3-OyDLeL2J-_GwYCN5n_IPwvcap0HyUt2NRzlebad32kxllx1j9CpIHTju4VzLj0LfrczaElPU5ghtFkD3v3l7z5Y3muH9VJB2qv8S5KcGA2Y7DmIkmB0OqbQBdHd8LW7pVZCREFH2Vr46roZ75Ae2FgREmgF6UDC73KkhCjUYN_mi8yTGWyR7K1DgN-EJ41NdVMYnj6Fqxw/https%3A%2F%2Fblueprints.launchpad.net%2Fcinder%2Fwallaby>
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@hitachi.com<mailto:kazumasa.nomura.rx@hitachi.com><mailto:kazumasa.nomura.rx@hitachi.com<mailto:kazumasa.nomura.rx@hitachi.com>>