Re: [DISCUSS] etiquette around breaking the pipeline

[Ju@N]

I'm in favour of quick reverts as well.
Even though a failure might seem easy to fix at a first glance, experience
has proven otherwise in many cases, so quickly reverting the offending
commit seems the right thing to do.
Whom should revert the offending commit?, I'd say the first person that
detects the failure... It should, of course, be communicated to the
originator of the PR so he/she can work towards solving the problem and
submit a new PR afterwards. In my opinion nobody should be offended by a
revert, as long as the person reverting the commit
communicates empathetically and helps the originator of the PR to
understand what was wrong, why it was reverted and, how can be solved (if
needed).
Maybe it's just me, but I'd feel more offended if my commit is breaking the
pipeline and preventing other community members from continue working
normally, than if somebody just reverts the bad changes I introduced.
Cheers.

On Thu, 30 Apr 2020 at 05:18, Owen Nichols  wrote:

> Hi Mark, I’ve noticed some voluntarily quick reverts, which is awesome,
> but other times CI has stayed broken for days, so it doesn’t feel like
> we’re all on the same page.  I cannot find anything in the wiki or dev list
> archives to suggest this was “settled” previously, but please share a link
> if I missed something.  Consensus that "quick reverts are good” sounds
> nice, but the details of who can notice and initiate the revert make a
> difference (do we really expect every contributor to stare at CI for the
> next 10 hours after their PR is merged?).
>
> > On Apr 29, 2020, at 8:12 PM, Mark Hanson  wrote:
> >
> > As far as I am aware, I think this is already a settled decision. The
> decision was quick revert.
> > In almost every case the build is more important than the change.
> >
> > Thanks,
> > Mark
> >
> >> On Apr 29, 2020, at 4:14 PM, Robert Houghton 
> wrote:
> >>
> >> I am very pro-revert for breaking changes. The Benchmark or Windows
> tests
> >> being a culprit is unfortunate, since the PR pipeline cannot tell us
> about
> >> those, but thats the cost of our excellence :)
> >>
> >> On Wed, Apr 29, 2020 at 4:06 PM Owen Nichols  > wrote:
> >>
> >>> There are many ways a commit can break the Geode CI pipeline[1] despite
> >>> our required PR checks, such as:
> >>> - merge a PR that failed some non-required PR checks
> >>> - merge a PR that last ran checks awhile ago and now interacts
> >>> unexpectedly with other recent changes
> >>> - merge a PR that fails Windows tests
> >>> - merge a PR that fails Benchmarks tests
> >>>
> >>> When a bad commit gets through for whatever reason, what should happen
> >>> next?  For example:
> >>> - bring it up on the dev list
> >>> - someone should revert the change as soon as possible, allowing the
> >>> pipeline to remain green while the issue is addressed
> >>> - a reasonable amount of time should be allowed for someone to make a
> >>> quick fix, otherwise revert.
> >>> - the pipeline should remain broken for as long as it takes to fix, as
> >>> long as there is clear communication that someone is working on it
> >>> - everyone look the other way and hope it fixes itself
> >>>
> >>> I’m sure there are other ideas as well.  A related question is *who*
> can
> >>> or should revert a bad commit?  Only the person that merged the PR?
> Only
> >>> the original author of the PR?  The first person to notice the problem?
> >>>
> >>> What is a reasonable amount of time for this to happen?  2 hours? 2
> days?
> >>> 2 weeks? Does it depend whether the bad commit is also affecting PR
> checks
> >>> for everyone else vs only depriving downstream consumers of new Geode
> >>> -SNAPSHOTs?
> >>>
> >>> Would you take offense if someone else reverted your commit?  Does is
> make
> >>> a difference if your commit is exposing an existing issue (as opposed
> to
> >>> introducing a new bug)?
> >>>
> >>> Is there a perception that reverts create a lot of extra work? (they
> >>> shouldn’t--just start your rework PR with a revert of the revert, then
> add
> >>> additional commits that resolve the issue, so reviewers can easily see
> what
> >>> was missing the first time)
> >>>
> >>> This is a discussion thread, not a vote.  We trust committers to do
> what’s
> >>> best.  Would embracing a “anyone can revert, no shame”
> >>> revert-first-then-fix culture benefit our community, or is our current
> >>> easygoing approach working just fine?
> >>>
> >>> [1]
> >>>
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-develop-main&data=02%7C01%7Chansonm%40vmware.com%7C631cbe6f65c14bbb030108d7ec931267%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C637237988725318710&sdata=2ecuh535cj7G9i8STCT32zyunsnrcupg4c8dowrGwvo%3D&reserved=0
> <
> https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fconcourse.apachegeode-ci.info%2Fteams%2Fmain%2Fpipelines%2Fapache-develop-main&data=02%7C01%7Chansonm%40vmware.com%7C631cb

