Re: Documentation-related tickets
I think we already have "documentation", I used it a couple of times ;) -Roman On Sunday, March 6, 2016 10:23 AM, Dmitriy Setrakyan wrote: Valentin, I think we should have a “documentation” component. Having browsed through the component list, we should get rid of the following components: “1.4”, “community”, “newbie”. I am not sure how these names got there, but they are not components. D. On Sat, Mar 5, 2016 at 3:12 PM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Folks, > > Do we have a component or a label that we commonly use to mark > documentation-related tickets? > > -Val >
Re: Documentation-related tickets
Valentin, I think we should have a “documentation” component. Having browsed through the component list, we should get rid of the following components: “1.4”, “community”, “newbie”. I am not sure how these names got there, but they are not components. D. On Sat, Mar 5, 2016 at 3:12 PM, Valentin Kulichenko < valentin.kuliche...@gmail.com> wrote: > Folks, > > Do we have a component or a label that we commonly use to mark > documentation-related tickets? > > -Val >
Documentation-related tickets
Folks, Do we have a component or a label that we commonly use to mark documentation-related tickets? -Val
Re: Switching back to review-then-commit process
+1 to the original proposal of Denis to introduce module maintainers and RTC process +1 to the proposal of Raul to restrict number of core modules, which require maintainers review Sergi 2016-03-05 6:43 GMT+03:00 Konstantin Boudnik : > It saddens me to see this coming to it ;( > > On Thu, Mar 03, 2016 at 02:54PM, Denis Magda wrote: > > Igniters, > > > > I would propose to switch back to review-then-commit process. This > > process has to be followed by both contributors and committers. > > > > There is a reason for this I have in mind. Ignite is a complex > > platform with several big modules. Some of the people may be experts > > in module A while others in module B etc. > > If a committer, who is good in module A, makes changes in module B > > merging the changes without a review this can break module's B > > internal functionality that the committer didn't take into account. > > > > My proposal is to introduce a list of maintainers for every Ignite > > module like it's done in Spark [1] and a rule that will require a > > committer to get an approval from a module maintainer before merging > > changes. > > > > Thoughts? > > > > -- > > Denis > > > > [1] > https://cwiki.apache.org/confluence/display/SPARK/Committers#Committers-ReviewProcessandMaintainers > > > > > > >
