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