Clear quality metrics is definitely great. However, we've also seen in the past that we sometimes find new issues by continue work on the code and some folks starting to use them on their own projects. For that reason, I think it might be wise to give ourselves some extra time to run into issues organically. Maybe we don't need that as our coverage improves.
On Fri, Mar 1, 2019 at 3:24 PM Owen Nichols <onich...@pivotal.io> wrote: > 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? > > > > -- Alexander J. Murmann (650) 283-1933
