If the milestone is placed in the snapshot area it is not a release. I strongly recommend that Pekko seriously consider making the milestone a release and plan to work through a number of release candidates to get the process ironed out.
There are a number of issues that have been identified with respect to how to do the release process. Things like a full automation of the process is putting the cart before the horse. You can't know what to automate until you know what to do. So let's agree what goes into RC1, get those issues resolved and document a step-by-step release for RC1 as it is done. When complete and reviewed we will have issues that will require another RC. Now you can probably automate some steps. Others will require human intervention. What we want to see here is not perfection, we want to see the process being built. We want to bring first hand knowledge of the tricks and pitfalls of the release process to a wider community. We want to get some packaging out for review by the IPMC. Claude On Tue, May 23, 2023 at 11:56 AM Matthew Benedict de Detrich <[email protected]> wrote: > > (i.e. first release after a hard work) > > This is meant to say "(i.e. first release after a hard fork)" > > On Tue, May 23, 2023 at 12:53 PM Matthew Benedict de Detrich < > [email protected]> wrote: > > > > 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] > > > > > -- > > 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] >
