The release criteria of “based on meeting quality goals” sounds great. What are those quality goals exactly, and can we objectively measure progress against them?
It looks like we already have a number of well-defined quality goals in https://cwiki.apache.org/confluence/display/GEODE/Release+process <https://cwiki.apache.org/confluence/display/GEODE/Release+process> Presuming this is up-to-date, we need to satisfy 8 required quality goals before we can release. Thus far, we have not met the goal "Build is successful including automated tests”. To meet it, is one “all green" run in the release pipeline <https://concourse.apachegeode-ci.info/teams/main/pipelines/apache-release-1-9-0-main?groups=complete> sufficient? Or should we require 2 or 3 “all green” runs on the same SHA? Do Windows tests count toward “all green”? Currently they are not in the default view (same as 1.8.0). The Geode release process document above also lists an additional 11 quality goals as “optional.” I assume these are meant as suggestions the community may wish to consider when voting on a release? If anyone feels the existing release process documentation does not adequately define what quality goals must be met in order to release, let’s discuss (and get those docs updated!) -Owen > On Mar 1, 2019, at 8:02 AM, Anthony Baker <aba...@pivotal.io> wrote: > > IMHO we start release work based on a quarterly schedule and we finish it > based on meeting quality goals. So right now I’m less worried about when the > release will be done (because uncertainty) and more focused on ensuring we > have demonstrated stability on the release branch. Hopefully that will > happen sooner than 4/1…but it could take longer too. > > Anthony > > >> On Feb 28, 2019, at 6:00 PM, Alexander Murmann <amurm...@apache.org> wrote: >> >> Hi everyone, >> >> According to our wiki we were aiming for a March 1st release date for our >> 1.9 release. We cut the release branch about two weeks late and see unusual >> amounts of merges still going into the branch. I propose that we give >> ourselves some more time to validate what's there. My proposal is to aim >> for last week of March or maybe even week of April 1st. >> >> What do you all think? >
