> As a compromise, I created another branch similar to Arnout's, which leads to the same outcome but only has a single merge to main commit at the end. AFAICS that will show the history as two parallel lines quite nicely without adding the clutter of the multiple merge commits.
> https://github.com/apache/incubator-pekko-http/compare/main...jrudolph:incubator-pekko-http:scala3-merged-simple?expand=1 This is much better from my side, don't have any objections here. On Thu, Apr 27, 2023 at 2:49 PM Johannes Rudolph <[email protected]> wrote: > We spent quite some effort to keep the extended history of the long > running branch, so it would be a pity to lose all that. > > As a compromise, I created another branch similar to Arnout's, which > leads to the same outcome but only has a single merge to main commit > at the end. AFAICS that will show the history as two parallel lines > quite nicely without adding the clutter of the multiple merge commits. > > > https://github.com/apache/incubator-pekko-http/compare/main...jrudolph:incubator-pekko-http:scala3-merged-simple?expand=1 > > Johannes > > On Thu, Apr 27, 2023 at 1:17 PM Arnout Engelen <[email protected]> wrote: > > > > 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] > > > > --------------------------------------------------------------------- > 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]
