Re: [Proposal] Thoughts on general guidelines to follow in Apache CarbonData community
+1, for 1,2,3,4,5,6,8,9,10 for 7, can we support do some test automatic? including performance for common function. It's great for CarbonData community, Can we arrange someone or manager to manage all JIRA and PR, and urge reviewer to review fast. The time will become slower after add these rules, we should accelerate the speed from raise a jira/PR to merge -- Sent from: http://apache-carbondata-dev-mailing-list-archive.1130556.n5.nabble.com/
Re: [Proposal] Thoughts on general guidelines to follow in Apache CarbonData community
+1 for 1,2,3,4,5,7,8,9,10. +0 for 6. One suggestion for 7, it better to give a performance comparison [TPCH] report for each release version. -- Sent from: http://apache-carbondata-dev-mailing-list-archive.1130556.n5.nabble.com/
Re: [Proposal] Thoughts on general guidelines to follow in Apache CarbonData community
+1 For Point 7 if there is a Automated report that can daily run and share the impact due to daily PR raised and report it to the committer could be efficient. -- Sent from: http://apache-carbondata-dev-mailing-list-archive.1130556.n5.nabble.com/
Re: [Proposal] Thoughts on general guidelines to follow in Apache CarbonData community
+1 for 1,2,3,4,5,8,9,10 +0 for 6,7 - Best Regards David Cai -- Sent from: http://apache-carbondata-dev-mailing-list-archive.1130556.n5.nabble.com/
Re: [Proposal] Thoughts on general guidelines to follow in Apache CarbonData community
Hi Thanks for starting the discussion. Big big +1 from my side, these rules are ASF key concepts (community over code, open and enough communition etc.), i do believe, these rules will help Apache CarbonData community go far! Regards Liang ravipesala wrote > Hi > > Please find our thoughts on the guidelines we can follow in the community > to ensure the quality of Carbondata and make the community more > collaborative. Let us discuss here. > > > 1.Let us discuss all the features in the community before starting > design. Let us attach the design document in the JIRA for future easy > reference > > 2.Let us have design review meetings for all new features and wait > till > at least 3 committers give +1 and approve the design. > > 3.Let us do the impact analysis on base flows and share our analysis > along with the design review. > > 4.Let us wait for at least 2 committers to review our code and put > LGTM. > > 5.Let us discuss and assign release manager role to one of the > committers/PMCs for every version and empower the release manager to > actively track the PRs required for the release scope and also assign the > review owners for them so that PRs are merged timely. > > 6.Let us have weekly meetings for all important features and let the > feature developers/owners share the progress and other > developments. > > 7.Let us attach functional, compatibility and performance comparison > [TPCH] reports both in JIRA and PR for all feature requirements > > 8.Let us develop features or optimizations not aligned with the > release > scope in a separate branch. > > 9.Let us add the mailing list link to the Jira to ensure easy > tracking. > Suggest checking all the open Jira before proposing new features or > enhancements. > > 10. Let us add the JIRA link in the mailing list to ensure easy tracking. > > -- > > Thanks & Regards, > Ravindra -- Sent from: http://apache-carbondata-dev-mailing-list-archive.1130556.n5.nabble.com/
[Proposal] Thoughts on general guidelines to follow in Apache CarbonData community
Hi Please find our thoughts on the guidelines we can follow in the community to ensure the quality of Carbondata and make the community more collaborative. Let us discuss here. 1.Let us discuss all the features in the community before starting design. Let us attach the design document in the JIRA for future easy reference 2.Let us have design review meetings for all new features and wait till at least 3 committers give +1 and approve the design. 3.Let us do the impact analysis on base flows and share our analysis along with the design review. 4.Let us wait for at least 2 committers to review our code and put LGTM. 5.Let us discuss and assign release manager role to one of the committers/PMCs for every version and empower the release manager to actively track the PRs required for the release scope and also assign the review owners for them so that PRs are merged timely. 6.Let us have weekly meetings for all important features and let the feature developers/owners share the progress and other developments. 7.Let us attach functional, compatibility and performance comparison [TPCH] reports both in JIRA and PR for all feature requirements 8.Let us develop features or optimizations not aligned with the release scope in a separate branch. 9.Let us add the mailing list link to the Jira to ensure easy tracking. Suggest checking all the open Jira before proposing new features or enhancements. 10. Let us add the JIRA link in the mailing list to ensure easy tracking. -- Thanks & Regards, Ravindra
