+1
On Thu, Feb 28, 2019 at 6:25 PM Owen Nichols wrote:
> This would eliminate a lot of noise from Windows tests, any objection to
> cherry-picking it to release/1.9.0?
>
> This is a test-only change.
>
> Thanks,
> -Owen
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 wi
+1 to prioritizing quality over releasing on the desired cadence. The
quarterly release cadence is a good goal, but it shouldn't be a strict rule
if there is more work to be done to ensure good quality.
Ryan
On Fri, Mar 1, 2019 at 8:02 AM Anthony Baker wrote:
> IMHO we start release work based
What Anthony said. +1
> On Mar 1, 2019, at 8:02 AM, Anthony Baker 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 o
I think this is exactly the right balance. Yay!
--
Mike Stolz
Principal Engineer, GemFire Product Lead
Mobile: +1-631-835-4771
On Fri, Mar 1, 2019 at 11:48 AM Ryan McMahon wrote:
> +1 to prioritizing quality over releasing on the desired cadence. The
> quarterly release cadence is a good goa
The fix for GEODE-6468 has been merged into release/1.9.0
On 2/28/19 5:10 PM, Sai Boorlagadda wrote:
+1 for merging this fix to release/1.9.0 as this is required for the
NIO related changes that are already merged.
On Thu, Feb 28, 2019 at 4:47 PM Bruce Schuchardt
wrote:
This is another ticke
I am aligned here that we should not be firm on a date be flexible to get a
more stable release out.
But could someone explain to me how would we measure this stability? The
pipelines are green
and the community members have cherry-picked all issues that were critical.
Unless we have some process
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+pr
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
or
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 wrote:
>
> Clear quality metrics is definitely great. However, we've also seen in the
> p
I started working on LICENSE issues.
On Fri, Mar 1, 2019 at 3:55 PM Anthony Baker 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, Alexand
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 fo
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 obje
13 matches
Mail list logo
