> The awesome new template of Gang suggests adding Closes #1234 < https://github.com/apache/parquet-java/pull/2940/files#diff-18813c86948efc57e661623d7ba48ff94325c9b5421ec9177f724922dd553a35R30 > in the PR description. Once the PR goes in, GitHub will automatically close the issue as well.
We use this approach (adding "closes #1234" or "resolved #1234" to the github description) to automatically close the issue in arrow-rs and datafusion and it works very well in my experience. To connect issues to epics / milestones, you can also add text like "relates to #1234" and github automatically makes a back link from #1234 to the PR. Andrew On Wed, Jul 17, 2024 at 3:00 AM Fokko Driesprong <fo...@apache.org> wrote: > Hey Micah, > > Thanks for bringing this up. I'm a big fan of just doing things through > Github. Of course, it is not as customizable as a script, but I think it > can do the job. > > 1. Being able to link each PR to a milestone. This becomes more important > > since the move away from JIRA to Github issues since it allows people to > > understand which release a certain PR belongs to. > > > > With the migration to Github, we also have two milestones > <https://github.com/apache/parquet-java/milestones>. If we assign the > milestones, we can track the PRs through here. I think this is mostly to > indicate what's blocking the release (both issues and PRs). > > 2. Automatic closing of the issue. > > > The awesome new template of Gang suggests adding Closes #1234 > < > https://github.com/apache/parquet-java/pull/2940/files#diff-18813c86948efc57e661623d7ba48ff94325c9b5421ec9177f724922dd553a35R30 > > > in the PR description. Once the PR goes in, GitHub will automatically close > the issue as well. > > 3. Allowing for easily backporting fixes to other release branches. > > > For the last 1.14.1 release, PRs have been created (#1360 > <https://github.com/apache/parquet-java/pull/1360> and #1364 > <https://github.com/apache/parquet-java/pull/1364>) to backport stuff. > This > differs per project, some projects like to have full transparency on what's > being backported, and also create PRs for that. If you ask me, once it is > on the main branch, it is also okay to cherry-pick maintenance branches > without raising a PR. I think this is one part where a script might provide > some more flexibility. > > I think another nice feature that GitHub offers is the releases > <https://github.com/apache/parquet-java/releases>. I just created one for > the Parquet 1.14.1 release > <https://github.com/apache/parquet-java/releases/tag/apache-parquet-1.14.1> > as > an example. You provide two tags (in this case 1.14.1 and 1.14.0) and it > will automatically create the changelog. > > This would also be a good topic to discuss on the sync later today. > > Kind regards, > Fokko > > Op wo 17 jul 2024 om 06:18 schreef Micah Kornfield <emkornfi...@gmail.com > >: > > > I started trying to modernize the merge script in parquet-java [1] and > the > > question came up on whether we want to require using a merge script at > all. > > > > At least for parquet-format I think people have been merging for a while > > using squash and merge. I'm not sure what people are doing for > > parquet-java but given that the script was never upgraded to python3 I > > suspect most people are using github as well. > > > > I think the main benefits a merge script provides are: > > 1. Being able to link each PR to a milestone. This becomes more > important > > since the move away from JIRA to Github issues since it allows people to > > understand which release a certain PR belongs to. > > 2. Automatic closing of the issue. > > 3. Allowing for easily backporting fixes to other release branches. > > > > It is possible that there might be a way to automate some or all of these > > with Github actions (or some other github automation) but I don't have > much > > familiarity with this. > > > > So the main question is should we maintain and require usage of a merge > > script? > > > > If the answer is yes, I'd propose creating a new repo that has just the > > merge script that can be linked into parquet-format and parquet java via > > git submodule. > > > > Thoughts? > > > > Thanks, > > Micah > > > > > > [1] https://github.com/apache/parquet-java/pull/1373 > > >
