Cool ,thanks! 何品
PJ Fanning <fannin...@apache.org> 于2025年1月9日周四 19:57写道： > I would like to press on with a Pekko Connectors 1.1.0 release. I can be > the release manager unless someone else wants to take this on. > > > On 2024/11/19 20:46:03 PJ Fanning wrote: > > I think it would be great to get more people involved in the Pekko > > community. There are a couple of active contributors who we should be > > considering adding as committers. Publicising Pekko is good for the > > community. > > > > I don't believe though that we should delay releases because we might > > get more reviewers for releases. I am involved in numerous ASF > > projects, including being active in the Incubator project. Few if any > > reviews come from outside the committer/PMC/PPMC base. It would be > > great if this was not the case but this is just a statement of my > > experience. > > > > With milestones and RCs and even snapshots - I see very few users ever > > testing these. Most users appear to wait until some tool like > > Dependabot or Scala Steward prompts them about new releases. > > > > I don't think we have a serious problem with our releases introducing > > bugs. There have been some issues but I think we are balancing the > > needs of being cautious about changes while also trying to respect the > > fact that contributors want to see their changes released. > > > > I believe that users have a responsibility to test software updates in > > a non-production environment. This is even more important for major > > and minor releases than for patch releases. > > > > It has been over a year since the 1.0.0 release and I think it is > > important to release 1.1.0 to upgrade all the out of date > > dependencies. > > > > > > > > > > On Mon, 18 Nov 2024 at 18:51, Matthew de Detrich <mdedetr...@gmail.com> > wrote: > > > > > > > I don't see the point in a milestone release. We have received little > > > to no feedback on milestone releases. I'm not against milestones when > > > they are justified but I don't think we have a case here. > > > > > > This is because the milestone releases have never been publicized > > > outside of the official Apache mailing list channels which to be blunt > > > it seems like most of the Pekko users aren't reading. Personally I > > > have only announced non milestone releases on other public channels > > > (twitter, reddit etc etc) and given where we are now I think this is a > > > mistake, milestones should also be announced there so that people are > > > aware of it and are incentivized to use it. > > > > > > > All things being equal, a milestone release is only worth it if it > > > saves us *two* regular releases: if it saves us only one regular > > > release it will be merely "the same amount of work", as creating a > > > milestone release is the same amount of work as creating a regular > > > release. > > > > > > Historically this hasn't been the case, granted as has been pointed > > > out people are not that aware of milestones but I gave my reasons just > > > before. Ideally people would treat -RC's seriously and properly test > > > it before we make an actual release, but due to the short timeframe of > > > 2 days I see that happening even less likely than someone properly > > > testing a milestone before a future release. > > > > > > Also it's quite typical for software projects to use milestones like > > > this, the suggestion isn't an outlandish one. While people are free to > > > test snapshots, it's not the same because it's not uncommon to put > > > broken stuff into main and then have a future PR to fix it so while > > > using a snapshot in a production and/or pre-production system is > > > usually not a good idea (and many organizations would completely > > > disallow it), using a milestone is more tolerable because of the > > > implicit understanding of a milestone (milestones still have to go > > > through a proper release schedule and a milestone is only released at > > > a point in time that as far as maintainers are aware is the software > > > is in a releasable state). > > > > > > I don't want to block the RC of pekko connectors just for this, but I > > > am putting it out there that anxiously rushing a release like this has > > > caused us issues before, and the issue is not that we decide to make a > > > release and vote on it but rather that almost all of pekko users are > > > unaware of the existence of -RC releases. Honestly a 2 day timeframe > > > for an -RC is way too short to do proper testing of pekko especially > > > with our current eagerness to +1 RC's. Unless there is a CVE (which is > > > its own process), we should have the ability to leave Pekko in a state > > > that is at least a week so that users can do proper testing and most > > > importantly that **users are aware of it**. > > > > > > Whether that is extending an RC time window to something along the > > > lines of 1 week (which has its own issues), or using milestones or to > > > be more prudent in allowing a +1 release (likely not going to cut it > > > at the current stage of Pekko), I think we should properly think about > > > this and I am also trying to be pragmatic here. > > > > > > On Mon, Nov 18, 2024 at 5:06 PM PJ Fanning <fannin...@gmail.com> > wrote: > > > > > > > > I don't see the point in a milestone release. We have received little > > > > to no feedback on milestone releases. I'm not against milestones when > > > > they are justified but I don't think we have a case here. > > > > > > > > On Mon, 18 Nov 2024 at 16:22, Arnout Engelen <enge...@apache.org> > wrote: > > > > > > > > > > All things being equal, a milestone release is only worth it if it > > > > > saves us *two* regular releases: if it saves us only one regular > > > > > release it will be merely "the same amount of work", as creating a > > > > > milestone release is the same amount of work as creating a regular > > > > > release. > > > > > > > > > > So far I don't get the impression they are helping us: we have 3 > pekko > > > > > core patch releases *despite* having had a milestone release. I'm > not > > > > > optimistic promoting the milestone more would improve that > > > > > significantly - and having to promote every milestone release does > > > > > create additional work. > > > > > > > > > > I would love anything we can do to catch bugs earlier and to make > > > > > releases more lightweight. > > > > > > > > > > While my preference is for a 1.1.0, if someone wants to RM a > milestone > > > > > release that's OK with me as well. > > > > > > > > > > > > > > > Kind regards, > > > > > > > > > > Arnout > > > > > > > > > > On Mon, Nov 18, 2024 at 2:39 PM Matthew de Detrich < > mdedetr...@gmail.com> wrote: > > > > > > > > > > > > > People can already test snapshots (and the current milestone) > > > > > > > > > > > > People are unfortunately not doing this (as is evidenced with > what > > > > > > happened with Pekko core with the cluster concurrent race > condition), > > > > > > and afaik the milestone is quite behind in terms of the > dependencies > > > > > > we have updated. If a M2 milestone is done then I would > advertise it > > > > > > in all of the relevant channels to make sure its as public as > > > > > > possible. > > > > > > > > > > > > I think we need to seriously re-evaluate and have a long term > view on > > > > > > how we do releases, both in terms of milestones (i.e. whether to > use > > > > > > them or not) and how we make this visible. Its actually wasting > more > > > > > > of our time rushing out full releases and then having to fix > easily > > > > > > caught bugs amd then do another release, we are already on the > 3rd > > > > > > patch release of pekko core because of this. > > > > > > > > > > > > On Mon, Nov 18, 2024 at 1:48 PM Arnout Engelen < > enge...@apache.org> wrote: > > > > > > > > > > > > > > I think we should trust our automated tests and do a full 1.1.0 > > > > > > > release rather than another milestone. > > > > > > > > > > > > > > People can already test snapshots (and the current milestone), > I'm not > > > > > > > optimistic we get significantly more testing out of releasing > an M2. > > > > > > > The overhead of releasing a milestone is identical to the > overhead of > > > > > > > releasing a full version. If we don't find issues, a milestone > would > > > > > > > have caused unnecessary delay, and if we do find issues, > fixing them > > > > > > > in a bugfix release is no more work than first having a > milestone. > > > > > > > > > > > > > > While I'm in favour of splitting out the monorepo long-term, > I'm not > > > > > > > sure we're ready for that yet. It's already tricky to find > enough > > > > > > > people to RM and verify/vote releases, splitting out the > monorepo will > > > > > > > make that problem worse. I'd say we should first take some > more steps > > > > > > > to make the release process more lightweight before starting > to split > > > > > > > repos. > > > > > > > > > > > > > > > > > > > > > Kind regards, > > > > > > > > > > > > > > Arnout > > > > > > > > > > > > > > > > > > > > > On Mon, Nov 18, 2024 at 9:29 AM Matthew de Detrich < > mdedetr...@gmail.com> wrote: > > > > > > > > > > > > > > > > Also the other reason why I would suggest a milestone rather > than a > > > > > > > > full 1.1.x release right now is that for 1.2.x I would > actually > > > > > > > > recommend that we start splitting out the monorepo, as is > evident its > > > > > > > > starting to cause a lot of issues due to its big bang have > to release > > > > > > > > everything at once. > > > > > > > > > > > > > > > > On Mon, Nov 18, 2024 at 9:03 AM Matthew de Detrich < > mdedetr...@gmail.com> wrote: > > > > > > > > > > > > > > > > > > Can we do a milstone release as an alternative? We have > been in this > > > > > > > > > place before and the obvious solution was a milestone > release. In fact > > > > > > > > > with so many critical dependency updates (as you rightly > mention) and > > > > > > > > > the fact that connectors is a massive monorepo this really > does call > > > > > > > > > for a milestone for people to actually test that the > various > > > > > > > > > connectors are working before doing a full release. > > > > > > > > > > > > > > > > > > On Thu, Nov 14, 2024 at 2:10 PM PJ Fanning < > fannin...@apache.org> wrote: > > > > > > > > > > > > > > > > > > > > I am anxious to do a Pekko Connectors 1.1.0 release. > There are significant dependency updates since 1.1.0-M1 - including CVE > fixes like CVE-2024-7254. > > > > > > > > > > > > > > > > > > > > It also blocks use from releasing the 1.1.0 versions of > Pekko Persistence Cassandra, Pekko Projections and Pekko Persistence R2DBC. > > > > > > > > > > > > > > > > > > > > There is no issue tracking the new auth strategy. We > have no users waiting for it. > > > > > > > > > > > > > > > > > > > > We can always do a 1.2.0 or 1.1.1 release when we have > the additional auth strategy. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2024/10/16 08:57:13 Matthew de Detrich wrote: > > > > > > > > > > > > Would it be possible to proceed with the 1.1.0 > release based on what's > > > > > > > > > > > already committed. We can always do a 1.1.1 release > when your additions are > > > > > > > > > > > made. > > > > > > > > > > > > > > > > > > > > > > The issue is that according to SemVer, 1.1.x is for > new features and so it > > > > > > > > > > > makes sense to do this in 1.1.x since it is adding an > entire auth strategy. > > > > > > > > > > > I already did some work on it but it is taking longer > than normal, there > > > > > > > > > > > isn't a need to rush through a release as people can > always use the > > > > > > > > > > > milestone if needed (or we can do a M2 if there is a > critical need for it) > > > > > > > > > > > > > > > > > > > > > > On Tue, Oct 15, 2024 at 1:23 PM PJ Fanning < > fannin...@apache.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > Hi Matthew, > > > > > > > > > > > > > > > > > > > > > > > > Would it be possible to proceed with the 1.1.0 > release based on what's > > > > > > > > > > > > already committed. We can always do a 1.1.1 release > when your additions are > > > > > > > > > > > > made. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On 2024/10/09 14:05:11 Matthew de Detrich wrote: > > > > > > > > > > > > > So I did want to add in one feature to > pekko-connectors before its > > > > > > > > > > > > > released, wanted to work on it this weekend. > Basically its added service > > > > > > > > > > > > > account auth compatibility to google cloud which > is a problem that I am > > > > > > > > > > > > > experiencing at work. > > > > > > > > > > > > > > > > > > > > > > > > > > Otherwise the current state of pekko-connectors > looks fine to me > > > > > > > > > > > > > > > > > > > > > > > > > > On Wed, Oct 2, 2024 at 11:45 AM PJ Fanning < > fannin...@apache.org> wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > > Hi everyone, > > > > > > > > > > > > > > > > > > > > > > > > > > > > The last major change needed for the Pekko > Connectors 1.1.0 release is > > > > > > > > > > > > > > to get Pekko gRPC 1.0.0 released and uptaken in > the Connectors repo. > > > > > > > > > > > > > > The gRPC release vote is in progress. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Most of the changes were in 1.1.0-M1 release > [1]. Some additional > > > > > > > > > > > > > > changes are listed in the GitHub Milestone [2]. > > > > > > > > > > > > > > > > > > > > > > > > > > > > Does anyone have any objections to doing this RC > next week? Does > > > > > > > > > > > > > > anyone want to take on the release manager role? > > > > > > > > > > > > > > > > > > > > > > > > > > > > Thanks, > > > > > > > > > > > > > > PJ > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > [1] > > > > > > > > > > > > > > > > > > > > > > > > > > > https://pekko.apache.org/docs/pekko-connectors/1.1/release-notes/releases-1.1.html > > > > > > > > > > > > > > [2] > https://github.com/apache/pekko-connectors/milestone/7 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > -- > > > > > > > Arnout Engelen > > > > > > > ASF Security Response > > > > > > > Apache Pekko PMC member, ASF Member > > > > > > > NixOS Committer > > > > > > > Independent Open Source consultant > > > > > > > > > > > > > > > --------------------------------------------------------------------- > > > > > > > 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 > > > > > > > > > > > > > > > > > > > > > -- > > > > > Arnout Engelen > > > > > ASF Security Response > > > > > Apache Pekko PMC member, ASF Member > > > > > NixOS Committer > > > > > Independent Open Source consultant > > > > > > > > > > > --------------------------------------------------------------------- > > > > > 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 > > > > > > > > > > --------------------------------------------------------------------- > > > 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 > > > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@pekko.apache.org > For additional commands, e-mail: dev-h...@pekko.apache.org > >
