Concourse job names have been changed to lowercase for conformity[1].
If your PR shows required checks with a status of "Expected -- Waiting for
status to be reported", please push another commit.
[1] https://concourse-ci.org/config-basics.html#schema.identifier
Thanks, Owen. I was sitting down to write this.
For more context:
With the merge of GEODE-9298 to remove concourse deprecations from our
pipeline, many of the concourse jobs have been re-named. This may cause issues
with in-flight PRs not correctly updating their status with GitHub, which could
Hi All,
There has been some discussion about adding a new state of approved to Geode
Jira for features or something like it, to help prevent work being done that
doesn’t make it into the project. What to people think?
Thanks,
Mark
Hi Mark,
Could you explain that a bit more – I’m not clear what you mean by: “to help
prevent work being done that doesn’t make it into the project”.
Does that mean work that isn’t somehow related to a (new) feature.
--Jens
From: Mark Hanson
Date: Friday, May 28, 2021 at 10:36 AM
To: dev@geod
Can you provide a more concrete example? I don’t understand why there would be
a JIRA written without a reasonable belief it would be executed on. A JIRA that
is later determined to not be worth the effort, not a bug, or whatever, should
just closed as “won’t fix”.
> On May 28, 2021, at 10:36
Oh, I see now. Yes, +1 to what Jake said.
From: Jacob Barrett
Date: Friday, May 28, 2021 at 10:41 AM
To: dev@geode.apache.org
Subject: Re: [Discuss] New feature work approval state in Geode project?
Can you provide a more concrete example? I don’t understand why there would be
a JIRA written wi
Does this mean that a Jira would have to be approved before assigned?
Dale
From: Mark Hanson
Date: Friday, May 28, 2021 at 10:36 AM
To: dev@geode.apache.org
Subject: [Discuss] New feature work approval state in Geode project?
Hi All,
There has been some discussion about adding a new state of a
Can you be more elaborate on this...
Are we saying; if I (geode dev) find a bug or feature that I need for my
application, I need to get approval to create a ticket and work on it? We
already have RFC process, won't that suffice...
-Anil.
On 5/28/21, 10:36 AM, "Mark Hanson" wrote:
Hi All
Hi All,
I am just starting the chain to get it into the dev list. Bill and Donal had
more concrete ideas to share.
For the record, I am happy with the RFC process, but I am flexible.
Thanks,
Mark
On 5/28/21, 10:43 AM, "Anilkumar Gingade" wrote:
Can you be more elaborate on this...
We have an RFC process "to get to consensus faster and ultimately get to
execution faster". But I think in general folks tend to only do an RFC for
a "big" change. Bug tickets, and particularly feature tickets are left as a
gray area.
A google search for "most successful open source project" lists
I've also seen this on other projects where sometimes an issue gets substantial
support, but ultimately gets rejected because it doesn't match the project's
direction. Making this clear before work happens makes sense to me in general.
However, I wonder if the additional process in our case is m
> On May 28, 2021, at 10:48 AM, Bill Burcham wrote:
>
> A google search for "most successful open source project" lists Apache
> Cassandra at the top. When a bug is submitted to the Cassandra Jira it
> starts in the TRIAGE NEEDED state. Ostensibly after triage, it moves to the
> OPEN state whic
I think the key difference between what Bill and Jake are saying is that Bill
is saying a new feature needs approval in a more structured way. I think Bill's
process is open the jira, then it is "approved" or "won't do" then work starts.
I think what Jake is saying is a little less structured. T
> On May 28, 2021, at 11:24 AM, Mark Hanson wrote:
>
> I think the key difference between what Bill and Jake are saying is that Bill
> is saying a new feature needs approval in a more structured way. I think
> Bill's process is open the jira, then it is "approved" or "won't do" then
> work
My thoughts; I can't make distinction between feature or bug; it’s a change to
the codebase, if it has greater impact, is sensitive and takes time to build;
then it is a candidate to bring it up and talk about it before implementation.
Sometime its hard to determine/distinguish it, we developer
I think the main problem this discussion thread could solve is when a
developer files a Jira ticket as a bug, assigns it to themselves, and
begins work on it. After some time (possibly even a month or something
significant like that), they submit a PR to fix the ticket, only to find
out from multip
+1 Also, I think if the entire work is done by IntelliJ then just mention
that in the PR description and I'm happy to add approval without stepping
through every line. I'd probably just pick a dozen random ones to check and
then approve it.
On Thu, May 27, 2021 at 6:36 PM Darrel Schneider wrote:
Another thought I have is that if the "fix" for a bug will require any sort
of new User API or configuration properties (ie gemfire.properties), then
we should always treat that as a new feature that requires going through
our RFC process for a new feature.
On Fri, May 28, 2021 at 2:42 PM Kirk Lun
Anil's thoughts parallel what I was trying to describe as well...
On Fri, May 28, 2021 at 2:35 PM Anilkumar Gingade
wrote:
> My thoughts; I can't make distinction between feature or bug; it’s a
> change to the codebase, if it has greater impact, is sensitive and takes
> time to build; then it is
> On May 28, 2021, at 3:45 PM, Kirk Lund wrote:
>
> Another thought I have is that if the "fix" for a bug will require any sort
> of new User API or configuration properties (ie gemfire.properties), then
> we should always treat that as a new feature that requires going through
> our RFC proce
20 matches
Mail list logo
