geode-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Owen Nichols <onich...@pivotal.io>
Subject Re: 1.9 release date
Date Thu, 28 Mar 2019 19:51:52 GMT
The daily trigger was inadvertently lost when the 1.9.0 release branch was re-cut.  I’ve
just restored it.

> On Mar 1, 2019, at 4:33 PM, Owen Nichols <onichols@pivotal.io> wrote:
> 
> Definitely makes sense to have some soak time, as it appears we just reached “code
complete” this morning.
> 
> I would love to see the automated tests in the release pipeline run at least once a day
for a couple weeks to help surface any new issues from the recent flurry of changes.  If no
one objects, I will go ahead and add a “daily” trigger to that pipeline.
> 
> -Owen
> 
>> On Mar 1, 2019, at 4:10 PM, Jason Huynh <jhuynh@pivotal.io> wrote:
>> 
>> To Alexander's point, I'm use the latest geode snapshot and am seeing an
>> issue that looks similar to (if not the same as) GEODE-3780 (but this one
>> is closed).
>> I'd like to explore this a bit more and decide if that should be reopened
>> but I am not sure if it's not an issue important enough to wait for.
>> 
>> I think some soak time would be nice but I can understand that it's not a
>> clear criteria.
>> 
>> On Fri, Mar 1, 2019 at 3:57 PM Sai Boorlagadda <sai.boorlagadda@gmail.com>
>> wrote:
>> 
>>> I started working on LICENSE issues.
>>> 
>>> On Fri, Mar 1, 2019 at 3:55 PM Anthony Baker <abaker@pivotal.io> wrote:
>>> 
>>>> I’ll point out that the license issue I mentioned earlier this week isn’t
>>>> resolved.  And that we’re bundling potentially incompatible Jackson jars.
>>>> 
>>>> Anthony
>>>> 
>>>> 
>>>>> On Mar 1, 2019, at 3:41 PM, Alexander Murmann <ajmurmann@gmail.com>
>>>> wrote:
>>>>> 
>>>>> 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 <onichols@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 <abaker@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 <amurmann@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
>>>> 
>>>> 
>>> 
> 


Mime
View raw message