> 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.
No one here is suggesting any kind of automation, this was already clear months ago. > What we want to see here is not perfection, we want to see the process being built. I don't think we are even at a stage where perfection is even a thought, the current discussions we have are just the basics of making an artifact. For example unless you specifically setup your host system to have multiple JDK's installed at once, Pekko will not even build because it relies on java.misc.unsafe. This is why there is a Docker image, which while not strictly required makes it easier/simpler and even more importantly for other committers to verify the release. Also I would like to point out/remind that even though making a source package release is important for Apache, it's useless for Pekko's users. It's been stated many times on the mailing list that the people actually using Pekko ultimately only care about the maven binary jars (i.e. 1.0.0 release) and that a lot of potential contributors are waiting for that 1.0.0 maven jar binary release. The ironic thing here is that we already have a method of creating proper artifacts, it's just done by github actions CI which doesn't adhere to Apache's processes for a release and that is an example of what's making it more complicated (otherwise we could have been pushing RC's weeks/months ago). On another note, while it's definitely true that we should strongly encourage getting a release out sooner than later, in my view arbitrary checkboxing of some process doesn't do anyone any favors (whether it's Apache, IPMC or Pekko users). On Tue, May 23, 2023 at 1:55 PM Claude Warren, Jr <[email protected]> wrote: > 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] > > > -- 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]
