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 <[email protected]>: > 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 >
