Re: [eclipse.org-architecture-council] Postmortem Release Path

[Mickael Istria <mistria@xxxxxxxxxx>]

Hi,

TL;DR: the review process is more than an IP check.

On Wed, May 30, 2018 at 7:50 PM, Jesse McConnell <jesse.mcconnell@xxxxxxxxx> wrote:

* project checks itself to make sure everything is in their iplog

* project builds out their release and publishes it, in the case of Jetty into Maven Central

* project then pushes to Wayne links to all published binaries, in Jetty's case its Distribution

* Wayne diligently downloads and checks the release binary for IP cleanliness and it either gets a yellow or a green mark.  

* if Green means everything is good and no further review is necessary, skip to end and profit

* if yellow it triggers a mandatory postmortem review process to address the issue, most likely Wayne isn't able to link together an actual binary to its IP approved self, or there needs to be an expedited CQ review to get something green

* If someone screwed up and included something wrong wrong wrong in the release binaries then it is time to get it fixed and notice pushed to their mailing lists, mea culpas, etc etc

I think this removes some value compared to the current process, which is not only about IP:

The review docuware on PMI is actually a critical part of the governance. For small and immature projects which do not have skills in communicating around achievements, the documentation that's requested for (non-service) releases forces them to summarize work, added value and plans for the project. It's vital that a project does this and the sooner the better. So while it's indeed extra-steps and time-consuming, forcing it is part of the added-value Eclipse Foundation brings to the project compared to some other forge without governance. I believe in research for instance, the reason why project join the Foundation is more for this kind of practices that improve success of the project than for IP reasons. So to me, removing the review doc removes a lot of value to the release process.

That said, I'd love to see more parts of it generated, for example with some community metrics pre-filled in the form or dynamically computed, relying on metrics from the dash projects. I would love to see the content of the review generated more and more automatically, but not to see the review removed.

> project builds out their release and publishes it, in the case of Jetty into Maven Central

Instead of publishes, I would say "stages" it.

Staging like having it available for testing and even adoption but not promoted as latest yet. It's relatively easy to do so with Maven (either creating a dedicated staging repo to deploy like Tycho does, or -for the luckiest- using a Nexus Pro with staging included).

Once a project is staged, releasing in upon approval is usually a one-click effort.

And the good news is that if we replace "publishes" by "stages", then this is already allowed and projects can stage their release binary long before the review takes place.

> project then pushes to Wayne links to all published binaries, in Jetty's case its Distribution

I don't think in the current form, the binaries are strictly assumed as being the core artifacts in term of IP and all. The review process mostly validates the source during the IP Log validation, not so much the binary. If there is no binary check, then what you suggest here is 1 extra-step to the current process.

But I may be wrong, and that's a good quesion: does the current review process validates anything against the binaries?

> Wayne diligently downloads and checks the release binary for IP cleanliness

That may be technically impossible.

--

Mickael Istria

Eclipse IDE developer, for Red Hat Developers