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
