Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [eclipse.org-architecture-council] Postmortem Release Path

Jesse,


Thanks for sending this. It is a big email and I want to make sure I get the point. So, if you will permit me to ask a naive question: Why is this better than the current process?


To be precise and in keeping with your analogy, I don't want to ever get on a plane that was allowed into the air without a pre-flight check since statistics suggest in that case a Postmortem Review would be exactly what happens next! ;-) I might argue that the same is true with the software I use. My question therefore breaks down to:

* What does this give us that is functionally better than the current process?

* Does it preserve the spirit of the current process?


Again, thanks for this. Very thought provoking.


Jay


Jay Jay Billings
Team Lead, Scientific Software Development
Oak Ridge National Laboratory
Twitter Handle: @jayjaybillings

From: eclipse.org-architecture-council-bounces@xxxxxxxxxxx <eclipse.org-architecture-council-bounces@xxxxxxxxxxx> on behalf of Jesse McConnell <jesse.mcconnell@xxxxxxxxx>
Sent: Wednesday, May 30, 2018 1:50 PM
To: eclipse.org-architecture-council@xxxxxxxxxxx
Subject: [eclipse.org-architecture-council] Postmortem Release Path
 

I had a thought for an alternative approach to the whole release process discussion we had on the last call and wanted to see if it would spark some discussion.

First off, I think we should approach things from the basic belief that projects want to follow the spirit of the IP process and make their decisions based on the belief that everything they are using or referencing exist in their IP Log.

The current Release Review process is more of a pre-flight check for an actual release that should, but doesn't actually _have_ to, maintain adhereance to the IP log, mistakes can happen .  I got the sense from the last call that some projects were approaching each release as something demanding full review each time and others double down on the bugfix release process bypassing much of the official release and only checking in with that process on minor version bumped (1.4.x -> 1.5.x, etc).

I propose the addition of a post-release review process path, the Postmortem Review. Something like this:

* 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

A couple of key points, the primary one being that Wayne can, and in many cases already has been, replaced by a series of small highly talented shell scripts (or python or perl, dunno).  I remember him having this ability to run something against a binary and get a sanity check out of it from an IP perspective, he did it against our downloads directory a number of times.  Ideally, a project would have the ability to trigger this review against an arbitrary list of urls to get their little green checkmarks for a given release.  If it goes yellow then Wayne the human has to get involved.  Given proper access to the tooling the projects could run it themselves to sanity check their own output.

It would be neat if this could be extended out into the project management tooling as well, I will say right now that I am terrible about updating the project-settings.xml file that we have somewhere that is supposed to contain information about various releases.  That file has precious little of interest to our project so it gets updated once in a blue moon.  Now if it was the place that we could put those links to file to review, or if the output of Wayne the script could be deterministic and we could preemptively put in a link in there that would make it clear that a release had passed the automated release review postmortem there is now a reason for me to go update that file or the general project metadata on a more regular basis.

A process like this would suit the continuous release folks better as well I would think and it could eventually be expanded to review published maven pom files if so inclined.

cheers,
Jesse

--
jesse mcconnell
jesse.mcconnell@xxxxxxxxx

Back to the top