Apologies - where I said `Pekko core release [1]`, I meant to have a different link to a different thread. That link was about the release is:
https://lists.apache.org/thread/xd4wp77bdwyll9243mnd9qc6j4d122kr On 2023/05/29 09:26:57 PJ Fanning wrote: > There was a discussion in the early days about documenting some rules about > how Pekko project work should be done [1]. > > Unfortunately, nobody had time to drive this through to the point where we > had broad agreement and got to the stage where we could host a wiki page. > > There are only a few people very active on the project and they have decided > to concentrate on getting the release done. > > Nothing has been committed without at least 1 other person reviewing it. > > Any change can be reverted, if there is general consensus that it should be > reverted. > > Will we have time to agree and document the processes soon? Possibly not - > the Pekko core release [1] is the tip of the iceberg, we have around a dozen > more sets of modules to release over the coming months. > > We have people waiting on our releases. Most of them are not that concerned > that we don't have a large rulebook. > > I am absolutely not saying that we shouldn't have a rulebook - the issue is > that noone is volunteering to write one. > > > > [1] https://lists.apache.org/thread/0hohnn9v0xhxn0qblb196p7mcq7jzz00 > > On 2023/05/29 08:34:04 PJ Fanning wrote: > > There is no firehose of general development. > > > > There is only 1 goal right now - a v1.0.0 release. > > > > If there is an issue/PR that we don't think fit in 1.0.0 - we have not > > merged the changes. You can find examples if you look in the issues > > and PRs. > > > > We intend to keep this approach until after the 1.0.0 release. > > > > We will create a branch after the release - so the 'main' branch will > > stay as the dev line (probably a future '1.1.0' branch) and a '1.0' > > branch which will be used for future 1.0.1 patch release. The exact > > branching strategy can be agreed in an email thread - what I say here > > is just indicative of the general plan. > > > > On Mon, 29 May 2023 at 08:32, kerr <[email protected]> wrote: > > > > > > I think we can do a first milestone after Scala 3.3.0 / 2.12.18/2.13.12 > > > was > > > officially announced . > > > > > > And Lightbend changed the license on September 7, 2022, so we would better > > > cut a release during next month. > > > > > > 何品 > > > > > > > > > Claude Warren, Jr <[email protected]> 于2023年5月29日周一 14:28写道： > > > > > > > First, there is a misinterpretation of what I am trying to say. I am > > > > not > > > > talking about limiting any contribution by anybody. That is, indeed, > > > > done > > > > by people scratching their itch. > > > > > > > > I am trying to get consensus on what constitutes the milestone. Having > > > > any > > > > developer come in and throw an item in the milestone should not mean > > > > that > > > > it actually is part of the milestone. At this point I am only looking > > > > to > > > > get consensus on what should be in the milestone. Later we can discuss > > > > creating a branch for the release so that additional material is not > > > > added > > > > while testing and final tasks are completed, but that is a different > > > > topic. > > > > > > > > The milestone listed things like: > > > > Automate the release > > > > <https://github.com/apache/incubator-pekko/issues/85> > > > > #85 opened on Jan 5 by pjfanning > > > > > > > > That ticket is no longer in the milestone, and while I agree that it > > > > should > > > > not be there, there was not a discussion to remove it, nor a consensus > > > > reached to do so. That is what I want to see. I want to see consensus > > > > on > > > > what needs to be done for milestone 1 to be attempted as a release. I > > > > want > > > > to see the community come together to form that consensus and I want to > > > > see > > > > immutable documentation that the consensus was achieved. This is part > > > > of > > > > learning the Apache way. > > > > > > > > Now, where can such a consensus be documented? On the mailing list. > > > > Perhaps in other places as well, but the mailing list is where most > > > > Apache > > > > projects do this. > > > > > > > > Where can the discussion of what is or is not included in the milestone > > > > be > > > > undertaken? Certainly not on the git discussions. There is no > > > > reasonable > > > > way to discuss the milestone as an entity on the individual tickets that > > > > comprise the milestone. The discussions on the indivieual tickets are > > > > rightly about the change itself, what needs to be done to complete or > > > > fix > > > > it, different implementation strategies and the like. They inform but > > > > are > > > > not the discussion about the milestone. > > > > > > > > The milestone item as recorded in github [1], does not have any way to > > > > discuss the milestone. So the only place I can see to discuss what > > > > items > > > > go in or come out of the milestone is on the mailing list. Until I > > > > opened > > > > a vote on the items that were already on the list, I had seen no > > > > discussion > > > > of what should be in, no document of consensus. > > > > > > > > Now, the argument that Pekko is somehow special because it is a hard > > > > fork > > > > of an existing project, with lots of people working on it and a > > > > necessity > > > > to get a release out before a specific deadline was reasonable when > > > > trying > > > > to move the entire project into the Apache domain, it will not fly > > > > moving > > > > forward. As my friends in the US South say: "That dog won't hunt". > > > > Pekko has to show that there is consensus. Pekko has to ensure that it > > > > is > > > > easy to find documentation of consensus as the people who will review > > > > the release proposal are volunteers (like everyone else here) with > > > > minimal > > > > time to dedicate to Pekko. Pekko has to show that the _community_ > > > > works. > > > > I would listen to the experienced people who are telling Pekko what > > > > needs > > > > to change. Failure to listen will result in failure of the project. > > > > The > > > > project is more than the code. I recently had a much more experienced > > > > mentor tell me that projects that think they are special generally > > > > fail. I > > > > do not want to see Pekko fail. > > > > > > > > My strategy has been to let the developers and those that understand the > > > > project and how it works drive the development. I have not commented on > > > > what gets developed or migrated. I have asked questions about what > > > > order > > > > things should be done in. I have tried to limit my suggestions to how > > > > to > > > > do things so that they fit within the Apache way. I will continue to do > > > > that. It is up to the PPMC to determine how or if it gets done. > > > > > > > > The IPMC is here to guide projects into the Apache fold. Please listen > > > > to > > > > them, build consensus with them. They will have binding votes on > > > > releases. The Foundation Board is here to make sure that the > > > > overarching > > > > and underpinning structures work and are supportive of projects. They > > > > will > > > > also strive to ensure that projects remain part of the fold. > > > > > > > > We are all volunteers and we are all striving to make Pekko work both > > > > as a > > > > software project and as a community. Let us all try to keep that in > > > > mind > > > > -- not that anyone has forgotten. > > > > > > > > So what do I want to see? I want the Pekko PMC to think about what it > > > > means to do a release? When should the release be cut off from the > > > > firehose of general development and into a more protected state? How > > > > does > > > > the PMC decide what goes in and what does not. How does the PMC show we > > > > have achieved consensus and how do we preserve the evidence of that? I > > > > want > > > > to see proof of consensus about what is going into the milestone. I > > > > want > > > > to see that the Pekko PMC has a process for reaching a consensus and > > > > follows that process. I want to see that process be open and > > > > transparent. > > > > > > > > What do I see as the problem right now? The lack of documentation of a > > > > consensus for what is in and out of the milestone. I don't mean > > > > documentation of the process, I mean evidence that a consensus was > > > > reached. Or, alternatively, a decision that the milestone does not > > > > document what the release will contain but that a different document > > > > specifies what is required for the next release. and a consensus around > > > > what goes in that. Basically, I want to be able to approach the Pekko > > > > project as a new potential contributor, find out what the project is > > > > concentrated on (presumably the next release) and what I can do to help. > > > > All of that starts when the Pekko PMC understands what they are striving > > > > for, and documents that. > > > > > > > > What do I not want to see: voting on every work product as it is > > > > developed. People need to be able to scratch their itch. None of this > > > > should be interpreted to specify what people can work on, nor how the > > > > PMC > > > > approves changes. Though the PMC might want to think about how to > > > > decide > > > > when something does not fit. But that is a discussion for another day. > > > > > > > > Claude > > > > > > > > [1] https://github.com/apache/incubator-pekko/milestone/1 > > > > > > > > On Sun, May 28, 2023 at 11:02 AM Matthew Benedict de Detrich > > > > <[email protected]> wrote: > > > > > > > > > Sorry typo > > > > > > > > > > * Pekko is not a typical greenfield Incubator > > > > > project and it should stop being treated as such as a default unless > > > > > we are breaking some hard ASF rule. > > > > > > > > > > On Sun, May 28, 2023 at 11:59 AM Matthew Benedict de Detrich < > > > > > [email protected]> wrote: > > > > > > > > > > > > I also don't think that things should be added or removed from the > > > > > > milestone without a discussion and vote. > > > > > > > > > > > > Agree with PJ Fanning here, while it is fair that in the normal > > > > > > running > > > > > of > > > > > > an Apache > > > > > > project needing to vote in order to remove/add things from a > > > > > > milestone > > > > > > makes sense, > > > > > > if this was done in Pekko, with the amount of things we need to do > > > > > > it > > > > > > would take years > > > > > > to get the first release done. > > > > > > > > > > > > I get the impression that the assumption of how much work is > > > > > > necessary > > > > is > > > > > > extremely > > > > > > under-estimated. If you want to get a more accurate estimate of how > > > > much > > > > > > is done, > > > > > > have a look at the github contributor page on Pekko's for the most > > > > active > > > > > > committers. > > > > > > > > > > > > > > > > > > Having to require a vote to add/remove things in the current state > > > > > > of > > > > > Pekko > > > > > > as a project, a lot of contributors would get the impression that > > > > > > it's > > > > > > adding > > > > > > bureaucracy/process with no real benefit. Since the current group of > > > > > > committers > > > > > > is quite tight nit (we are talking about former Akka/Scala > > > > > > developers) > > > > > > everyone > > > > > > is in broad agreement of what needs to be done for a release and the > > > > more > > > > > > big > > > > > > ticket contentious issues (i.e. waiting for Scala 3.3 LTS, adding > > > > > inliner) > > > > > > are > > > > > > already being discussed on the mailing list. > > > > > > > > > > > > And even if we did add voting for this, it would largely be > > > > > > pointless > > > > > > because > > > > > > the same few people that are part of the active contributors would > > > > > > just > > > > > > be +1 > > > > > > everything except that we would have to wait a week for any change > > > > > > (for > > > > > the > > > > > > voting to conclude). At this point some people amy bring up "well we > > > > > don't > > > > > > have > > > > > > to wait for a week of voting, it can be lower" and then we get into > > > > > > needless bike > > > > > > shedding arguments wasting even more time. > > > > > > > > > > > > And to be clear here, I am not saying that these things can't change > > > > and > > > > > > the > > > > > > current state of affairs is perfectly healthy, there are definite > > > > issues > > > > > > about > > > > > > sustainability here but our current highest priority is to get a > > > > > > Pekko > > > > > > release > > > > > > out ASAP else we have the risk of it being DOA (dead on arrival) > > > > because > > > > > a > > > > > > large proportion of would-be Pekko users/community have moved on. > > > > > > > > > > > > So for now I would urge that rather than unless strictly necessary, > > > > > > we > > > > > > should > > > > > > refrain from adding new processes before the first release. Instead > > > > > > focusing > > > > > > on *how* we do things, we should focus on *what* the goals are and > > > > > > let > > > > > the > > > > > > process's form organically from the developers. > > > > > > > > > > > > I also have confidence that the PPMC would be more open than typical > > > > > > for a project like Pekko with the context/understanding that Pekko > > > > > > is a > > > > > > hard > > > > > > fork of an existing project (Akka) and because of this it's > > > > > > bringing in > > > > > an > > > > > > already existing, non trivial sized community and its > > > > > > expectations/workflow/processes. Pekko is not a typical greenfield > > > > > > Incubator > > > > > > project and it should stop being treated as such unless as a default > > > > > unless > > > > > > we are breaking some hard ASF rule. > > > > > > > > > > > > On Sun, May 28, 2023 at 10:42 AM Claude Warren, Jr > > > > > > <[email protected]> wrote: > > > > > > > > > > > >> My discussion was not about how to develop or direction for each > > > > > >> issue > > > > > but > > > > > >> whether each issues belongs in the milestone. There is no other > > > > > >> place > > > > > to > > > > > >> discuss the milestone and what goes in it. Since there was not a > > > > > >> lot > > > > of > > > > > >> discussion on the milestone contents I felt that taking a line item > > > > vote > > > > > >> would be good to surface any cases where there were issues with > > > > > >> what > > > > > >> should > > > > > >> be in the milestone. > > > > > >> > > > > > >> I also don't think that things should be added or removed from the > > > > > >> milestone without a discussion and vote. > > > > > >> > > > > > >> > > > > > >> On Sat, May 27, 2023 at 5:58 PM PJ Fanning <[email protected]> > > > > > wrote: > > > > > >> > > > > > >> > I agree with Matthew. I believe the issues should be discussed > > > > > >> > individually in the comments on the issues themselves. > > > > > >> > > > > > > >> > My opinion is that where there are differences in opinions in > > > > > >> > these > > > > > >> > comments and that we need some mechanism to decide on which way > > > > > >> > to > > > > go, > > > > > >> that > > > > > >> > a Vote thread is then useful. > > > > > >> > > > > > > >> > We have already closed off some issues and dropped others from > > > > > >> > the > > > > > >> > milestone. > > > > > >> > > > > > > >> > We are getting close to a release and we are discovering a lot of > > > > > issues > > > > > >> > with the technicalities of making the release. Getting involved > > > > > >> > in > > > > > >> voting > > > > > >> > on all of these issues will slow down the whole process. > > > > > >> > > > > > > >> > On 2023/05/24 15:40:01 Matthew Benedict de Detrich wrote: > > > > > >> > > If we are talking about the milestone generally and voting then > > > > it's > > > > > >> > clear > > > > > >> > > that this can be discussed on the mailing list. I was > > > > > >> > > referring to > > > > > >> > > individual > > > > > >> > > discussion of issues in a milestone which is what I also > > > > > >> > > believe > > > > PJ > > > > > >> > Fanning > > > > > >> > > was referring to. > > > > > >> > > > > > > > >> > > On Wed, May 24, 2023 at 5:28 PM Claude Warren, Jr > > > > > >> > > <[email protected]> wrote: > > > > > >> > > > > > > > >> > > > The milestone itself [1] does not have any way to discuss the > > > > > >> > milestone as > > > > > >> > > > a single entity. There is no place where all discussion > > > > > >> > > > about > > > > > what > > > > > >> > should > > > > > >> > > > go into (or be taken out of) the milestone occurs. Each > > > > > >> > > > ticket > > > > in > > > > > >> the > > > > > >> > > > milestone has its discussion space. But the milestone itself > > > > does > > > > > >> not. > > > > > >> > > > Thus my desire to have discussions about what goes into or > > > > > >> > > > come > > > > > out > > > > > >> of > > > > > >> > the > > > > > >> > > > milestone to be held on the dev list. > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > [1] https://github.com/apache/incubator-pekko/milestone/1 > > > > > >> > > > > > > > > >> > > > > > > > > >> > > > > > > > > > >> > > > > > > > > >> > > > > > > > >> > > > > > > > >> > > -- > > > > > >> > > > > > > > >> > > 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] > > > > > > --------------------------------------------------------------------- > 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]
