My current objection stems from how many merge commits the PR has (see https://github.com/apache/incubator-pekko-http/pull/130), I haven't done a merge in Github UI for a while but if these remain in the git log after the merge commit (which I believe is the case) then it would add a huge amount of noise to the git log. As Arnout pointed out in the PR, he can remove these but it would take quite a bit of work as well as potentially creating a regression.
Also in case people are not aware, as long as a git commit references a PR from Github, Github will store the branch/commits from the PR indefinitely so you can always view the original PR to see precise commits/attribution. This was also pointed out earlier when we were deciding on linear history (fun fact, you can directly search the github UI with a commit reference resulting from a squash/rebase and it will show you the entire git log before the squash/merge). On Sun, Apr 16, 2023 at 2:00 PM PJ Fanning <fannin...@gmail.com> wrote: > I think it is fair to treat this as an exception and do allow a merge > commit for this. > > On Sun, 16 Apr 2023 at 12:58, Matthew Benedict de Detrich > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > My preference is for a squash commit with the Co-Authored-Tag (which as > > stated before would be automatic) but that's because personally I value > > linear history much more strongly. In addition to the Co-Authored tag, > more > > accurate/clear attribution can also be done within the > > squash commit message (i.e. main/original implementation done by X, fixes > > to work with newest version done by Y etc etc). > > > > On Sun, Apr 16, 2023 at 12:53 PM Johannes Rudolph < > > johannes.rudo...@gmail.com> wrote: > > > > > Yep, we will have to change this before this commit to be able to > merge. > > > > > > Matthew Benedict de Detrich <matthew.dedetr...@aiven.io.invalid> > schrieb > > > am > > > So., 16. Apr. 2023, 12:42: > > > > > > > > We should do a real merge commit here and not do any rebasing or > > > > squashing in this case to preserve the history and attribution as it > > > > is. > > > > > > > > I don't think this is possible because we have enforced linear > history > > > for > > > > all Pekko repos but squash/rebase does preserve attribution via the > > > > Co-Authored tag (see > > > > > > > > > > > > https://docs.github.com/en/pull-requests/committing-changes-to-your-project/creating-and-editing-commits/creating-a-commit-with-multiple-authors > > > > ). > > > > By default if you do a squash/rebase on Github's web UI it will > > > > automatically add in the Co-Authored tags if it sees that there are > > > > multiple commits from different authors. > > > > > > > > The main downside here is the loss of granularity particularly when > > > doing a > > > > squash (i.e. you specifically lose which commits were done by whom). > > > > > > > > On Sun, Apr 16, 2023 at 12:18 PM Johannes Rudolph < > > > > johannes.rudo...@gmail.com> wrote: > > > > > > > > > I support merging now/soon for pekko 1.0.x. It introduces some > extra > > > > > maintenance burden especially to support 2.12 and 3 at the same > time. > > > > > On the other hand, the most risky parts that the branch introduces > for > > > > > Scala 2.x support have already been merged with the move to the > latest > > > > > upstream parboiled2 version. Maintaining the branch longer will > only > > > > > become more difficult. I will hopefully have another look at the > state > > > > > of the branch next week, but I think it should be in good shape. We > > > > > should do a real merge commit here and not do any rebasing or > > > > > squashing in this case to preserve the history and attribution as > it > > > > > is. > > > > > > > > > > Johannes > > > > > > > > > > On Sat, Apr 15, 2023 at 11:17 AM Matthew Benedict de Detrich > > > > > <matthew.dedetr...@aiven.io.invalid> wrote: > > > > > > > > > > > > So regarding this proposal specifically of merging the scala3 > branch > > > > into > > > > > > pekko-http main I am all for it. The risk is low and if there > are any > > > > > > potential issues its better we find them out now rather than > later > > > > > > considering its for a 1.0.x release. There are also performance > fixes > > > > > which > > > > > > we should reintroduce which have been removed when we moved to > > > upstream > > > > > > Parboiled2 > > > > > > > > > > > > > Granted you likely don't care all that much about what one > consumer > > > > > > thinks, > > > > > > but i wouldn't be surprised if others are in similar situations. > > > > > > > > > > > > > We're in a similar situation to Dave here. Do you have an > > > indication > > > > > for > > > > > > how long is left on the scala3 pekko-http support? > > > > > > > > > > > > I wouldn't be so rash, we actually care a lot about the users > (or at > > > > > least > > > > > > I do). The biggest problem we are experiencing is there is a lot > of > > > > > factors > > > > > > at play which are causing tensions. For example the original > plan was > > > > to > > > > > > make Pekko 1.0.0 as close as possible to Akka 2.6 BSL with no > > > > behavioural > > > > > > changes but when then realized there were changes which would be > for > > > > the > > > > > > better of the community. One example of such change is updating > > > Jackson > > > > > > (due to CVE's) which also forced us to upgrade from Scala 3.2. > > > > > > > > > > > > Then there are other factors at play such as Scala 3.3, there are > > > > > extremely > > > > > > strong arguments by many people (including Scala center/EPFL) > that > > > > Pekko > > > > > > should target Scala 3.3 since its a LTS. The core of the bind > here > > > > really > > > > > > is binary compatibility/stability. If we release Pekko 1.0.0 > with a > > > > > Scala 3 > > > > > > version, we are likely going to be stuck with that version for a > > > LOOONG > > > > > > time considering that we made an agreement that only > CVE's/critical > > > > fixes > > > > > > will be backported to 1.0.x branch. My personal overview of the > > > > situation > > > > > > is that at least technically speaking (i.e. aside from the > > > > > > license/header/legal issues) there isn't much to do. There is a > > > project > > > > > > with a brief overview of what needs to be done at > > > > > > https://github.com/orgs/apache/projects/220/views/1 so I would > say > > > as > > > > a > > > > > > very broad estimation there is probably 1-2 months of work which > > > should > > > > > > also line up well with a Scala 3.3 LTS release (that is expected > this > > > > > > month). There is also > > > > https://github.com/apache/incubator-pekko/pull/281 > > > > > > which we should make a discussion on, I will create a discussion > > > thread > > > > > for > > > > > > this. > > > > > > > > > > > > On a tangential note, a discussion should probably be made about > the > > > > > > evolution of the Pekko project in general wrt binary > > > > > > compatibility/stability. At the heart of these problems is the > > > > > expectation > > > > > > of extreme binary compatibility that is inherited from Akka and I > > > think > > > > > > there is merit in exploring whether such expectations is the > > > healthiest > > > > > for > > > > > > the project in general (i.e. should they be loosened a bit?). > > > > > > > > > > > > On Sat, Apr 15, 2023 at 1:33 AM Greg Methvin <gr...@apache.org> > > > wrote: > > > > > > > > > > > > > I support this proposal. Scala 3 support is something most > people > > > > want > > > > > in a > > > > > > > Scala library these days, so having it would make the 1.0.0 > release > > > > > feel > > > > > > > more complete, especially for new users. It would also allow > > > library > > > > > > > authors to publish new releases using the Scala 3 artifacts as > soon > > > > as > > > > > > > possible. > > > > > > > > > > > > > > The only real concern is how much it would delay the release. > If it > > > > did > > > > > > > cause a delay, I imagine we could put out a milestone release > with > > > > > > > everything except the Scala 3 support, to give people a chance > to > > > > start > > > > > > > migrating earlier? > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, Apr 14, 2023 at 8:37 AM PJ Fanning < > fannin...@gmail.com> > > > > > wrote: > > > > > > > > > > > > > > > incubator-pekko release is not dependent on anything in > > > > > > > > incubator-pekko-http. The original discussion has nothing to > do > > > > with > > > > > core > > > > > > > > pekko. incubator-pekko will be released when they are ready. > > > > > > > > incubator-pekko-http will be released separately, some time > later > > > > > when it > > > > > > > > is ready. If you want to discuss incubator-pekko, please > start a > > > > new > > > > > mail > > > > > > > > thread. > > > > > > > > > > > > > > > > On Fri 14 Apr 2023, 17:27 Sam Byng, > > > <samb...@microsoft.com.invalid > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > We're in a similar situation to Dave here. Do you have an > > > > > indication > > > > > > > for > > > > > > > > > how long is left on the scala3 pekko-http support? > > > > > > > > > > > > > > > > > > The positives on our side are that we don't have to wait > for > > > > pekko > > > > > > > 1.1.0 > > > > > > > > > to get pekko-http, and it makes further releases of > connectors > > > > etc > > > > > > > > simpler. > > > > > > > > > However, negatives would be the possible extension of 1.0.0 > > > date. > > > > > So > > > > > > > far, > > > > > > > > > looking at the MR it seems that adding pekko-http scala3 > > > support > > > > > is not > > > > > > > > far > > > > > > > > > off so wouldn't extend the 1.0.0 release too dramatically. > > > > > > > > > > > > > > > > > > -Sam > > > > > > > > > > > > > > > > > > > -----Original Message----- > > > > > > > > > > From: Dave Brosius <mebigfat...@gmail.com> > > > > > > > > > > Sent: Friday, April 14, 2023 2:49 PM > > > > > > > > > > To: dev@pekko.apache.org > > > > > > > > > > Subject: Re: [DISCUSS] adding pekko-http scala3 support > now > > > for > > > > > > > v1.0.0 > > > > > > > > > release > > > > > > > > > > > > > > > > > > > > As a future simple consumer of Apache Pekko, i'd would > love > > > > > anything > > > > > > > > > that gets a published release sooner than later as our > > > corporate > > > > > > > > governance > > > > > > > > > is on our necks about using akka (even the > last o/s > variant) > > > > > because > > > > > > > of > > > > > > > > > the license change. We have 1 year from the announcement > (sept > > > > > 23) to > > > > > > > > > resolve. > > > > > > > > > > > > > > > > > > > > Granted you likely don't care all that much about what > one > > > > > consumer > > > > > > > > > thinks, but i wouldn't be surprised if others are in > similar > > > > > > > situations. > > > > > > > > > > > > > > > > > > > > On Wed, Apr 12, 2023 at 5:54 AM Nicolas Vollmar < > > > > > nvoll...@gmail.com> > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > I assume overall there weren't any (major) changes to > public > > > > > APIs for > > > > > > > > > > Scala 3, so merging it for 1.0.0 would be a small risk, > but > > > > also > > > > > > > > > > reduce burden of maintaining the branch and allow to ship > > > > Scala 3 > > > > > > > > > > support across the board with 1.0.0. I'd +1 that. > > > > > > > > > > > > > > > > > > > > On Tue, 11 Apr 2023 at 13:26, PJ Fanning < > > > fannin...@apache.org > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > Hi, > > > > > > > > > > > > > > > > > > > > > > I'd like to pitch the idea of just merging the > pekko-http > > > > > scala3 > > > > > > > > > > > support to main branch when it is ready and including > this > > > in > > > > > the > > > > > > > > > v1.0.0 release. > > > > > > > > > > > We have already made small-ish changes like using > Parboiled > > > > > jar and > > > > > > > > > > > upgrading Jackson. > > > > > > > > > > > > > > > > > > > > > > The scala3 changes don't make significant changes to > the > > > APIs > > > > > and > > > > > > > it > > > > > > > > > > feels > > > > > > > > > > > like adding the scala3 support now would not make > migration > > > > > from > > > > > > > > > > > Akka > > > > > > > > > > HTTP > > > > > > > > > > > much harder. Akka HTTP has released scala3 support (BSL > > > > > licensed) > > > > > > > > > > > but the release seems to have gone smoothly - without > much > > > > user > > > > > > > > > complaint. > > > > > > > > > > Nothing > > > > > > > > > > > significant had to be documented about the migration to > > > Akka > > > > > HTTP > > > > > > > > > > > 10.4 > > > > > > > > > > [1]. > > > > > > > > > > > > > > > > > > > > > > My main reason for supporting an early merge of this is > > > that > > > > it > > > > > > > will > > > > > > > > > > > save us a whole circle of releases downstream. A scala3 > > > > support > > > > > > > > > > > pekko-http > > > > > > > > > > > v1.1.0 would lead to new releases for pekko-connectors > and > > > > > other > > > > > > > > > > downstream > > > > > > > > > > > projects. > > > > > > > > > > > > > > > > > > > > > > I get that we want to make migration to v1.0.0 easy > but I > > > > don't > > > > > > > > > > > think the > > > > > > > > > > > scala3 changes make this significantly harder. > > > > > > > > > > > > > > > > > > > > > > If we had made faster progress with the v1.0.0 release > then > > > > > being > > > > > > > > > > > conservative probably makes sense but now that we still > > > don't > > > > > have > > > > > > > a > > > > > > > > > > > release scheduled, it feels like we might be better off > > > > > planning to > > > > > > > > > > > get a slightly bigger v1.0.0 release done and saving > > > > ourselves > > > > > the > > > > > > > > > > > hassle of having to do a v1.1.0 release for the scala3 > > > > changes. > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc. > > > > > > > > > > akka.io > > > > > > > %2Fdocs%2Fakka-http%2Fcurrent%2Fmigration-guide%2Fmigration-gui > > > > > > > > > > de-10.4.x.html%23general-notes&data=05%7C01%7Csambyng% > > > > > > > 40microsoft.com% > > > > > > > > > > > > > > > > > > > > > > 7C84d3391cb35f40598c2908db3ceefd85%7C72f988bf86f141af91ab2d7cd011db47% > > > > > > > > > > > > > > > > > > > > > > 7C1%7C0%7C638170769415330544%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwM > > > > > > > > > > > > > > > > > > > > > > DAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdat > > > > > > > > > > > > > > > a=9kKrhjPaZVGmWaV%2FPcF%2BygzMZjd%2BzXwNpCIuQxyD%2FcY%3D&reserved=0 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -------------------------------------------------------------------- > > > > > > > > > > > - To unsubscribe, e-mail: > dev-unsubscr...@pekko.apache.org > > > > For > > > > > > > > > > > additional commands, e-mail: dev-h...@pekko.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > > > > > > > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > Matthew de Detrich > > > > > > > > > > > > *Aiven Deutschland GmbH* > > > > > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > > > > > > > *m:* +491603708037 > > > > > > > > > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > > > > > > > > > > > --------------------------------------------------------------------- > > > > > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > > > > > For additional commands, e-mail: dev-h...@pekko.apache.org > > > > > > > > > > > > > > > > > > -- > > > > > > > > Matthew de Detrich > > > > > > > > *Aiven Deutschland GmbH* > > > > > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > > > > > *m:* +491603708037 > > > > > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > > > > > > > > > > > > > -- > > > > Matthew de Detrich > > > > *Aiven Deutschland GmbH* > > > > Immanuelkirchstraße 26, 10405 Berlin > > > > Amtsgericht Charlottenburg, HRB 209739 B > > > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen > > > > *m:* +491603708037 > > > > *w:* aiven.io *e:* matthew.dedetr...@aiven.io > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > For additional commands, e-mail: dev-h...@pekko.apache.org > > -- Matthew de Detrich *Aiven Deutschland GmbH* Immanuelkirchstraße 26, 10405 Berlin Amtsgericht Charlottenburg, HRB 209739 B Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen *m:* +491603708037 *w:* aiven.io *e:* matthew.dedetr...@aiven.io
