Hi all, Thank you for raising this topic Joris. I do agree with what you propose as I frequently see separate but very much connected issues being opened in PyArrow just for the sake of having a 1-1 relationship (and I do the same) . I feel it adds to a huge number of issues unnecessarily and adds to the noise making it harder to have a good overview.
So yes, +1 from me if this doesn't add too much work to update our current merge workflow (I am also +1 to revisit if we do need the merge script). Best, Alenka V V čet., 12. sep. 2024 ob 19:56 je oseba Rok Mihevc <rok.mih...@gmail.com> napisala: > Perhaps adding a count tag to the PR titles would be useful for such cases? > e.g.: GH-<issue id>: [<PR #>/<expected total # of PRs if known>]<other > tags> <title text> > > Rok > > On Thu, Sep 12, 2024 at 10:37 AM Antoine Pitrou <anto...@python.org> > wrote: > > > > > Hi, > > > > I don't have a specific opinion on this, but as a data point, this > > already happens from time to time (though rarely). > > > > Regards > > > > Antoine. > > > > > > Le 11/09/2024 à 17:32, Joris Van den Bossche a écrit : > > > Hi all, > > > > > > This is a discussion specifically for the GitHub development workflow > > > we use in the monorepo, i.e. https://github.com/apache/arrow/ > > > > > > We have the unwritten(?) (but implicitly implied by our tooling) rule > > > that we always should have one issue for one PR to close that issue. > > > I would like to discuss expanding that to explicitly allow making > > > multiple PRs that link to the same issue. > > > > > > For clarity, I don't want to discuss the usefulness of actually having > > > an issue linked to a PR (we could discuss expanding the scope of our > > > "minor" PRs, but that's for a separate discussion I would say). > > > But in practice, you regularly want to split up the work related to > > > the same topic into multiple PRs (to have smaller PRs, to ease > > > reviewing, etc). At the moment, to follow our workflow, that requires > > > creating a bunch of dummy child issues just to have a unique issue > > > number to reference in each PR. While in practice they could all > > > reference the same issue number. This keeps the relevant information > > > more centralized in that one issue, and avoids the noise of a flood of > > > dummy issues in our issue list. > > > > > > Practical example: currently I am planning to work on adding type > > > annotations to the pyarrow library. I will probably split up that work > > > in a PR per module, but they can all reference a single parent issue > > > instead of also creating an issue about "adding type annotations in > > > module xxx" for each PR. > > > > > > --- > > > > > > I think this is perfectly possible with our current tooling, if we > > > want, with the following notes: > > > > > > - The current merge script will ask you to update (i.e. close) the > > > issue, and at that point if you know this is a parent issue you should > > > say "no" (or afterwards reopen the issue). > > > (we could also discuss whether we actually need this merge script, but > > > let's keep that for another thread? ;)) > > > > > > - The release notes generation currently relies on listing issues, and > > > not PRs. That means if you want the issue listed, it should be closed > > > (and tagged with that milestone) by the time of the release (if it is > > > ungoing work, you can at that point create a new issue for all PRs > > > going into the next release). > > > > > > - If a PR needs to be backported, that also depends on its connection > > > to and the milestone of the issue. Thus, for PRs that need to be > > > backported, you should always open a unique issue and it should not > > > reference an issue tracking multiple PRs. > > > > > > Thoughts? Concerns with allowing this? > > > > > > Best, > > > Joris > > >
