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] > > >
