My only concern here is it seems to rely on convention rather than mechanisms. If there are no other comments on the matter I'll delete the merge scripts for now and we can see how a github only process works out and revise accordingly.
Thanks for the discussion. Cheers, Micah On Wed, Jul 17, 2024 at 1:42 AM Alkis Evlogimenos <alkis.evlogime...@databricks.com.invalid> wrote: > +1 in using stock github > > On Wed, Jul 17, 2024 at 10: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 > > > > > >
