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

[Jesse McConnell <jesse.mcconnell@xxxxxxxxx>]

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.

Which is why I offer it as an alternative as opposed to a replacement.  Point being, for a project doing continuous delivery the idea of following the current process is a problem.  Current process makes sense if you have big multifacated releases happening a couple of times a year where you can diligently track all the amazing features you are releasing and bundle it all up nice for review.  Not all projects work that way.  Continuous release enables you to push out a bugfix today and a useful QoL feature tomorrow.  These are not all Service releases in the traditional sense, at least by the definition I understand so going through the traditional release review process represents undue burden on the project.  

Ultimately, I am interested in our recommending the addition of a process to the EDP that can more accurately capture the reality of what some projects are trying to do whilst respecting the core tenets of the Eclipse Foundation which I firmly believe are rooted in demonstrable clean IP policy.  All software foundations advocate processes that help make projects successful but the Eclipse Foundation is the only one that I am aware of that has a team of lawyers backing up and reviewing contributions and dependencies to ensure IP cleanliness.

cheers,

Jesse