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]
