Hey Micah, That's a good point. I'm happy to formalize the conventions by raising a PR against the parquet website with guidelines where we can hammer out the details.
Kind regards, Fokko Op vr 19 jul 2024 om 23:49 schreef Ryan Blue <[email protected]>: > +1 for using Github options. I think the scripts were mainly intended to do > things that Github does for you. > > On Fri, Jul 19, 2024 at 2:47 PM Micah Kornfield <[email protected]> > wrote: > > > 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 > > <[email protected]> wrote: > > > > > +1 in using stock github > > > > > > On Wed, Jul 17, 2024 at 10:00 AM Fokko Driesprong <[email protected]> > > > 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 < > > > [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 > > > > > > > > > > > > > > > > > -- > Ryan Blue > Databricks >
