+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
> >
>

Reply via email to