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)
I also believe that is the case. > then it would add a huge amount of noise to the git log. > > 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 Personally I'm not too worried about 'noise' in the git log, and think it can be helpful to have it while diagnosing issues using tools other than the GitHub web UI. That said, if it helps moving this feature forward I'm OK with having it squashed as well :). As for the general question of merging before 1.0.x: I'd say the trade-off is between: * merge now: risks incompatibility between akka-http and pekko-http 1.0.x, risks additional maintenance work to support Scala 2.12 and 3 side-by-side * postpone merge: risks discovering problems with supporting 2.x and 3 side-by-side later (post-1.0.x) I think it would be attractive to merge it now, to find any problems as early as possible (preferably before even releasing 1.0.x) Kind regards, Arnout > 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] -- Arnout Engelen ASF Security Response Committer on Apache Pekko Committer on NixOS Independent Open Source consultant --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
