Also its not like consensus isn't being reached about what goes into a milestone and what doesn't, just a few days ago we were discussing about how to deal with the json framing problem and whether this should be included or not (see https://github.com/apache/incubator-pekko/pull/44)
Also regarding voting what goes into milestones and what does, as far as I can tell this is not the norm for Apache TLP's. Kafka for example does not do this, the committers of Kafka generally decide on what goes into a milestone and what doesn't (which is exactly how we are operating) and if there are any issues then it gets raised in the mailing list/github issues (which is also what we are doing). While I get the sentiment behind fostering a community, again I think we should refocus on this being organic and organic can also mean completely different to what you are used to. I will also say that if there are processes being suggested that a non negligible amount of Apache TLP's do not follow then it's going to be an incredibly hard battle to fight because the impression this gives off to the Pekko community is that rather than there being some hard rule we are instead having unfamiliar processes being pushed onto us. On Mon, May 29, 2023 at 10:34 AM PJ Fanning <[email protected]> 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] > > -- 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]
