If it remains close to a "rename" drop-in replacement, getting rid of the parallel stream could justify merging the 3 branch for 1.0.
On Mon, Apr 17, 2023 at 10:33 AM Matthew Benedict de Detrich <[email protected]> wrote: > 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 <[email protected]> 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 > > <[email protected]> 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 < > > > [email protected]> wrote: > > > > > > > Yep, we will have to change this before this commit to be able to > > merge. > > > > > > > > Matthew Benedict de Detrich <[email protected]> > > 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 < > > > > > [email protected]> 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 > > > > > > <[email protected]> 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 <[email protected] > > > > > > 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 < > > [email protected]> > > > > > > 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, > > > > <[email protected] > > > > > > > > > > > > > > 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 <[email protected]> > > > > > > > > > > > Sent: Friday, April 14, 2023 2:49 PM > > > > > > > > > > > To: [email protected] > > > > > > > > > > > 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 < > > > > > > [email protected]> > > > > > > > > > > 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 < > > > > [email protected] > > > > > > > > > > > > > > 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: > > [email protected] > > > > > For > > > > > > > > > > > > additional commands, e-mail: > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > > > > > For additional commands, e-mail: > [email protected] > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > > > > > 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:* [email protected] > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > To unsubscribe, e-mail: [email protected] > > > > > > For additional commands, e-mail: [email protected] > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > > > > 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:* [email protected] > > > > > > > > > > > > > > > > > > -- > > > > > > 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:* [email protected] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [email protected] > > For additional commands, e-mail: [email protected] > > > > > > -- > > 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:* [email protected] >
