> I think that it is time to start to take a hard look at a release candidate. I do not expect the release candidate to succeed, however, there is a lot to be learned in the failure.
Our current strategy is to release a MILESTONE which should hopefully happen this week. This is because doing a RC is more problematic due to how difficult it is to build Pekko outside of CI (with a MILESTONE we can release it under Apache Snapshots Repo) > I think we should start by determining if there are items that are not required for the release and items that are missing. I am opening two issues today that I will add to the milestone. They are the addition of the LICENSE and NOTICE files to the snapshots, under the assumption that doing so will also add them to the release. FYI this has already been done for all Pekko modules, the core logic of doing so is abstracted in https://github.com/mdedetrich/sbt-apache-sonatype. Every single Pekko repo contains the relevant LICENSE, NOTICE and DISCLAIMER files both in the source dist package and also in the maven jar convenience package > 1. do not work on a change without a ticket. This can be considered somewhat unnecessary with regards to how github works, more specifically a PR in github **is a ticket** and since we use github for both pull requests and tickets this distinction can be considered somewhat arbitrary. On a related note, the reason why people worked on features without creating issues first is simply due to velocity. If we had to go through a formal process we would have achieved a fraction of what we have done currently. I would suggest the most appropriate time to introduce new process would be after the first release, not now. Its already been both communicated and demonstrated multiple times that the current development process of Pekko is highly tailored to the unique scenario we are in (i.e. first release after a hard work) and that it does need to change, but doing so now in my opinion would introduce a real risk of slowing things down which is the exact opposite of what we want to do now. > 2. make sure the ticket is associated with the milestone. This is already being done, at least for tickets/pull requests that are relevant to a milestone. See https://github.com/orgs/apache/projects/ and https://github.com/apache/incubator-pekko/milestones > 3. when you are working on a ticket, assign it to yourself. If you can not assign it to yourself, post a note on the dev mailing list with a subject prefix of [ACCESS] noting the ticket that you do not have access to and then add a comment to the ticket indicating that you are working on it. Github doesn't allow you to assign tickets if you are not a maintainer (which for Apache projects means comitter). I have noted in the past that we need to be a lot better about assigning in general (this has been noted multiple times) however I will raise the some points raised in response to point number 1 here. > 4. any change that is not a simple break/fix should be discussed in the dev mail list with the subject prefix of [DISUCSS]. What is the mentality behind this? I strongly disagree with making such a rule, we shouldn't be preventing people from making contributions even if they are not focused on the current milestone/release candidate. I don't have any issue in freezing the repository during a release process but this is one step too far. Its especially damaging in the case of Pekko because since we have made an agreement that version 1.0.x doesn't introduce new features, people have been making pull requests for new features over time with the expectation they will get merged later. Such a rule send a very negative signal to potential contributors. On Tue, May 23, 2023 at 12:38 PM Claude Warren, Jr <[email protected]> wrote: > Greetings, > > > I think that it is time to start to take a hard look at a release > candidate. I do not expect the release candidate to succeed, however, > there is a lot to be learned in the failure. > > There is a milestone [1] currently open. Let's take that and work toward > the release candidate. > > I think we should start by determining if there are items that are not > required for the release and items that are missing. I am opening two > issues today that I will add to the milestone. They are the addition of > the LICENSE and NOTICE files to the snapshots, under the assumption that > doing so will also add them to the release. Let's clean the list and then > concentrate on only those items that will get us to RC1. So let's hold a > vote on the items in the current milestone and see if they all need to be > in release 1.0 > > In this process we will need to ensure that everyone is communicating what > they are doing. So, I think we should do the following: > 1. do not work on a change without a ticket. > 2. make sure the ticket is associated with the milestone. > 3. when you are working on a ticket, assign it to yourself. If you can > not assign it to yourself, post a note on the dev mailing list with a > subject prefix of [ACCESS] noting the ticket that you do not have access to > and then add a comment to the ticket indicating that you are working on it. > 4. any change that is not a simple break/fix should be discussed in the > dev mail list with the subject prefix of [DISUCSS]. > > We should also be looking on the dev list for offers of assistance and > point them to the milestone first. We need to develop standard operating > procedures that are welcoming to new contributors. > > [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]
