On Thu, Nov 15, 2018 at 12:53 PM Alfredo Deza <adeza@xxxxxxxxxx> wrote: > > On Thu, Nov 15, 2018 at 3:49 PM Patrick Donnelly <pdonnell@xxxxxxxxxx> wrote: > > > > On Thu, Nov 15, 2018 at 6:01 AM Lenz Grimmer <lgrimmer@xxxxxxxx> wrote: > > > > > > On 11/15/18 6:40 AM, Gregory Farnum wrote: > > > > > > > I think part of the problem domain here isn't just bugs that > > > > deliberately take up multiple PRs, but bugs where the first fix is > > > > incorrect or incomplete and needs to be amended by a later patch. > > > > > > Well, but that would deserve getting tracked in a separate issue > > > (flagged as "regression" and referring to the original issue), wouldn't it? > > > > Yes, absolutely! And the backports for the original issue should be > > blocked by the fix for the follow-up issue. This should be strictly > > managed by the PTL for the respective project. > > > > I'm 100% against having multiple PRs in a single issue. It just makes > > things more confusing. It's lazy software engineering and we shouldn't > > enable it. > > In the case of ceph-volume, I may have misrepresented our way of > linking issues. It is not that we are not creating issues for > each defect and slapping regressions onto the old issue, it is that we > add the backport PR links as comments, hence the question if it > was possible to add more than 1 link. > > Not that it should stop this from moving forward, we can workaround it > or improve it in some other way. I'd recommend using the related/blocking issue feature instead of linking to another PR. It makes more sense and it doesn't present an ambiguous situation to the backporter (why is this second PR linked? was there a problem with the first PR or is this just a follow-up enhancement? etc.). -- Patrick Donnelly
