Just to close on this, I'll go ahead and delete the merge script and we'll try to use github workflows, we can always reassess the process at some later point.
On Tue, Jul 23, 2024 at 1:09 PM Julien Le Dem <jul...@apache.org> wrote: > The merge script existed originally because The ASF only allowed merging in > the apache git repo and the github repo was just a read-only mirror. > Now that this is not the case anymore, I am also in favor of just using > github. > > On Mon, Jul 22, 2024 at 3:40 AM Fokko Driesprong <fo...@apache.org> wrote: > > > Hey everyone, > > > > I've raised two PRs to update the way of working for contributing > > <https://github.com/apache/parquet-site/pull/76> and releasing > > <https://github.com/apache/parquet-site/pull/78>. Let me know what you > > think. > > > > Kind regards, > > Fokko > > > > > > Op za 20 jul 2024 om 00:03 schreef Fokko Driesprong <fo...@apache.org>: > > > > > 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 > <b...@databricks.com.invalid > > > >: > > > > > >> +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 < > emkornfi...@gmail.com> > > >> 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 > > >> > <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 > > >> > > > > > > >> > > > > > >> > > > > >> > > > >> > > >> > > >> -- > > >> Ryan Blue > > >> Databricks > > >> > > > > > >
