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