> No one here is suggesting any kind of automation, this was already clear months ago.
I just checked the github milestone/project and I realized there are still a lot of automation tickets there. This should have been removed some time ago, so I can see how this caused confusion. Since Claude has already created a vote on this we can manage it there. On Tue, May 23, 2023 at 2:31 PM Matthew Benedict de Detrich < [email protected]> wrote: > > 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] > -- 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]