Request for Apache Geode release management permissions

[Dave Barnes]

This is a request for bulk modification permissions and admin permissions on 
the Geode project.
Thanks,
Dave Barnes
dbar...@apache.org 

Re: Request for Apache Geode release management permissions

[Owen Nichols]

You should have that now.  Thanks again for volunteering as Release Manager.

> On Apr 30, 2020, at 9:00 AM, Dave Barnes  wrote:
> 
> This is a request for bulk modification permissions and admin permissions on 
> the Geode project.
> Thanks,
> Dave Barnes
> dbar...@apache.org 
> 

Request for Concourse permissions

[Dave Barnes]

This is a request for permissions to log in and create pipelines for Apache 
Geode (https://concourse.apachegeode-ci.info/ 
).
Thanks,
Dave Barnes
dbar...@apache.com 
Github acct ID: davebarnes97

Re: Wiki edit permissions

[Raymond Ingles]

Thanks! Got the RFC up.

On Wed, Apr 29, 2020 at 5:32 PM Kirk Lund  wrote:

> You should both have permissions for creating and editing now. Thanks!
>
> On Wed, Apr 29, 2020 at 2:29 PM Kirk Lund  wrote:
>
> > Granting you permissions now... hang on a minute or two.
> >
> > On Wed, Apr 29, 2020 at 11:20 AM Raymond Ingles 
> > wrote:
> >
> >> My colleague and I are hoping to add a new RFC to the Geode wiki, but we
> >> need edit permissions to do it. I created an account on the wiki in the
> >> name of ring...@vmware.com, and Sarah did so
> >> with the address sabbe...@gmail.com. Who
> >> should we contact about getting edit permissions to add a new RFC for
> >> discussion? Thanks!
> >>
> >
>

[DISCUSS] Geode Redis API Improvements

[Raymond Ingles]

Hi all,

The current Redis API support in Geode has been marked experimental for a
couple years and has several bugs and inconsistencies compared to native
Redis. We created a RFC for updating the Geode Redis API support, to
address issues in the implementation, improve performance and add High
Availability support.

Please review and comment by 5/8/2020.

https://cwiki.apache.org/confluence/display/GEODE/Geode+Redis+API+Improvements

Thanks!

[ANNOUNCE] Geode 1.13 support branch coming soon

[Dave Barnes]

The project's time-based schedule targets the first Monday after May 1 for
cutting the support branch.
So, we're planning to cut the Geode 1.13 support branch on Monday, May 4,
2020.

Only critical fixes will be allowed once the support branch has been
created, so do what you can to make the develop branch as stable as
possible before Monday.

Thanks,
Dave

Re: [DISCUSS] Publish Builds, not Snapshots

[Robert Houghton]

I don't read any strong negatives to this change. I would like to start
polishing a PR on this work, unless anyone has strong opposing feelings.
Does anyone feel that this change requires a VOTE?

On Tue, Apr 28, 2020 at 10:36 AM Jacob Barrett  wrote:

