I agree with Jinmei on all points. I definitely think there should be
parity between precheckin and the main pipeline, but that might just be
because I caused the main pipeline to fail on Java11 this week.
On Wed, Nov 7, 2018 at 1:34 PM, Jinmei Liao wrote:
> First of all, I believe all gating t
Hi everyone,
In order to perform all necessary steps to release 1.8.0, I need the
following permissions:
* Admin permissions for JIRA (username "amurmann")
* Upload permissions for Docker Hub (username "ajmurmann")
Thank you!
I’m working on a review of LICENSE and NOTICE. Looks like a few things slipped
in that need to be declared.
Anthony
> On Nov 2, 2018, at 12:42 PM, Bruce Schuchardt wrote:
>
> Fixes for PRClientServerRegionFunctionExecutionDUnitTest and
> CreateAsyncEventQueueCommandDUnitTest have been pushe
Also cherry-picked the LICENSE fix onto the release branch.
Anthony
> On Nov 8, 2018, at 10:04 AM, Anthony Baker wrote:
>
> Done!
>
>> On Nov 8, 2018, at 9:31 AM, Alexander Murmann wrote:
>>
>> Hi everyone,
>>
>> In order to perform all necessary steps to release 1.8.0, I need the
>> follo
Hi everyone,
I am considering adding Lombok as a compile-time dependency (
https://projectlombok.org/) so we can reduce the amount of boilerplate code
and reduce the size of some of our classes. I have a small proof of concept
PR ready to go. Before I do so, I want to find out if people have tried
Done!
> On Nov 8, 2018, at 9:31 AM, Alexander Murmann wrote:
>
> Hi everyone,
>
> In order to perform all necessary steps to release 1.8.0, I need the
> following permissions:
> * Admin permissions for JIRA (username "amurmann")
> * Upload permissions for Docker Hub (username "ajmurmann")
>
>
The Spring world/community are heavy users of Lombok.
In essence it is "nice", BUT it does now add a new dependency on a
library that is to provide functionality that developers should provide.
IJ Idea does provide support for Lombok.
I have not yet seen any code bloat that Lombok could reduc
I've only touched a few classes in my PR, but I feel like there's a lot
more boilerplate floating around that can be removed. Having said that, I
agree with your point regarding Kotlin, but for the Java code I would find
Lombok pretty useful. Have included a link to the PR:
https://github.com/apac
Hello everyone,
As discussed previously created a new release branch for Apache Geode 1.8.0
- "release/1.8.0"
Please do review and raise any concern with the release branch.
If no concerns are raised, we will start with the voting for the release
candidate soon.
This also means that all tickets
The key issue here is how closely the PR pipeline’s testing should match the
develop pipeline.
If parity is desirable, then we need to either add Java11 test jobs to the PR
pipeline, or go back to having Java11 tests be non-gating in the develop
pipeline.
If instead we want PR to be just a smo
Sounds like the overwhelming consensus is to keep Java11 gating, add Java11 to
PR, and defer non-gating tests.
I have prepared PRs for these changes:
https://github.com/apache/geode/pull/2806 (add Java11 to PR pipeline)
https://github.com/apache/geode/pull/2816 (run non-gating jobs only after
ga
Note: If the PR gets accepted, people that use IntelliJ idea or Eclipse
will need to use the Lombok plugin for their respective IDEs -- for
IntelliJ people will also need to enable annotation processing in the
compiler settings if not already enabled.
On Thu, Nov 8, 2018 at 12:02 PM Aditya Anchuri
I know that this is "pedantic".. but to me "isDiskSynchronous" reads
better than "getDiskSynchronous"
but in the end, it returns the declared field.
Kotlin's data class on the other plays a little "nicer".
If you define the field as "isDiskSynchronous" the generated getter is
"isDiskSynchrono
I’d prefer to keep lombok usage out of our public API’s. I’d like to be able
to write javadoc for all public methods. Also, I don’t want a user to have to
understand Lombok to read our API’s or do an extra step to setup their IDE.
For internal usage I’m agnostic with a small dose of concern on
Regarding is vs get, Lombok generates a getter as "isFoo" if foo is a
boolean type -- but a Boolean object type by default gets generated as
getFoo().
I personally like that, because I want to make sure I communicate in that
getter that the type is nullable.
On Thu, Nov 8, 2018 at 2:33 PM Anthony
Hello all!
We currently have 182 branches on the apache/geode repository. This is
excessive.
Please fork the main repository and save your branches there. If you
must use the apache/geode repository for some reason, please be diligent in
your removal of dead branches.
*I would like to beg
Notes:
- Older release/* branches may be removed.
- Do not remove branches like native-client-software-grant, sga2,
wan_cq_donation, etc. Those need to be preserved as a provenance record.
- Do not remove master or develop :-)
Anthony
> On Nov 8, 2018, at 4:55 PM, Patrick Rhomberg wrote:
>
I'm pretty sure we want to keep the release tags for every release we've
made, in case someone wants to check something against old releases.
On Thu, Nov 8, 2018 at 5:04 PM Anthony Baker wrote:
> Notes:
>
> - Older release/* branches may be removed.
> - Do not remove branches like native-client-
Our release tags should already be protected. We create all of our release
tags under rel/ which apache protects by default. [1]
Maybe we should just create rel/XXX tags for the heads of the branches
Anthony mentioned and delete the branches themselves?
https://git-wip-us.apache.org/docs/switchin
As an informative comparison on conciseness offering same functionality:
Java Code:
import java.io.Serializable; import lombok.Getter; import org.apache.geode.cache.configuration.CacheConfig.GatewayReceiver; import org.apache.geode.cache.configuration.DeclarableType; /** * This class stores the
For a matter of safety, perhaps we should as INFRA to protect those branches?
> On Nov 8, 2018, at 5:04 PM, Anthony Baker wrote:
>
> Notes:
>
> - Older release/* branches may be removed.
> - Do not remove branches like native-client-software-grant, sga2,
> wan_cq_donation, etc. Those need to
21 matches
Mail list logo