> Probably for a separate discussion but I would opt for a future where the
> release manager validates and signs a specific build from produced by the
> CI. This takes a lot of error away in the what the release manager
> currently does, which has resulted in incorrect artifacts being voted on.
>
> In this model the release manager would be certifying a release with full
> version number, or whatever we choose for the release version number.
>
> Until then the release manager could just use the short number. In
> Gradle/Maven versioning a version without qualifier is always newer than
> one with. So 1.13.0 is newer than any 1.13.0-build.123.
>
> -Jake
>
>
> > On Apr 28, 2020, at 10:24 AM, Anthony Baker  wrote:
> >
> > Note that I’m asking about building on my local system.  Will the
> version listed in gradle.properties use the full 1.13.0-build.123 syntax?
> How would it get bumped?
> >
> > Would a release manager end up using just 1.13.0?  Hoping for yes :-)
> >
> > Anthony
> >
> >> On Apr 28, 2020, at 9:24 AM, Robert Houghton 
> wrote:
> >>
> >> @anthony
> >> /develop would say 1.13.0-build.230 (as of this morning).
> >> Once cut, /release/1.13 would say 1.13.0-build.231, and /develop would
> >> switch to 1.14.0-build.1.
> >>
> >> gfsh would return that full value. That is the artifact version.
> >>
> >> On Mon, Apr 27, 2020 at 4:38 PM Anthony Baker 
> wrote:
> >>
> >>> If I build the /develop branch and run `gfsh version` what will it
> print?
> >>>
> >>> If I build the soon-to-be /release/1.13 branch and run `gfsh version`
> what
> >>> will it print?
> >>>
> >>> Anthony
> >>>
> >>>
> >>> On 4/27/20, 4:32 PM, "Robert Houghton"  wrote:
> >>>
> >>>   The artifact would change from "1.13.0-SNAPSHOT" to
> "1.13.0-build.123".
> >>>
> >>>
> >>>
> >>>
> >>>
> >
>
>

Re: [DISCUSS] Publish Builds, not Snapshots

[Owen Nichols]

It sounds like the only impact is that downstream projects that consume 
-SNAPSHOT builds will need to make one small change to their maven config; 
downstream projects that consume release versions will be unaffected.  So just 
let us know when to make that change.

Anytime soon after support/1.13 is cut would be great to bring this change to 
develop.  Assuming it goes smoothly on develop, would you envision backporting 
to support/1.13 and support/1.12 as well?

> On Apr 30, 2020, at 8:38 PM, Robert Houghton  wrote:
> 
> I don't read any strong negatives to this change. I would like to start
> polishing a PR on this work, unless anyone has strong opposing feelings.
> Does anyone feel that this change requires a VOTE?
> 
> On Tue, Apr 28, 2020 at 10:36 AM Jacob Barrett  wrote:
> 
>> Probably for a separate discussion but I would opt for a future where the
>> release manager validates and signs a specific build from produced by the
>> CI. This takes a lot of error away in the what the release manager
>> currently does, which has resulted in incorrect artifacts being voted on.
>> 
>> In this model the release manager would be certifying a release with full
>> version number, or whatever we choose for the release version number.
>> 
>> Until then the release manager could just use the short number. In
>> Gradle/Maven versioning a version without qualifier is always newer than
>> one with. So 1.13.0 is newer than any 1.13.0-build.123.
>> 
>> -Jake
>> 
>> 
>>> On Apr 28, 2020, at 10:24 AM, Anthony Baker  wrote:
>>> 
>>> Note that I’m asking about building on my local system.  Will the
>> version listed in gradle.properties use the full 1.13.0-build.123 syntax?
>> How would it get bumped?
>>> 
>>> Would a release manager end up using just 1.13.0?  Hoping for yes :-)
>>> 
>>> Anthony
>>> 
 On Apr 28, 2020, at 9:24 AM, Robert Houghton 
>> wrote:
 
 @anthony
 /develop would say 1.13.0-build.230 (as of this morning).
 Once cut, /release/1.13 would say 1.13.0-build.231, and /develop would
 switch to 1.14.0-build.1.
 
 gfsh would return that full value. That is the artifact version.
 
 On Mon, Apr 27, 2020 at 4:38 PM Anthony Baker 
>> wrote:
 
> If I build the /develop branch and run `gfsh version` what will it
>> print?
> 
> If I build the soon-to-be /release/1.13 branch and run `gfsh version`
>> what
> will it print?
> 
> Anthony
> 
> 
> On 4/27/20, 4:32 PM, "Robert Houghton"  wrote:
> 
>  The artifact would change from "1.13.0-SNAPSHOT" to
>> "1.13.0-build.123".
> 
> 
> 
> 
> 
>>> 
>> 
>>