You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@bigtop.apache.org by Konstantin Boudnik <co...@apache.org> on 2014/12/25 02:16:42 UTC
To speed up the development: shall we become a CTR project?
I've been reading this discussion on Ignite (incubating) dev@ list
http://s.apache.org/wPA and it clicked with the thread we were having in
the last few days around the community and development processes.
What do you guys think if we'll try CTR model? Committers here went through
the process of gaining their karma and proved with their contributions that
they don't need peer-reviews for a lot of things that are coming into the
project on the daily basis. The RTC is especially annoying for trivial changes
and is really making things slower than they could've been.
So, what do you think guys?
--
Take care,
Cos
2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
Cos' pubkey: http://people.apache.org/~cos/cos.asc
---- Wisdom of the hour ----
FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #4
A: Go west, young man, go west!
Q: What do wabbits do when they get tiwed of wunning awound?
Re: two months since Bigtop started on CTR path
Posted by RJ Nowling <rn...@gmail.com>.
+1 from me, too.
On Fri, Nov 20, 2015 at 4:45 PM, Konstantin Boudnik <co...@apache.org> wrote:
> Seemingly we have a consensus here, but this is a policy change, so I will
> start an official [VOTE] to wrap it up. Thanks!
>
> Cos
>
> On Tue, Nov 17, 2015 at 06:19PM, Olaf Flebbe wrote:
> > Hi,
> >
> > Seems I haven't broken too much ;-) +1 from me, too.
> >
> > Thanks.
> > Olaf
> >
> >
> > > Am 17.11.2015 um 17:19 schrieb Roman Shaposhnik <roman@shaposhnik.org
> >:
> > >
> > > On Mon, Nov 16, 2015 at 10:53 PM, Konstantin Boudnik <co...@apache.org>
> wrote:
> > >> What I find real good about this experiment is that we don't see any
> abuse of
> > >> this policy. Committers are actively seeking the feedback if they
> feel a need
> > >> to have a discussion about the implementation. Which is one of the
> most common
> > >> objections to the model.
> > >
> > > +1 to that!
> > >
> > > Thanks,
> > > Roman.
> >
>
>
>
Re: two months since Bigtop started on CTR path
Posted by Konstantin Boudnik <co...@apache.org>.
Seemingly we have a consensus here, but this is a policy change, so I will
start an official [VOTE] to wrap it up. Thanks!
Cos
On Tue, Nov 17, 2015 at 06:19PM, Olaf Flebbe wrote:
> Hi,
>
> Seems I haven't broken too much ;-) +1 from me, too.
>
> Thanks.
> Olaf
>
>
> > Am 17.11.2015 um 17:19 schrieb Roman Shaposhnik <ro...@shaposhnik.org>:
> >
> > On Mon, Nov 16, 2015 at 10:53 PM, Konstantin Boudnik <co...@apache.org> wrote:
> >> What I find real good about this experiment is that we don't see any abuse of
> >> this policy. Committers are actively seeking the feedback if they feel a need
> >> to have a discussion about the implementation. Which is one of the most common
> >> objections to the model.
> >
> > +1 to that!
> >
> > Thanks,
> > Roman.
>
Re: two months since Bigtop started on CTR path
Posted by Olaf Flebbe <of...@oflebbe.de>.
Hi,
Seems I haven't broken too much ;-) +1 from me, too.
Thanks.
Olaf
> Am 17.11.2015 um 17:19 schrieb Roman Shaposhnik <ro...@shaposhnik.org>:
>
> On Mon, Nov 16, 2015 at 10:53 PM, Konstantin Boudnik <co...@apache.org> wrote:
>> What I find real good about this experiment is that we don't see any abuse of
>> this policy. Committers are actively seeking the feedback if they feel a need
>> to have a discussion about the implementation. Which is one of the most common
>> objections to the model.
>
> +1 to that!
>
> Thanks,
> Roman.
Re: two months since Bigtop started on CTR path
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Mon, Nov 16, 2015 at 10:53 PM, Konstantin Boudnik <co...@apache.org> wrote:
> What I find real good about this experiment is that we don't see any abuse of
> this policy. Committers are actively seeking the feedback if they feel a need
> to have a discussion about the implementation. Which is one of the most common
> objections to the model.
+1 to that!
Thanks,
Roman.
Re: two months since Bigtop started on CTR path
Posted by Konstantin Boudnik <co...@apache.org>.
What I find real good about this experiment is that we don't see any abuse of
this policy. Committers are actively seeking the feedback if they feel a need
to have a discussion about the implementation. Which is one of the most common
objections to the model.
On Tue, Nov 17, 2015 at 02:06PM, Evans Ye wrote:
> It seems things are going pretty well under CTR:
> * Committers are more productive
> * Nothing went wrong seriously
> * Concern on patches are addressed
>
> So I'm +1 to make CTR model permanent.
>
> 2015-11-17 10:31 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
>
> > Next week will be two months since we pushed BIGTOP-2069 introducing a
> > trial
> > period of the project's CTR development model. I am happy to say that we
> > haven't broke the project ;) And now with the new better working CI the
> > chances of it are even slimmer, IMO. Once we have an automatic deployment
> > and
> > testing, we'll be even in the better shape.
> >
> > Hence, I'd like to revisit the conversation from September and gauge the
> > consensus of CTR model to become permanent?
> >
> > Thoughts?
> > Cos
> >
> > On Tue, Sep 22, 2015 at 05:01PM, Konstantin Boudnik wrote:
> > > Looks like we have the lazy consensus on this. Let's move forward with
> > > two-months trial, conditional on CI being recovered after the current
> > issues
> > > with disk space getting filled quickly. So, I presume we'll start after
> > the
> > > ApacheCon EU.
> > >
> > > I propose the following work-flow for CTR and document it in the
> > top-level
> > > README. Here's the patch:
> > >
> > > diff --git README.md README.md
> > > index 6342f92..23062a6 100644
> > > --- README.md
> > > +++ README.md
> > > @@ -55,6 +55,27 @@ There are lots of ways to contribute. People with
> > different expertise can help
> > >
> > > Also, opening [JIRA's](https://issues.apache.org/jira/browse/BIGTOP)
> > and getting started by posting on the mailing list is helpful.
> > >
> > > +CTR model trial
> > > +===============
> > > +
> > > +As discussed on the dev@ list (http://bit.ly/1gLeArc) we are going
> > into a trial
> > > +period of CTR model for Bigtop project. The trial will go into effect
> > until
> > > +Dec, 5th, 2015 or for two months since the master CI disk space issues
> > are resolve,
> > > +whichever comes first. The following rules will be used for the CTR
> > process:
> > > + * a committer can go ahead and commit the patch without mandatory
> > review if
> > > + felt confident in its quality (e.g. reasonable testing has been done
> > > + locally; all compilations pass; RAT check is passed; the patch
> > follows
> > > + coding guidelines)
> > > + * a committer is encouraged to seek peer-review and/or advice before
> > hand if
> > > + there're doubts in the approach taken, design decision, or
> > implementation
> > > + details
> > > + * a committer should keep an eye on the official CI builds at
> > > + http://ci.bigtop.apache.org:8080/view/Bigtop-trunk/
> > (Docker-Bigtop-*
> > > + builds) to make sure that committed changes haven't break anything.
> > In
> > > + which case the committer should take a timely effort to resolve the
> > issues
> > > + and unblock the others in the community
> > > + * there's no changes in the JIRA process, except as specified above
> > > +
> > > What do people use Apache Bigtop for?
> > > ==============================
> > >
> > > ---- end of the patch
> > >
> > > If the above looks ok for everybody I will go ahead and commit this in a
> > couple
> > > of days, once I regain the network connection.
> > >
> > > Regards,
> > > Cos
> > >
> > > On Sun, Sep 20, 2015 at 03:23AM, Evans Ye wrote:
> > > > Ofcourse if that doesnt fit we can roll back to RTC :)
> > > > 2015年9月20日 上午3:20於 "Evans Ye" <ev...@apache.org>寫道：
> > > >
> > > > > This is way better than mine!
> > > > > With practical use & try we can have concrete idea of how CTR works
> > in our
> > > > > community. We can develop our policy to handle real world cases
> > instead of
> > > > > just imaging it.
> > > > > 2015年9月20日 上午3:11於 "Konstantin Boudnik" <co...@apache.org>寫道：
> > > > >
> > > > >> I'd rather avoid or at least postpone the voting until we have
> > everyone
> > > > >> being
> > > > >> comfortable with the proposed changed. I really don't like an idea
> > of
> > > > >> someone
> > > > >> being in minority and being forced to play alone. On the other
> > hand, I
> > > > >> see a
> > > > >> bunch of situations where CTR would be beneficial e.g BIGTOP-2057.
> > > > >>
> > > > >> If as Evans said all questions were answered, let's proceed to
> > voting. If
> > > > >> not
> > > > >> - let's give CTR a try for say a couple of months and see how it
> > works for
> > > > >> everybody. We hardly can do any irreversible harm even if we try -
> > we can
> > > > >> always revert anything we don't like ;)
> > > > >>
> > > > >> Cos
> > > > >>
> > > > >> On Sun, Sep 20, 2015 at 01:52AM, Evans Ye wrote:
> > > > >> > To summarise this discussing thread, I think we have most of our
> > team
> > > > >> > member supporting CTR model and questions from RTC advocates are
> > > > >> answered.
> > > > >> > I propose to start a vote to officially made decision wether or
> > not to
> > > > >> > switch to CTR.
> > > > >> > If that passed, we then start drafting our CTR policy through
> > > > >> discussion.
> > > > >> > Any other thoughts?
> > > > >> >
> > > > >> > 2015-09-18 2:50 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > > > >> >
> > > > >> > > Can I ask RTC advocate to review a couple of patches to unblock
> > me?
> > > > >> > >
> > > > >> > > BIGTOP-2025
> > > > >> > > BIGTOP-2051
> > > > >> > >
> > > > >> > > Thank you very much!
> > > > >> > > Cos
> > > > >> > >
> > > > >> > > On Mon, Sep 14, 2015 at 11:32AM, Konstantin Boudnik wrote:
> > > > >> > > > On Mon, Sep 14, 2015 at 07:35PM, Olaf Flebbe wrote:
> > > > >> > > > > Sorry, I haven't followed the initial discussion since I
> > was not
> > > > >> > > onboard at that time.
> > > > >> > > > >
> > > > >> > > > > From my view bigtop is the fastest moving project, I ever
> > knew. I
> > > > >> am
> > > > >> > > active
> > > > >> > > > > for over 20 years in all kinds of opensource projects, but
> > bigtops
> > > > >> > > tops them
> > > > >> > > > > all in speed, second fastest maybe samba and linux kernel
> > at 0.0x
> > > > >> > > >
> > > > >> > > > That's so good to hear! Made my day, if not the whole week!
> > Speaks
> > > > >> tons
> > > > >> > > about
> > > > >> > > > the community we have on this project!
> > > > >> > > >
> > > > >> > > > > I am strongly oppose [i.e. -1] the CTR style, since I think
> > the
> > > > >> > > project --
> > > > >> > > > > and myself -- take large benefits from discussions about
> > > > >> implementing
> > > > >> > > the
> > > > >> > > > > best solution for the project.
> > > > >> > > >
> > > > >> > > > I think CTR doesn't mean that one can not ever ask for a code
> > review
> > > > >> > > upfront.
> > > > >> > > > It's all about trusting the developers to do what's the best
> > for the
> > > > >> > > project
> > > > >> > > > without hanging out high and dry in some obvious cases.
> > > > >> > > >
> > > > >> > > > > Getting a +1 is not only that a patch simply runs, it is
> > about
> > > > >> code
> > > > >> > > style,
> > > > >> > > > > architectural decisions. Even a one-liner patch can break
> > > > >> designs.
> > > > >> > > >
> > > > >> > > > And that again falls back to the point of trusting the
> > judgement of
> > > > >> your
> > > > >> > > peers
> > > > >> > > > to do the "right thing" and come forward with the discussion
> > before
> > > > >> > > making the
> > > > >> > > > changes that are questionable or contraversial. And we won't
> > know
> > > > >> if it
> > > > >> > > works
> > > > >> > > > before we try it at least for some time ;)
> > > > >> > > >
> > > > >> > > > Cos
> > > > >> > > >
> > > > >> > > > > I think a clear review guideline would help bigtop more
> > that a
> > > > >> commit
> > > > >> > > > > policy change.
> > > > >> > > > >
> > > > >> > > > > Olaf
> > > > >> > > > >
> > > > >> > > > >
> > > > >> > > > >
> > > > >> > > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > >
> > > > >>
> > > > >
> >
Re: two months since Bigtop started on CTR path
Posted by Evans Ye <ev...@apache.org>.
It seems things are going pretty well under CTR:
* Committers are more productive
* Nothing went wrong seriously
* Concern on patches are addressed
So I'm +1 to make CTR model permanent.
2015-11-17 10:31 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> Next week will be two months since we pushed BIGTOP-2069 introducing a
> trial
> period of the project's CTR development model. I am happy to say that we
> haven't broke the project ;) And now with the new better working CI the
> chances of it are even slimmer, IMO. Once we have an automatic deployment
> and
> testing, we'll be even in the better shape.
>
> Hence, I'd like to revisit the conversation from September and gauge the
> consensus of CTR model to become permanent?
>
> Thoughts?
> Cos
>
> On Tue, Sep 22, 2015 at 05:01PM, Konstantin Boudnik wrote:
> > Looks like we have the lazy consensus on this. Let's move forward with
> > two-months trial, conditional on CI being recovered after the current
> issues
> > with disk space getting filled quickly. So, I presume we'll start after
> the
> > ApacheCon EU.
> >
> > I propose the following work-flow for CTR and document it in the
> top-level
> > README. Here's the patch:
> >
> > diff --git README.md README.md
> > index 6342f92..23062a6 100644
> > --- README.md
> > +++ README.md
> > @@ -55,6 +55,27 @@ There are lots of ways to contribute. People with
> different expertise can help
> >
> > Also, opening [JIRA's](https://issues.apache.org/jira/browse/BIGTOP)
> and getting started by posting on the mailing list is helpful.
> >
> > +CTR model trial
> > +===============
> > +
> > +As discussed on the dev@ list (http://bit.ly/1gLeArc) we are going
> into a trial
> > +period of CTR model for Bigtop project. The trial will go into effect
> until
> > +Dec, 5th, 2015 or for two months since the master CI disk space issues
> are resolve,
> > +whichever comes first. The following rules will be used for the CTR
> process:
> > + * a committer can go ahead and commit the patch without mandatory
> review if
> > + felt confident in its quality (e.g. reasonable testing has been done
> > + locally; all compilations pass; RAT check is passed; the patch
> follows
> > + coding guidelines)
> > + * a committer is encouraged to seek peer-review and/or advice before
> hand if
> > + there're doubts in the approach taken, design decision, or
> implementation
> > + details
> > + * a committer should keep an eye on the official CI builds at
> > + http://ci.bigtop.apache.org:8080/view/Bigtop-trunk/
> (Docker-Bigtop-*
> > + builds) to make sure that committed changes haven't break anything.
> In
> > + which case the committer should take a timely effort to resolve the
> issues
> > + and unblock the others in the community
> > + * there's no changes in the JIRA process, except as specified above
> > +
> > What do people use Apache Bigtop for?
> > ==============================
> >
> > ---- end of the patch
> >
> > If the above looks ok for everybody I will go ahead and commit this in a
> couple
> > of days, once I regain the network connection.
> >
> > Regards,
> > Cos
> >
> > On Sun, Sep 20, 2015 at 03:23AM, Evans Ye wrote:
> > > Ofcourse if that doesnt fit we can roll back to RTC :)
> > > 2015年9月20日 上午3:20於 "Evans Ye" <ev...@apache.org>寫道：
> > >
> > > > This is way better than mine!
> > > > With practical use & try we can have concrete idea of how CTR works
> in our
> > > > community. We can develop our policy to handle real world cases
> instead of
> > > > just imaging it.
> > > > 2015年9月20日 上午3:11於 "Konstantin Boudnik" <co...@apache.org>寫道：
> > > >
> > > >> I'd rather avoid or at least postpone the voting until we have
> everyone
> > > >> being
> > > >> comfortable with the proposed changed. I really don't like an idea
> of
> > > >> someone
> > > >> being in minority and being forced to play alone. On the other
> hand, I
> > > >> see a
> > > >> bunch of situations where CTR would be beneficial e.g BIGTOP-2057.
> > > >>
> > > >> If as Evans said all questions were answered, let's proceed to
> voting. If
> > > >> not
> > > >> - let's give CTR a try for say a couple of months and see how it
> works for
> > > >> everybody. We hardly can do any irreversible harm even if we try -
> we can
> > > >> always revert anything we don't like ;)
> > > >>
> > > >> Cos
> > > >>
> > > >> On Sun, Sep 20, 2015 at 01:52AM, Evans Ye wrote:
> > > >> > To summarise this discussing thread, I think we have most of our
> team
> > > >> > member supporting CTR model and questions from RTC advocates are
> > > >> answered.
> > > >> > I propose to start a vote to officially made decision wether or
> not to
> > > >> > switch to CTR.
> > > >> > If that passed, we then start drafting our CTR policy through
> > > >> discussion.
> > > >> > Any other thoughts?
> > > >> >
> > > >> > 2015-09-18 2:50 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > > >> >
> > > >> > > Can I ask RTC advocate to review a couple of patches to unblock
> me?
> > > >> > >
> > > >> > > BIGTOP-2025
> > > >> > > BIGTOP-2051
> > > >> > >
> > > >> > > Thank you very much!
> > > >> > > Cos
> > > >> > >
> > > >> > > On Mon, Sep 14, 2015 at 11:32AM, Konstantin Boudnik wrote:
> > > >> > > > On Mon, Sep 14, 2015 at 07:35PM, Olaf Flebbe wrote:
> > > >> > > > > Sorry, I haven't followed the initial discussion since I
> was not
> > > >> > > onboard at that time.
> > > >> > > > >
> > > >> > > > > From my view bigtop is the fastest moving project, I ever
> knew. I
> > > >> am
> > > >> > > active
> > > >> > > > > for over 20 years in all kinds of opensource projects, but
> bigtops
> > > >> > > tops them
> > > >> > > > > all in speed, second fastest maybe samba and linux kernel
> at 0.0x
> > > >> > > >
> > > >> > > > That's so good to hear! Made my day, if not the whole week!
> Speaks
> > > >> tons
> > > >> > > about
> > > >> > > > the community we have on this project!
> > > >> > > >
> > > >> > > > > I am strongly oppose [i.e. -1] the CTR style, since I think
> the
> > > >> > > project --
> > > >> > > > > and myself -- take large benefits from discussions about
> > > >> implementing
> > > >> > > the
> > > >> > > > > best solution for the project.
> > > >> > > >
> > > >> > > > I think CTR doesn't mean that one can not ever ask for a code
> review
> > > >> > > upfront.
> > > >> > > > It's all about trusting the developers to do what's the best
> for the
> > > >> > > project
> > > >> > > > without hanging out high and dry in some obvious cases.
> > > >> > > >
> > > >> > > > > Getting a +1 is not only that a patch simply runs, it is
> about
> > > >> code
> > > >> > > style,
> > > >> > > > > architectural decisions. Even a one-liner patch can break
> > > >> designs.
> > > >> > > >
> > > >> > > > And that again falls back to the point of trusting the
> judgement of
> > > >> your
> > > >> > > peers
> > > >> > > > to do the "right thing" and come forward with the discussion
> before
> > > >> > > making the
> > > >> > > > changes that are questionable or contraversial. And we won't
> know
> > > >> if it
> > > >> > > works
> > > >> > > > before we try it at least for some time ;)
> > > >> > > >
> > > >> > > > Cos
> > > >> > > >
> > > >> > > > > I think a clear review guideline would help bigtop more
> that a
> > > >> commit
> > > >> > > > > policy change.
> > > >> > > > >
> > > >> > > > > Olaf
> > > >> > > > >
> > > >> > > > >
> > > >> > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > > >
> > > >> > >
> > > >>
> > > >
>
Re: two months since Bigtop started on CTR path
Posted by Konstantin Boudnik <co...@apache.org>.
Next week will be two months since we pushed BIGTOP-2069 introducing a trial
period of the project's CTR development model. I am happy to say that we
haven't broke the project ;) And now with the new better working CI the
chances of it are even slimmer, IMO. Once we have an automatic deployment and
testing, we'll be even in the better shape.
Hence, I'd like to revisit the conversation from September and gauge the
consensus of CTR model to become permanent?
Thoughts?
Cos
On Tue, Sep 22, 2015 at 05:01PM, Konstantin Boudnik wrote:
> Looks like we have the lazy consensus on this. Let's move forward with
> two-months trial, conditional on CI being recovered after the current issues
> with disk space getting filled quickly. So, I presume we'll start after the
> ApacheCon EU.
>
> I propose the following work-flow for CTR and document it in the top-level
> README. Here's the patch:
>
> diff --git README.md README.md
> index 6342f92..23062a6 100644
> --- README.md
> +++ README.md
> @@ -55,6 +55,27 @@ There are lots of ways to contribute. People with different expertise can help
>
> Also, opening [JIRA's](https://issues.apache.org/jira/browse/BIGTOP) and getting started by posting on the mailing list is helpful.
>
> +CTR model trial
> +===============
> +
> +As discussed on the dev@ list (http://bit.ly/1gLeArc) we are going into a trial
> +period of CTR model for Bigtop project. The trial will go into effect until
> +Dec, 5th, 2015 or for two months since the master CI disk space issues are resolve,
> +whichever comes first. The following rules will be used for the CTR process:
> + * a committer can go ahead and commit the patch without mandatory review if
> + felt confident in its quality (e.g. reasonable testing has been done
> + locally; all compilations pass; RAT check is passed; the patch follows
> + coding guidelines)
> + * a committer is encouraged to seek peer-review and/or advice before hand if
> + there're doubts in the approach taken, design decision, or implementation
> + details
> + * a committer should keep an eye on the official CI builds at
> + http://ci.bigtop.apache.org:8080/view/Bigtop-trunk/ (Docker-Bigtop-*
> + builds) to make sure that committed changes haven't break anything. In
> + which case the committer should take a timely effort to resolve the issues
> + and unblock the others in the community
> + * there's no changes in the JIRA process, except as specified above
> +
> What do people use Apache Bigtop for?
> ==============================
>
> ---- end of the patch
>
> If the above looks ok for everybody I will go ahead and commit this in a couple
> of days, once I regain the network connection.
>
> Regards,
> Cos
>
> On Sun, Sep 20, 2015 at 03:23AM, Evans Ye wrote:
> > Ofcourse if that doesnt fit we can roll back to RTC :)
> > 2015年9月20日 上午3:20於 "Evans Ye" <ev...@apache.org>寫道：
> >
> > > This is way better than mine!
> > > With practical use & try we can have concrete idea of how CTR works in our
> > > community. We can develop our policy to handle real world cases instead of
> > > just imaging it.
> > > 2015年9月20日 上午3:11於 "Konstantin Boudnik" <co...@apache.org>寫道：
> > >
> > >> I'd rather avoid or at least postpone the voting until we have everyone
> > >> being
> > >> comfortable with the proposed changed. I really don't like an idea of
> > >> someone
> > >> being in minority and being forced to play alone. On the other hand, I
> > >> see a
> > >> bunch of situations where CTR would be beneficial e.g BIGTOP-2057.
> > >>
> > >> If as Evans said all questions were answered, let's proceed to voting. If
> > >> not
> > >> - let's give CTR a try for say a couple of months and see how it works for
> > >> everybody. We hardly can do any irreversible harm even if we try - we can
> > >> always revert anything we don't like ;)
> > >>
> > >> Cos
> > >>
> > >> On Sun, Sep 20, 2015 at 01:52AM, Evans Ye wrote:
> > >> > To summarise this discussing thread, I think we have most of our team
> > >> > member supporting CTR model and questions from RTC advocates are
> > >> answered.
> > >> > I propose to start a vote to officially made decision wether or not to
> > >> > switch to CTR.
> > >> > If that passed, we then start drafting our CTR policy through
> > >> discussion.
> > >> > Any other thoughts?
> > >> >
> > >> > 2015-09-18 2:50 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> > >> >
> > >> > > Can I ask RTC advocate to review a couple of patches to unblock me?
> > >> > >
> > >> > > BIGTOP-2025
> > >> > > BIGTOP-2051
> > >> > >
> > >> > > Thank you very much!
> > >> > > Cos
> > >> > >
> > >> > > On Mon, Sep 14, 2015 at 11:32AM, Konstantin Boudnik wrote:
> > >> > > > On Mon, Sep 14, 2015 at 07:35PM, Olaf Flebbe wrote:
> > >> > > > > Sorry, I haven't followed the initial discussion since I was not
> > >> > > onboard at that time.
> > >> > > > >
> > >> > > > > From my view bigtop is the fastest moving project, I ever knew. I
> > >> am
> > >> > > active
> > >> > > > > for over 20 years in all kinds of opensource projects, but bigtops
> > >> > > tops them
> > >> > > > > all in speed, second fastest maybe samba and linux kernel at 0.0x
> > >> > > >
> > >> > > > That's so good to hear! Made my day, if not the whole week! Speaks
> > >> tons
> > >> > > about
> > >> > > > the community we have on this project!
> > >> > > >
> > >> > > > > I am strongly oppose [i.e. -1] the CTR style, since I think the
> > >> > > project --
> > >> > > > > and myself -- take large benefits from discussions about
> > >> implementing
> > >> > > the
> > >> > > > > best solution for the project.
> > >> > > >
> > >> > > > I think CTR doesn't mean that one can not ever ask for a code review
> > >> > > upfront.
> > >> > > > It's all about trusting the developers to do what's the best for the
> > >> > > project
> > >> > > > without hanging out high and dry in some obvious cases.
> > >> > > >
> > >> > > > > Getting a +1 is not only that a patch simply runs, it is about
> > >> code
> > >> > > style,
> > >> > > > > architectural decisions. Even a one-liner patch can break
> > >> designs.
> > >> > > >
> > >> > > > And that again falls back to the point of trusting the judgement of
> > >> your
> > >> > > peers
> > >> > > > to do the "right thing" and come forward with the discussion before
> > >> > > making the
> > >> > > > changes that are questionable or contraversial. And we won't know
> > >> if it
> > >> > > works
> > >> > > > before we try it at least for some time ;)
> > >> > > >
> > >> > > > Cos
> > >> > > >
> > >> > > > > I think a clear review guideline would help bigtop more that a
> > >> commit
> > >> > > > > policy change.
> > >> > > > >
> > >> > > > > Olaf
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > > >
> > >> > > >
> > >> > > >
> > >> > >
> > >>
> > >
Re: To speed up the development: shall we become a CTR project?
Posted by Konstantin Boudnik <co...@apache.org>.
Looks like we have the lazy consensus on this. Let's move forward with
two-months trial, conditional on CI being recovered after the current issues
with disk space getting filled quickly. So, I presume we'll start after the
ApacheCon EU.
I propose the following work-flow for CTR and document it in the top-level
README. Here's the patch:
diff --git README.md README.md
index 6342f92..23062a6 100644
--- README.md
+++ README.md
@@ -55,6 +55,27 @@ There are lots of ways to contribute. People with different expertise can help
Also, opening [JIRA's](https://issues.apache.org/jira/browse/BIGTOP) and getting started by posting on the mailing list is helpful.
+CTR model trial
+===============
+
+As discussed on the dev@ list (http://bit.ly/1gLeArc) we are going into a trial
+period of CTR model for Bigtop project. The trial will go into effect until
+Dec, 5th, 2015 or for two months since the master CI disk space issues are resolve,
+whichever comes first. The following rules will be used for the CTR process:
+ * a committer can go ahead and commit the patch without mandatory review if
+ felt confident in its quality (e.g. reasonable testing has been done
+ locally; all compilations pass; RAT check is passed; the patch follows
+ coding guidelines)
+ * a committer is encouraged to seek peer-review and/or advice before hand if
+ there're doubts in the approach taken, design decision, or implementation
+ details
+ * a committer should keep an eye on the official CI builds at
+ http://ci.bigtop.apache.org:8080/view/Bigtop-trunk/ (Docker-Bigtop-*
+ builds) to make sure that committed changes haven't break anything. In
+ which case the committer should take a timely effort to resolve the issues
+ and unblock the others in the community
+ * there's no changes in the JIRA process, except as specified above
+
What do people use Apache Bigtop for?
==============================
---- end of the patch
If the above looks ok for everybody I will go ahead and commit this in a couple
of days, once I regain the network connection.
Regards,
Cos
On Sun, Sep 20, 2015 at 03:23AM, Evans Ye wrote:
> Ofcourse if that doesnt fit we can roll back to RTC :)
> 2015年9月20日 上午3:20於 "Evans Ye" <ev...@apache.org>寫道：
>
> > This is way better than mine!
> > With practical use & try we can have concrete idea of how CTR works in our
> > community. We can develop our policy to handle real world cases instead of
> > just imaging it.
> > 2015年9月20日 上午3:11於 "Konstantin Boudnik" <co...@apache.org>寫道：
> >
> >> I'd rather avoid or at least postpone the voting until we have everyone
> >> being
> >> comfortable with the proposed changed. I really don't like an idea of
> >> someone
> >> being in minority and being forced to play alone. On the other hand, I
> >> see a
> >> bunch of situations where CTR would be beneficial e.g BIGTOP-2057.
> >>
> >> If as Evans said all questions were answered, let's proceed to voting. If
> >> not
> >> - let's give CTR a try for say a couple of months and see how it works for
> >> everybody. We hardly can do any irreversible harm even if we try - we can
> >> always revert anything we don't like ;)
> >>
> >> Cos
> >>
> >> On Sun, Sep 20, 2015 at 01:52AM, Evans Ye wrote:
> >> > To summarise this discussing thread, I think we have most of our team
> >> > member supporting CTR model and questions from RTC advocates are
> >> answered.
> >> > I propose to start a vote to officially made decision wether or not to
> >> > switch to CTR.
> >> > If that passed, we then start drafting our CTR policy through
> >> discussion.
> >> > Any other thoughts?
> >> >
> >> > 2015-09-18 2:50 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> >> >
> >> > > Can I ask RTC advocate to review a couple of patches to unblock me?
> >> > >
> >> > > BIGTOP-2025
> >> > > BIGTOP-2051
> >> > >
> >> > > Thank you very much!
> >> > > Cos
> >> > >
> >> > > On Mon, Sep 14, 2015 at 11:32AM, Konstantin Boudnik wrote:
> >> > > > On Mon, Sep 14, 2015 at 07:35PM, Olaf Flebbe wrote:
> >> > > > > Sorry, I haven't followed the initial discussion since I was not
> >> > > onboard at that time.
> >> > > > >
> >> > > > > From my view bigtop is the fastest moving project, I ever knew. I
> >> am
> >> > > active
> >> > > > > for over 20 years in all kinds of opensource projects, but bigtops
> >> > > tops them
> >> > > > > all in speed, second fastest maybe samba and linux kernel at 0.0x
> >> > > >
> >> > > > That's so good to hear! Made my day, if not the whole week! Speaks
> >> tons
> >> > > about
> >> > > > the community we have on this project!
> >> > > >
> >> > > > > I am strongly oppose [i.e. -1] the CTR style, since I think the
> >> > > project --
> >> > > > > and myself -- take large benefits from discussions about
> >> implementing
> >> > > the
> >> > > > > best solution for the project.
> >> > > >
> >> > > > I think CTR doesn't mean that one can not ever ask for a code review
> >> > > upfront.
> >> > > > It's all about trusting the developers to do what's the best for the
> >> > > project
> >> > > > without hanging out high and dry in some obvious cases.
> >> > > >
> >> > > > > Getting a +1 is not only that a patch simply runs, it is about
> >> code
> >> > > style,
> >> > > > > architectural decisions. Even a one-liner patch can break
> >> designs.
> >> > > >
> >> > > > And that again falls back to the point of trusting the judgement of
> >> your
> >> > > peers
> >> > > > to do the "right thing" and come forward with the discussion before
> >> > > making the
> >> > > > changes that are questionable or contraversial. And we won't know
> >> if it
> >> > > works
> >> > > > before we try it at least for some time ;)
> >> > > >
> >> > > > Cos
> >> > > >
> >> > > > > I think a clear review guideline would help bigtop more that a
> >> commit
> >> > > > > policy change.
> >> > > > >
> >> > > > > Olaf
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > >
> >> > > >
> >> > >
> >>
> >
Re: To speed up the development: shall we become a CTR project?
Posted by Evans Ye <ev...@apache.org>.
Ofcourse if that doesnt fit we can roll back to RTC :)
2015年9月20日 上午3:20於 "Evans Ye" <ev...@apache.org>寫道：
> This is way better than mine!
> With practical use & try we can have concrete idea of how CTR works in our
> community. We can develop our policy to handle real world cases instead of
> just imaging it.
> 2015年9月20日 上午3:11於 "Konstantin Boudnik" <co...@apache.org>寫道：
>
>> I'd rather avoid or at least postpone the voting until we have everyone
>> being
>> comfortable with the proposed changed. I really don't like an idea of
>> someone
>> being in minority and being forced to play alone. On the other hand, I
>> see a
>> bunch of situations where CTR would be beneficial e.g BIGTOP-2057.
>>
>> If as Evans said all questions were answered, let's proceed to voting. If
>> not
>> - let's give CTR a try for say a couple of months and see how it works for
>> everybody. We hardly can do any irreversible harm even if we try - we can
>> always revert anything we don't like ;)
>>
>> Cos
>>
>> On Sun, Sep 20, 2015 at 01:52AM, Evans Ye wrote:
>> > To summarise this discussing thread, I think we have most of our team
>> > member supporting CTR model and questions from RTC advocates are
>> answered.
>> > I propose to start a vote to officially made decision wether or not to
>> > switch to CTR.
>> > If that passed, we then start drafting our CTR policy through
>> discussion.
>> > Any other thoughts?
>> >
>> > 2015-09-18 2:50 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
>> >
>> > > Can I ask RTC advocate to review a couple of patches to unblock me?
>> > >
>> > > BIGTOP-2025
>> > > BIGTOP-2051
>> > >
>> > > Thank you very much!
>> > > Cos
>> > >
>> > > On Mon, Sep 14, 2015 at 11:32AM, Konstantin Boudnik wrote:
>> > > > On Mon, Sep 14, 2015 at 07:35PM, Olaf Flebbe wrote:
>> > > > > Sorry, I haven't followed the initial discussion since I was not
>> > > onboard at that time.
>> > > > >
>> > > > > From my view bigtop is the fastest moving project, I ever knew. I
>> am
>> > > active
>> > > > > for over 20 years in all kinds of opensource projects, but bigtops
>> > > tops them
>> > > > > all in speed, second fastest maybe samba and linux kernel at 0.0x
>> > > >
>> > > > That's so good to hear! Made my day, if not the whole week! Speaks
>> tons
>> > > about
>> > > > the community we have on this project!
>> > > >
>> > > > > I am strongly oppose [i.e. -1] the CTR style, since I think the
>> > > project --
>> > > > > and myself -- take large benefits from discussions about
>> implementing
>> > > the
>> > > > > best solution for the project.
>> > > >
>> > > > I think CTR doesn't mean that one can not ever ask for a code review
>> > > upfront.
>> > > > It's all about trusting the developers to do what's the best for the
>> > > project
>> > > > without hanging out high and dry in some obvious cases.
>> > > >
>> > > > > Getting a +1 is not only that a patch simply runs, it is about
>> code
>> > > style,
>> > > > > architectural decisions. Even a one-liner patch can break
>> designs.
>> > > >
>> > > > And that again falls back to the point of trusting the judgement of
>> your
>> > > peers
>> > > > to do the "right thing" and come forward with the discussion before
>> > > making the
>> > > > changes that are questionable or contraversial. And we won't know
>> if it
>> > > works
>> > > > before we try it at least for some time ;)
>> > > >
>> > > > Cos
>> > > >
>> > > > > I think a clear review guideline would help bigtop more that a
>> commit
>> > > > > policy change.
>> > > > >
>> > > > > Olaf
>> > > > >
>> > > > >
>> > > > >
>> > > > >
>> > > >
>> > > >
>> > >
>>
>
Re: To speed up the development: shall we become a CTR project?
Posted by Evans Ye <ev...@apache.org>.
This is way better than mine!
With practical use & try we can have concrete idea of how CTR works in our
community. We can develop our policy to handle real world cases instead of
just imaging it.
2015年9月20日 上午3:11於 "Konstantin Boudnik" <co...@apache.org>寫道：
> I'd rather avoid or at least postpone the voting until we have everyone
> being
> comfortable with the proposed changed. I really don't like an idea of
> someone
> being in minority and being forced to play alone. On the other hand, I see
> a
> bunch of situations where CTR would be beneficial e.g BIGTOP-2057.
>
> If as Evans said all questions were answered, let's proceed to voting. If
> not
> - let's give CTR a try for say a couple of months and see how it works for
> everybody. We hardly can do any irreversible harm even if we try - we can
> always revert anything we don't like ;)
>
> Cos
>
> On Sun, Sep 20, 2015 at 01:52AM, Evans Ye wrote:
> > To summarise this discussing thread, I think we have most of our team
> > member supporting CTR model and questions from RTC advocates are
> answered.
> > I propose to start a vote to officially made decision wether or not to
> > switch to CTR.
> > If that passed, we then start drafting our CTR policy through discussion.
> > Any other thoughts?
> >
> > 2015-09-18 2:50 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> >
> > > Can I ask RTC advocate to review a couple of patches to unblock me?
> > >
> > > BIGTOP-2025
> > > BIGTOP-2051
> > >
> > > Thank you very much!
> > > Cos
> > >
> > > On Mon, Sep 14, 2015 at 11:32AM, Konstantin Boudnik wrote:
> > > > On Mon, Sep 14, 2015 at 07:35PM, Olaf Flebbe wrote:
> > > > > Sorry, I haven't followed the initial discussion since I was not
> > > onboard at that time.
> > > > >
> > > > > From my view bigtop is the fastest moving project, I ever knew. I
> am
> > > active
> > > > > for over 20 years in all kinds of opensource projects, but bigtops
> > > tops them
> > > > > all in speed, second fastest maybe samba and linux kernel at 0.0x
> > > >
> > > > That's so good to hear! Made my day, if not the whole week! Speaks
> tons
> > > about
> > > > the community we have on this project!
> > > >
> > > > > I am strongly oppose [i.e. -1] the CTR style, since I think the
> > > project --
> > > > > and myself -- take large benefits from discussions about
> implementing
> > > the
> > > > > best solution for the project.
> > > >
> > > > I think CTR doesn't mean that one can not ever ask for a code review
> > > upfront.
> > > > It's all about trusting the developers to do what's the best for the
> > > project
> > > > without hanging out high and dry in some obvious cases.
> > > >
> > > > > Getting a +1 is not only that a patch simply runs, it is about code
> > > style,
> > > > > architectural decisions. Even a one-liner patch can break designs.
> > > >
> > > > And that again falls back to the point of trusting the judgement of
> your
> > > peers
> > > > to do the "right thing" and come forward with the discussion before
> > > making the
> > > > changes that are questionable or contraversial. And we won't know if
> it
> > > works
> > > > before we try it at least for some time ;)
> > > >
> > > > Cos
> > > >
> > > > > I think a clear review guideline would help bigtop more that a
> commit
> > > > > policy change.
> > > > >
> > > > > Olaf
> > > > >
> > > > >
> > > > >
> > > > >
> > > >
> > > >
> > >
>
Re: To speed up the development: shall we become a CTR project?
Posted by Konstantin Boudnik <co...@apache.org>.
I'd rather avoid or at least postpone the voting until we have everyone being
comfortable with the proposed changed. I really don't like an idea of someone
being in minority and being forced to play alone. On the other hand, I see a
bunch of situations where CTR would be beneficial e.g BIGTOP-2057.
If as Evans said all questions were answered, let's proceed to voting. If not
- let's give CTR a try for say a couple of months and see how it works for
everybody. We hardly can do any irreversible harm even if we try - we can
always revert anything we don't like ;)
Cos
On Sun, Sep 20, 2015 at 01:52AM, Evans Ye wrote:
> To summarise this discussing thread, I think we have most of our team
> member supporting CTR model and questions from RTC advocates are answered.
> I propose to start a vote to officially made decision wether or not to
> switch to CTR.
> If that passed, we then start drafting our CTR policy through discussion.
> Any other thoughts?
>
> 2015-09-18 2:50 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
>
> > Can I ask RTC advocate to review a couple of patches to unblock me?
> >
> > BIGTOP-2025
> > BIGTOP-2051
> >
> > Thank you very much!
> > Cos
> >
> > On Mon, Sep 14, 2015 at 11:32AM, Konstantin Boudnik wrote:
> > > On Mon, Sep 14, 2015 at 07:35PM, Olaf Flebbe wrote:
> > > > Sorry, I haven't followed the initial discussion since I was not
> > onboard at that time.
> > > >
> > > > From my view bigtop is the fastest moving project, I ever knew. I am
> > active
> > > > for over 20 years in all kinds of opensource projects, but bigtops
> > tops them
> > > > all in speed, second fastest maybe samba and linux kernel at 0.0x
> > >
> > > That's so good to hear! Made my day, if not the whole week! Speaks tons
> > about
> > > the community we have on this project!
> > >
> > > > I am strongly oppose [i.e. -1] the CTR style, since I think the
> > project --
> > > > and myself -- take large benefits from discussions about implementing
> > the
> > > > best solution for the project.
> > >
> > > I think CTR doesn't mean that one can not ever ask for a code review
> > upfront.
> > > It's all about trusting the developers to do what's the best for the
> > project
> > > without hanging out high and dry in some obvious cases.
> > >
> > > > Getting a +1 is not only that a patch simply runs, it is about code
> > style,
> > > > architectural decisions. Even a one-liner patch can break designs.
> > >
> > > And that again falls back to the point of trusting the judgement of your
> > peers
> > > to do the "right thing" and come forward with the discussion before
> > making the
> > > changes that are questionable or contraversial. And we won't know if it
> > works
> > > before we try it at least for some time ;)
> > >
> > > Cos
> > >
> > > > I think a clear review guideline would help bigtop more that a commit
> > > > policy change.
> > > >
> > > > Olaf
> > > >
> > > >
> > > >
> > > >
> > >
> > >
> >
Re: To speed up the development: shall we become a CTR project?
Posted by Evans Ye <ev...@apache.org>.
To summarise this discussing thread, I think we have most of our team
member supporting CTR model and questions from RTC advocates are answered.
I propose to start a vote to officially made decision wether or not to
switch to CTR.
If that passed, we then start drafting our CTR policy through discussion.
Any other thoughts?
2015-09-18 2:50 GMT+08:00 Konstantin Boudnik <co...@apache.org>:
> Can I ask RTC advocate to review a couple of patches to unblock me?
>
> BIGTOP-2025
> BIGTOP-2051
>
> Thank you very much!
> Cos
>
> On Mon, Sep 14, 2015 at 11:32AM, Konstantin Boudnik wrote:
> > On Mon, Sep 14, 2015 at 07:35PM, Olaf Flebbe wrote:
> > > Sorry, I haven't followed the initial discussion since I was not
> onboard at that time.
> > >
> > > From my view bigtop is the fastest moving project, I ever knew. I am
> active
> > > for over 20 years in all kinds of opensource projects, but bigtops
> tops them
> > > all in speed, second fastest maybe samba and linux kernel at 0.0x
> >
> > That's so good to hear! Made my day, if not the whole week! Speaks tons
> about
> > the community we have on this project!
> >
> > > I am strongly oppose [i.e. -1] the CTR style, since I think the
> project --
> > > and myself -- take large benefits from discussions about implementing
> the
> > > best solution for the project.
> >
> > I think CTR doesn't mean that one can not ever ask for a code review
> upfront.
> > It's all about trusting the developers to do what's the best for the
> project
> > without hanging out high and dry in some obvious cases.
> >
> > > Getting a +1 is not only that a patch simply runs, it is about code
> style,
> > > architectural decisions. Even a one-liner patch can break designs.
> >
> > And that again falls back to the point of trusting the judgement of your
> peers
> > to do the "right thing" and come forward with the discussion before
> making the
> > changes that are questionable or contraversial. And we won't know if it
> works
> > before we try it at least for some time ;)
> >
> > Cos
> >
> > > I think a clear review guideline would help bigtop more that a commit
> > > policy change.
> > >
> > > Olaf
> > >
> > >
> > >
> > >
> >
> >
>
Re: To speed up the development: shall we become a CTR project?
Posted by Konstantin Boudnik <co...@apache.org>.
Can I ask RTC advocate to review a couple of patches to unblock me?
BIGTOP-2025
BIGTOP-2051
Thank you very much!
Cos
On Mon, Sep 14, 2015 at 11:32AM, Konstantin Boudnik wrote:
> On Mon, Sep 14, 2015 at 07:35PM, Olaf Flebbe wrote:
> > Sorry, I haven't followed the initial discussion since I was not onboard at that time.
> >
> > From my view bigtop is the fastest moving project, I ever knew. I am active
> > for over 20 years in all kinds of opensource projects, but bigtops tops them
> > all in speed, second fastest maybe samba and linux kernel at 0.0x
>
> That's so good to hear! Made my day, if not the whole week! Speaks tons about
> the community we have on this project!
>
> > I am strongly oppose [i.e. -1] the CTR style, since I think the project --
> > and myself -- take large benefits from discussions about implementing the
> > best solution for the project.
>
> I think CTR doesn't mean that one can not ever ask for a code review upfront.
> It's all about trusting the developers to do what's the best for the project
> without hanging out high and dry in some obvious cases.
>
> > Getting a +1 is not only that a patch simply runs, it is about code style,
> > architectural decisions. Even a one-liner patch can break designs.
>
> And that again falls back to the point of trusting the judgement of your peers
> to do the "right thing" and come forward with the discussion before making the
> changes that are questionable or contraversial. And we won't know if it works
> before we try it at least for some time ;)
>
> Cos
>
> > I think a clear review guideline would help bigtop more that a commit
> > policy change.
> >
> > Olaf
> >
> >
> >
> >
>
>
Re: To speed up the development: shall we become a CTR project?
Posted by Konstantin Boudnik <co...@apache.org>.
On Mon, Sep 14, 2015 at 07:35PM, Olaf Flebbe wrote:
> Sorry, I haven't followed the initial discussion since I was not onboard at that time.
>
> From my view bigtop is the fastest moving project, I ever knew. I am active
> for over 20 years in all kinds of opensource projects, but bigtops tops them
> all in speed, second fastest maybe samba and linux kernel at 0.0x
That's so good to hear! Made my day, if not the whole week! Speaks tons about
the community we have on this project!
> I am strongly oppose [i.e. -1] the CTR style, since I think the project --
> and myself -- take large benefits from discussions about implementing the
> best solution for the project.
I think CTR doesn't mean that one can not ever ask for a code review upfront.
It's all about trusting the developers to do what's the best for the project
without hanging out high and dry in some obvious cases.
> Getting a +1 is not only that a patch simply runs, it is about code style,
> architectural decisions. Even a one-liner patch can break designs.
And that again falls back to the point of trusting the judgement of your peers
to do the "right thing" and come forward with the discussion before making the
changes that are questionable or contraversial. And we won't know if it works
before we try it at least for some time ;)
Cos
> I think a clear review guideline would help bigtop more that a commit
> policy change.
>
> Olaf
>
>
>
>
Re: To speed up the development: shall we become a CTR project?
Posted by Olaf Flebbe <of...@oflebbe.de>.
Sorry, I haven't followed the initial discussion since I was not onboard at that time.
From my view bigtop is the fastest moving project, I ever knew. I am active for over 20 years in all kinds of opensource projects, but bigtops tops them all in speed, second fastest maybe samba and linux kernel at 0.0x
I am strongly oppose [i.e. -1] the CTR style, since I think the project -- and myself -- take large benefits from discussions about implementing the best solution for the project.
Getting a +1 is not only that a patch simply runs, it is about code style, architectural decisions. Even a one-liner patch can break designs.
I think a clear review guideline would help bigtop more that a commit policy change.
Olaf
Re: To speed up the development: shall we become a CTR project?
Posted by Konstantin Boudnik <co...@apache.org>.
That's be incredible helpful! Thanks you Andrew!
On Mon, Sep 14, 2015 at 10:33AM, Andrew Musselman wrote:
> If you guys are looking for some help with
> https://issues.apache.org/jira/browse/BIGTOP-1249 I will ask around at work
> to see who might have the interest and bandwidth.
>
> On Mon, Sep 14, 2015 at 10:00 AM, Andrew Purtell <an...@gmail.com>
> wrote:
>
> > Just to be clear I didn't simply describe what the HBase community is
> > doing in this regard but also submitted those ideas for consideration here.
> > I could make the same dismissive statement about your pointer to the Ignite
> > lists.
> >
> >
> > > On Sep 14, 2015, at 9:54 AM, Konstantin Boudnik <co...@apache.org> wrote:
> > >
> > > What Andrew describes is a good step forward CTR process and I am sure
> > HBase
> > > community will find a process that works for them the best. I still
> > think CTR
> > > and yet another step further. I believe if a person has commit-bit it is,
> > > essentially, means that his judgement is trusted and he knows what's
> > good to
> > > the project and won't hurt the code intentionally. Mistakes will be
> > happening
> > > under either of the processes. But the trust in your community fellows
> > goes
> > > long way, I think.
> > >
> > > We had this discussion on Ignite dev@ list just about a month ago [1].
> > And all
> > > sorts of arguments were expressed there, and I'd encourage everyone to
> > spend
> > > a little bit of time reviewing it. The great points were made by Brane
> > [2],
> > > [3], and [4]. They aren't that long and esp. [3] is very deep, in my
> > option.
> > >
> > > Considering that I really agree with what Brane and myself (doug ;) have
> > said
> > > on that thread I won't repeat myself here, but just ask to look at the
> > last
> > > three emails from below.
> > >
> > > BTW, Ignite is on the CTR process for about a month now - nothing morbid
> > had
> > > happened to it. And the rate of the development in this project is pretty
> > > high, actually.
> > >
> > > Thanks,
> > > Cos
> > >
> > > [1]
> > http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1822.html
> > >
> > > [2]
> > http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1850.html
> > > [3]
> > http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1885.html
> > > [4]
> > http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1859.html
> > >
> > >> On Mon, Sep 14, 2015 at 08:51AM, Andrew Purtell wrote:
> > >> I made this argument over on the dev@hbase list: If the community
> > considers
> > >> quality a priority (and we do, right? (Smile)) then we should have a
> > strong
> > >> code review ethic whether technically bound to have one (RTC) or not
> > (CTR).
> > >>
> > >> I started a discussion to move over to CTR on HBase because some
> > components
> > >> or niche concerns don't draw prompt reviews, slowing down the
> > >> contributor/committer because their next steps depend on the current
> > patch.
> > >> We had this discussion on our dev@ list. You can find it in the public
> > >> archives if curious. However I was mostly convinced we have sufficient
> > tools
> > >> without CTR so that's not necessary, eg: - Any committer can check
> > anything
> > >> into a dev branch (non release branch) without review; review comes
> > later at
> > >> the branch merge vote. Haven't checked if we have a branch merge
> > policy. We
> > >> can always add one.
> > >> - Small fixes or test only changes are given leeway to the committer's
> > >> discretion. Try to wait long enough if a volunteer wants to show up and
> > do a
> > >> review. - We have an informal consensus practice where as long as the
> > >> change doesn't have major impact (again, committer discretion) then
> > after an
> > >> issue sits a day or two one might post "going to commit this later today
> > >> unless objection" - and, if no objection, this is a "lazy review" and
> > >> commit.
> > >>
> > >> For your consideration.
> > >>
> > >>
> > >>> On Sep 14, 2015, at 7:33 AM, RJ Nowling <rn...@gmail.com> wrote:
> > >>>
> > >>> I don't want to derail this decision if CTR has general approval. I
> > would
> > >>> be happy with a clear checklist document that we can all agree to
> > follow
> > >>> before commits.
> > >>>
> > >>> On Mon, Sep 14, 2015 at 9:24 AM, jay vyas <jayunit100.apache@gmail.com
> > >
> > >>> wrote:
> > >>>
> > >>>> i think we moved this discussion here
> > >>>> https://issues.apache.org/jira/browse/BIGTOP-1249
> > >>>>
> > >>>> The goal is definetely to get automated reviews.
> > >>>>
> > >>>> we hacked around successfully with some prototypes but never
> > productionized
> > >>>> them.
> > >>>>
> >
Re: To speed up the development: shall we become a CTR project?
Posted by Konstantin Boudnik <co...@apache.org>.
On Mon, Sep 14, 2015 at 10:00AM, Andrew Purtell wrote:
> Just to be clear I didn't simply describe what the HBase community is doing
> in this regard but also submitted those ideas for consideration here. I
> could make the same dismissive statement about your pointer to the Ignite
> lists.
Andrew, it wasn't dismissive and wasn't really triggered by your reply. Now
reading the first sentence of my reply below I can see why it could be
considered dismissive. But may be I deserved a bit of benefit of a doubt?
Any way, I actually didn't see much value in copy-pasting all the threads from
that list, which is already publicly available. You made the same referral to
the dev@hbase, except that I have actually provided the links ;)
> > On Sep 14, 2015, at 9:54 AM, Konstantin Boudnik <co...@apache.org> wrote:
> >
> > What Andrew describes is a good step forward CTR process and I am sure HBase
> > community will find a process that works for them the best. I still think CTR
> > and yet another step further. I believe if a person has commit-bit it is,
> > essentially, means that his judgement is trusted and he knows what's good to
> > the project and won't hurt the code intentionally. Mistakes will be happening
> > under either of the processes. But the trust in your community fellows goes
> > long way, I think.
> >
> > We had this discussion on Ignite dev@ list just about a month ago [1]. And all
> > sorts of arguments were expressed there, and I'd encourage everyone to spend
> > a little bit of time reviewing it. The great points were made by Brane [2],
> > [3], and [4]. They aren't that long and esp. [3] is very deep, in my option.
> >
> > Considering that I really agree with what Brane and myself (doug ;) have said
> > on that thread I won't repeat myself here, but just ask to look at the last
> > three emails from below.
> >
> > BTW, Ignite is on the CTR process for about a month now - nothing morbid had
> > happened to it. And the rate of the development in this project is pretty
> > high, actually.
> >
> > Thanks,
> > Cos
> >
> > [1] http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1822.html
> >
> > [2] http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1850.html
> > [3] http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1885.html
> > [4] http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1859.html
> >
> >> On Mon, Sep 14, 2015 at 08:51AM, Andrew Purtell wrote:
> >> I made this argument over on the dev@hbase list: If the community considers
> >> quality a priority (and we do, right? (Smile)) then we should have a strong
> >> code review ethic whether technically bound to have one (RTC) or not (CTR).
> >>
> >> I started a discussion to move over to CTR on HBase because some components
> >> or niche concerns don't draw prompt reviews, slowing down the
> >> contributor/committer because their next steps depend on the current patch.
> >> We had this discussion on our dev@ list. You can find it in the public
> >> archives if curious. However I was mostly convinced we have sufficient tools
> >> without CTR so that's not necessary, eg: - Any committer can check anything
> >> into a dev branch (non release branch) without review; review comes later at
> >> the branch merge vote. Haven't checked if we have a branch merge policy. We
> >> can always add one.
> >> - Small fixes or test only changes are given leeway to the committer's
> >> discretion. Try to wait long enough if a volunteer wants to show up and do a
> >> review. - We have an informal consensus practice where as long as the
> >> change doesn't have major impact (again, committer discretion) then after an
> >> issue sits a day or two one might post "going to commit this later today
> >> unless objection" - and, if no objection, this is a "lazy review" and
> >> commit.
> >>
> >> For your consideration.
> >>
> >>
> >>> On Sep 14, 2015, at 7:33 AM, RJ Nowling <rn...@gmail.com> wrote:
> >>>
> >>> I don't want to derail this decision if CTR has general approval. I would
> >>> be happy with a clear checklist document that we can all agree to follow
> >>> before commits.
> >>>
> >>> On Mon, Sep 14, 2015 at 9:24 AM, jay vyas <ja...@gmail.com>
> >>> wrote:
> >>>
> >>>> i think we moved this discussion here
> >>>> https://issues.apache.org/jira/browse/BIGTOP-1249
> >>>>
> >>>> The goal is definetely to get automated reviews.
> >>>>
> >>>> we hacked around successfully with some prototypes but never productionized
> >>>> them.
> >>>>
Re: To speed up the development: shall we become a CTR project?
Posted by Konstantin Boudnik <co...@apache.org>.
On Tue, Sep 15, 2015 at 08:43PM, Evans Ye wrote:
> There're some points made by Olaf and I think they're valuable. But I think
> we can get the benefit of reviewing process by applying some policy to our
> CTR.
>
> For example, one is forced to drop a patch on JIRA and wait for a certain
> while before commit.
> Someone interested in it may take a look at patch and left a comment.
> Comments need to be addressed as well as consensus should be reached then a
> patch can be committed.
Similar logic can be applied in the opposite direction: if someone make a
commit that breaks something he will be responsible to address the issues.
If a commit is made that is suboptimal from the design standpoint and others
have pointed to it - the commit can be reversed. We use a version control
after all, so no changes are irreversible.
> The benefit of CTR to me is that some minor improvement or bugfix that do
> not have design issue can be fixed earlier and then things can move
> forward. I see sometimes patch get stalled and no one is looking into it,
> which is sort of depressing to either committer or contributor who creates
> it. But I do know everyone is busy and we might just being lack of
> resources. If we adopt CTR and committers' load can be alleviated. We can
> spend time on things that need to be discussed more. We can spend time
> helping more contributors on board.
Hear, hear! Given that CTR will require us to be thorough when we are inviting
new committers and make sure that we extend the commit-bit to people who
aren't just shooting from the hip. But that's a little price to pay, in my
opinion.
> Getting back to CI, maybe this is a good chance to improve it based on what
> we really need in the field by adopting CTR. What I mean is what I proposed
> earlier might looks like the best case for our CI, but maybe there're
> something we don't really need that much. So, if we have our CI at least
> cover all the major functionality, then we should be good to go.
+1
>
> Evans
> 2015年9月15日 上午6:07於 "Andrew Purtell" <ap...@apache.org>寫道：
>
> > Yes, please! :-)
> >
> > On Mon, Sep 14, 2015 at 10:33 AM, Andrew Musselman <
> > andrew.musselman@gmail.com> wrote:
> >
> > > If you guys are looking for some help with
> > > https://issues.apache.org/jira/browse/BIGTOP-1249 I will ask around at
> > > work
> > > to see who might have the interest and bandwidth.
> > >
> > > On Mon, Sep 14, 2015 at 10:00 AM, Andrew Purtell <
> > andrew.purtell@gmail.com
> > > >
> > > wrote:
> > >
> > > > Just to be clear I didn't simply describe what the HBase community is
> > > > doing in this regard but also submitted those ideas for consideration
> > > here.
> > > > I could make the same dismissive statement about your pointer to the
> > > Ignite
> > > > lists.
> > > >
> > > >
> > > > > On Sep 14, 2015, at 9:54 AM, Konstantin Boudnik <co...@apache.org>
> > > wrote:
> > > > >
> > > > > What Andrew describes is a good step forward CTR process and I am
> > sure
> > > > HBase
> > > > > community will find a process that works for them the best. I still
> > > > think CTR
> > > > > and yet another step further. I believe if a person has commit-bit it
> > > is,
> > > > > essentially, means that his judgement is trusted and he knows what's
> > > > good to
> > > > > the project and won't hurt the code intentionally. Mistakes will be
> > > > happening
> > > > > under either of the processes. But the trust in your community
> > fellows
> > > > goes
> > > > > long way, I think.
> > > > >
> > > > > We had this discussion on Ignite dev@ list just about a month ago
> > [1].
> > > > And all
> > > > > sorts of arguments were expressed there, and I'd encourage everyone
> > to
> > > > spend
> > > > > a little bit of time reviewing it. The great points were made by
> > Brane
> > > > [2],
> > > > > [3], and [4]. They aren't that long and esp. [3] is very deep, in my
> > > > option.
> > > > >
> > > > > Considering that I really agree with what Brane and myself (doug ;)
> > > have
> > > > said
> > > > > on that thread I won't repeat myself here, but just ask to look at
> > the
> > > > last
> > > > > three emails from below.
> > > > >
> > > > > BTW, Ignite is on the CTR process for about a month now - nothing
> > > morbid
> > > > had
> > > > > happened to it. And the rate of the development in this project is
> > > pretty
> > > > > high, actually.
> > > > >
> > > > > Thanks,
> > > > > Cos
> > > > >
> > > > > [1]
> > > >
> > >
> > http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1822.html
> > > > >
> > > > > [2]
> > > >
> > >
> > http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1850.html
> > > > > [3]
> > > >
> > >
> > http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1885.html
> > > > > [4]
> > > >
> > >
> > http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1859.html
> > > > >
> > > > >> On Mon, Sep 14, 2015 at 08:51AM, Andrew Purtell wrote:
> > > > >> I made this argument over on the dev@hbase list: If the community
> > > > considers
> > > > >> quality a priority (and we do, right? (Smile)) then we should have a
> > > > strong
> > > > >> code review ethic whether technically bound to have one (RTC) or not
> > > > (CTR).
> > > > >>
> > > > >> I started a discussion to move over to CTR on HBase because some
> > > > components
> > > > >> or niche concerns don't draw prompt reviews, slowing down the
> > > > >> contributor/committer because their next steps depend on the current
> > > > patch.
> > > > >> We had this discussion on our dev@ list. You can find it in the
> > > public
> > > > >> archives if curious. However I was mostly convinced we have
> > sufficient
> > > > tools
> > > > >> without CTR so that's not necessary, eg: - Any committer can check
> > > > anything
> > > > >> into a dev branch (non release branch) without review; review comes
> > > > later at
> > > > >> the branch merge vote. Haven't checked if we have a branch merge
> > > > policy. We
> > > > >> can always add one.
> > > > >> - Small fixes or test only changes are given leeway to the
> > committer's
> > > > >> discretion. Try to wait long enough if a volunteer wants to show up
> > > and
> > > > do a
> > > > >> review. - We have an informal consensus practice where as long as
> > the
> > > > >> change doesn't have major impact (again, committer discretion) then
> > > > after an
> > > > >> issue sits a day or two one might post "going to commit this later
> > > today
> > > > >> unless objection" - and, if no objection, this is a "lazy review"
> > and
> > > > >> commit.
> > > > >>
> > > > >> For your consideration.
> > > > >>
> > > > >>
> > > > >>> On Sep 14, 2015, at 7:33 AM, RJ Nowling <rn...@gmail.com>
> > wrote:
> > > > >>>
> > > > >>> I don't want to derail this decision if CTR has general approval.
> > I
> > > > would
> > > > >>> be happy with a clear checklist document that we can all agree to
> > > > follow
> > > > >>> before commits.
> > > > >>>
> > > > >>> On Mon, Sep 14, 2015 at 9:24 AM, jay vyas <
> > > jayunit100.apache@gmail.com
> > > > >
> > > > >>> wrote:
> > > > >>>
> > > > >>>> i think we moved this discussion here
> > > > >>>> https://issues.apache.org/jira/browse/BIGTOP-1249
> > > > >>>>
> > > > >>>> The goal is definetely to get automated reviews.
> > > > >>>>
> > > > >>>> we hacked around successfully with some prototypes but never
> > > > productionized
> > > > >>>> them.
> > > > >>>>
> > > >
> > >
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein
> > (via Tom White)
> >
Re: To speed up the development: shall we become a CTR project?
Posted by Andrew Musselman <an...@gmail.com>.
Sounds great; thanks all.
On Mon, Sep 14, 2015 at 11:15 AM, Jay Vyas <ja...@gmail.com>
wrote:
> Thanks Andrew. As per our conversation on Twitter it will be exciting to
> add more engineers to the maintainable of the automated patch reviews. We
> can help provide feedback on getting started, of course.
>
> Just have your guys ping us on the mailing list and we will maybe schedule
> a google hangout to discuss the best way to setup automation.
>
> > On Sep 14, 2015, at 1:33 PM, Andrew Musselman <
> andrew.musselman@gmail.com> wrote:
> >
> > If you guys are looking for some help with
> > https://issues.apache.org/jira/browse/BIGTOP-1249 I will ask around at
> work
> > to see who might have the interest and bandwidth.
> >
> > On Mon, Sep 14, 2015 at 10:00 AM, Andrew Purtell <
> andrew.purtell@gmail.com>
> > wrote:
> >
> >> Just to be clear I didn't simply describe what the HBase community is
> >> doing in this regard but also submitted those ideas for consideration
> here.
> >> I could make the same dismissive statement about your pointer to the
> Ignite
> >> lists.
> >>
> >>
> >>> On Sep 14, 2015, at 9:54 AM, Konstantin Boudnik <co...@apache.org>
> wrote:
> >>>
> >>> What Andrew describes is a good step forward CTR process and I am sure
> >> HBase
> >>> community will find a process that works for them the best. I still
> >> think CTR
> >>> and yet another step further. I believe if a person has commit-bit it
> is,
> >>> essentially, means that his judgement is trusted and he knows what's
> >> good to
> >>> the project and won't hurt the code intentionally. Mistakes will be
> >> happening
> >>> under either of the processes. But the trust in your community fellows
> >> goes
> >>> long way, I think.
> >>>
> >>> We had this discussion on Ignite dev@ list just about a month ago [1].
> >> And all
> >>> sorts of arguments were expressed there, and I'd encourage everyone to
> >> spend
> >>> a little bit of time reviewing it. The great points were made by Brane
> >> [2],
> >>> [3], and [4]. They aren't that long and esp. [3] is very deep, in my
> >> option.
> >>>
> >>> Considering that I really agree with what Brane and myself (doug ;)
> have
> >> said
> >>> on that thread I won't repeat myself here, but just ask to look at the
> >> last
> >>> three emails from below.
> >>>
> >>> BTW, Ignite is on the CTR process for about a month now - nothing
> morbid
> >> had
> >>> happened to it. And the rate of the development in this project is
> pretty
> >>> high, actually.
> >>>
> >>> Thanks,
> >>> Cos
> >>>
> >>> [1]
> >>
> http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1822.html
> >>>
> >>> [2]
> >>
> http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1850.html
> >>> [3]
> >>
> http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1885.html
> >>> [4]
> >>
> http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1859.html
> >>>
> >>>> On Mon, Sep 14, 2015 at 08:51AM, Andrew Purtell wrote:
> >>>> I made this argument over on the dev@hbase list: If the community
> >> considers
> >>>> quality a priority (and we do, right? (Smile)) then we should have a
> >> strong
> >>>> code review ethic whether technically bound to have one (RTC) or not
> >> (CTR).
> >>>>
> >>>> I started a discussion to move over to CTR on HBase because some
> >> components
> >>>> or niche concerns don't draw prompt reviews, slowing down the
> >>>> contributor/committer because their next steps depend on the current
> >> patch.
> >>>> We had this discussion on our dev@ list. You can find it in the
> public
> >>>> archives if curious. However I was mostly convinced we have sufficient
> >> tools
> >>>> without CTR so that's not necessary, eg: - Any committer can check
> >> anything
> >>>> into a dev branch (non release branch) without review; review comes
> >> later at
> >>>> the branch merge vote. Haven't checked if we have a branch merge
> >> policy. We
> >>>> can always add one.
> >>>> - Small fixes or test only changes are given leeway to the committer's
> >>>> discretion. Try to wait long enough if a volunteer wants to show up
> and
> >> do a
> >>>> review. - We have an informal consensus practice where as long as the
> >>>> change doesn't have major impact (again, committer discretion) then
> >> after an
> >>>> issue sits a day or two one might post "going to commit this later
> today
> >>>> unless objection" - and, if no objection, this is a "lazy review" and
> >>>> commit.
> >>>>
> >>>> For your consideration.
> >>>>
> >>>>
> >>>>> On Sep 14, 2015, at 7:33 AM, RJ Nowling <rn...@gmail.com> wrote:
> >>>>>
> >>>>> I don't want to derail this decision if CTR has general approval. I
> >> would
> >>>>> be happy with a clear checklist document that we can all agree to
> >> follow
> >>>>> before commits.
> >>>>>
> >>>>> On Mon, Sep 14, 2015 at 9:24 AM, jay vyas <
> jayunit100.apache@gmail.com
> >>>
> >>>>> wrote:
> >>>>>
> >>>>>> i think we moved this discussion here
> >>>>>> https://issues.apache.org/jira/browse/BIGTOP-1249
> >>>>>>
> >>>>>> The goal is definetely to get automated reviews.
> >>>>>>
> >>>>>> we hacked around successfully with some prototypes but never
> >> productionized
> >>>>>> them.
> >>
>
Re: To speed up the development: shall we become a CTR project?
Posted by Jay Vyas <ja...@gmail.com>.
Thanks Andrew. As per our conversation on Twitter it will be exciting to add more engineers to the maintainable of the automated patch reviews. We can help provide feedback on getting started, of course.
Just have your guys ping us on the mailing list and we will maybe schedule a google hangout to discuss the best way to setup automation.
> On Sep 14, 2015, at 1:33 PM, Andrew Musselman <an...@gmail.com> wrote:
>
> If you guys are looking for some help with
> https://issues.apache.org/jira/browse/BIGTOP-1249 I will ask around at work
> to see who might have the interest and bandwidth.
>
> On Mon, Sep 14, 2015 at 10:00 AM, Andrew Purtell <an...@gmail.com>
> wrote:
>
>> Just to be clear I didn't simply describe what the HBase community is
>> doing in this regard but also submitted those ideas for consideration here.
>> I could make the same dismissive statement about your pointer to the Ignite
>> lists.
>>
>>
>>> On Sep 14, 2015, at 9:54 AM, Konstantin Boudnik <co...@apache.org> wrote:
>>>
>>> What Andrew describes is a good step forward CTR process and I am sure
>> HBase
>>> community will find a process that works for them the best. I still
>> think CTR
>>> and yet another step further. I believe if a person has commit-bit it is,
>>> essentially, means that his judgement is trusted and he knows what's
>> good to
>>> the project and won't hurt the code intentionally. Mistakes will be
>> happening
>>> under either of the processes. But the trust in your community fellows
>> goes
>>> long way, I think.
>>>
>>> We had this discussion on Ignite dev@ list just about a month ago [1].
>> And all
>>> sorts of arguments were expressed there, and I'd encourage everyone to
>> spend
>>> a little bit of time reviewing it. The great points were made by Brane
>> [2],
>>> [3], and [4]. They aren't that long and esp. [3] is very deep, in my
>> option.
>>>
>>> Considering that I really agree with what Brane and myself (doug ;) have
>> said
>>> on that thread I won't repeat myself here, but just ask to look at the
>> last
>>> three emails from below.
>>>
>>> BTW, Ignite is on the CTR process for about a month now - nothing morbid
>> had
>>> happened to it. And the rate of the development in this project is pretty
>>> high, actually.
>>>
>>> Thanks,
>>> Cos
>>>
>>> [1]
>> http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1822.html
>>>
>>> [2]
>> http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1850.html
>>> [3]
>> http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1885.html
>>> [4]
>> http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1859.html
>>>
>>>> On Mon, Sep 14, 2015 at 08:51AM, Andrew Purtell wrote:
>>>> I made this argument over on the dev@hbase list: If the community
>> considers
>>>> quality a priority (and we do, right? (Smile)) then we should have a
>> strong
>>>> code review ethic whether technically bound to have one (RTC) or not
>> (CTR).
>>>>
>>>> I started a discussion to move over to CTR on HBase because some
>> components
>>>> or niche concerns don't draw prompt reviews, slowing down the
>>>> contributor/committer because their next steps depend on the current
>> patch.
>>>> We had this discussion on our dev@ list. You can find it in the public
>>>> archives if curious. However I was mostly convinced we have sufficient
>> tools
>>>> without CTR so that's not necessary, eg: - Any committer can check
>> anything
>>>> into a dev branch (non release branch) without review; review comes
>> later at
>>>> the branch merge vote. Haven't checked if we have a branch merge
>> policy. We
>>>> can always add one.
>>>> - Small fixes or test only changes are given leeway to the committer's
>>>> discretion. Try to wait long enough if a volunteer wants to show up and
>> do a
>>>> review. - We have an informal consensus practice where as long as the
>>>> change doesn't have major impact (again, committer discretion) then
>> after an
>>>> issue sits a day or two one might post "going to commit this later today
>>>> unless objection" - and, if no objection, this is a "lazy review" and
>>>> commit.
>>>>
>>>> For your consideration.
>>>>
>>>>
>>>>> On Sep 14, 2015, at 7:33 AM, RJ Nowling <rn...@gmail.com> wrote:
>>>>>
>>>>> I don't want to derail this decision if CTR has general approval. I
>> would
>>>>> be happy with a clear checklist document that we can all agree to
>> follow
>>>>> before commits.
>>>>>
>>>>> On Mon, Sep 14, 2015 at 9:24 AM, jay vyas <jayunit100.apache@gmail.com
>>>
>>>>> wrote:
>>>>>
>>>>>> i think we moved this discussion here
>>>>>> https://issues.apache.org/jira/browse/BIGTOP-1249
>>>>>>
>>>>>> The goal is definetely to get automated reviews.
>>>>>>
>>>>>> we hacked around successfully with some prototypes but never
>> productionized
>>>>>> them.
>>
Re: To speed up the development: shall we become a CTR project?
Posted by Olaf Flebbe <of...@oflebbe.de>.
Hi,
Evans is adressing my concerns very well.
Olaf
> Am 15.09.2015 um 14:43 schrieb Evans Ye <ev...@apache.org>:
>
> There're some points made by Olaf and I think they're valuable. But I think
> we can get the benefit of reviewing process by applying some policy to our
> CTR.
>
> For example, one is forced to drop a patch on JIRA and wait for a certain
> while before commit.
> Someone interested in it may take a look at patch and left a comment.
> Comments need to be addressed as well as consensus should be reached then a
> patch can be committed.
>
> The benefit of CTR to me is that some minor improvement or bugfix that do
> not have design issue can be fixed earlier and then things can move
> forward. I see sometimes patch get stalled and no one is looking into it,
> which is sort of depressing to either committer or contributor who creates
> it. But I do know everyone is busy and we might just being lack of
> resources. If we adopt CTR and committers' load can be alleviated. We can
> spend time on things that need to be discussed more. We can spend time
> helping more contributors on board.
>
> Getting back to CI, maybe this is a good chance to improve it based on what
> we really need in the field by adopting CTR. What I mean is what I proposed
> earlier might looks like the best case for our CI, but maybe there're
> something we don't really need that much. So, if we have our CI at least
> cover all the major functionality, then we should be good to go.
>
> Evans
> 2015年9月15日 上午6:07於 "Andrew Purtell" <ap...@apache.org>寫道：
>
>> Yes, please! :-)
>>
>> On Mon, Sep 14, 2015 at 10:33 AM, Andrew Musselman <
>> andrew.musselman@gmail.com> wrote:
>>
>>> If you guys are looking for some help with
>>> https://issues.apache.org/jira/browse/BIGTOP-1249 I will ask around at
>>> work
>>> to see who might have the interest and bandwidth.
>>>
>>> On Mon, Sep 14, 2015 at 10:00 AM, Andrew Purtell <
>> andrew.purtell@gmail.com
>>>>
>>> wrote:
>>>
>>>> Just to be clear I didn't simply describe what the HBase community is
>>>> doing in this regard but also submitted those ideas for consideration
>>> here.
>>>> I could make the same dismissive statement about your pointer to the
>>> Ignite
>>>> lists.
>>>>
>>>>
>>>>> On Sep 14, 2015, at 9:54 AM, Konstantin Boudnik <co...@apache.org>
>>> wrote:
>>>>>
>>>>> What Andrew describes is a good step forward CTR process and I am
>> sure
>>>> HBase
>>>>> community will find a process that works for them the best. I still
>>>> think CTR
>>>>> and yet another step further. I believe if a person has commit-bit it
>>> is,
>>>>> essentially, means that his judgement is trusted and he knows what's
>>>> good to
>>>>> the project and won't hurt the code intentionally. Mistakes will be
>>>> happening
>>>>> under either of the processes. But the trust in your community
>> fellows
>>>> goes
>>>>> long way, I think.
>>>>>
>>>>> We had this discussion on Ignite dev@ list just about a month ago
>> [1].
>>>> And all
>>>>> sorts of arguments were expressed there, and I'd encourage everyone
>> to
>>>> spend
>>>>> a little bit of time reviewing it. The great points were made by
>> Brane
>>>> [2],
>>>>> [3], and [4]. They aren't that long and esp. [3] is very deep, in my
>>>> option.
>>>>>
>>>>> Considering that I really agree with what Brane and myself (doug ;)
>>> have
>>>> said
>>>>> on that thread I won't repeat myself here, but just ask to look at
>> the
>>>> last
>>>>> three emails from below.
>>>>>
>>>>> BTW, Ignite is on the CTR process for about a month now - nothing
>>> morbid
>>>> had
>>>>> happened to it. And the rate of the development in this project is
>>> pretty
>>>>> high, actually.
>>>>>
>>>>> Thanks,
>>>>> Cos
>>>>>
>>>>> [1]
>>>>
>>>
>> http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1822.html
>>>>>
>>>>> [2]
>>>>
>>>
>> http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1850.html
>>>>> [3]
>>>>
>>>
>> http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1885.html
>>>>> [4]
>>>>
>>>
>> http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1859.html
>>>>>
>>>>>> On Mon, Sep 14, 2015 at 08:51AM, Andrew Purtell wrote:
>>>>>> I made this argument over on the dev@hbase list: If the community
>>>> considers
>>>>>> quality a priority (and we do, right? (Smile)) then we should have a
>>>> strong
>>>>>> code review ethic whether technically bound to have one (RTC) or not
>>>> (CTR).
>>>>>>
>>>>>> I started a discussion to move over to CTR on HBase because some
>>>> components
>>>>>> or niche concerns don't draw prompt reviews, slowing down the
>>>>>> contributor/committer because their next steps depend on the current
>>>> patch.
>>>>>> We had this discussion on our dev@ list. You can find it in the
>>> public
>>>>>> archives if curious. However I was mostly convinced we have
>> sufficient
>>>> tools
>>>>>> without CTR so that's not necessary, eg: - Any committer can check
>>>> anything
>>>>>> into a dev branch (non release branch) without review; review comes
>>>> later at
>>>>>> the branch merge vote. Haven't checked if we have a branch merge
>>>> policy. We
>>>>>> can always add one.
>>>>>> - Small fixes or test only changes are given leeway to the
>> committer's
>>>>>> discretion. Try to wait long enough if a volunteer wants to show up
>>> and
>>>> do a
>>>>>> review. - We have an informal consensus practice where as long as
>> the
>>>>>> change doesn't have major impact (again, committer discretion) then
>>>> after an
>>>>>> issue sits a day or two one might post "going to commit this later
>>> today
>>>>>> unless objection" - and, if no objection, this is a "lazy review"
>> and
>>>>>> commit.
>>>>>>
>>>>>> For your consideration.
>>>>>>
>>>>>>
>>>>>>> On Sep 14, 2015, at 7:33 AM, RJ Nowling <rn...@gmail.com>
>> wrote:
>>>>>>>
>>>>>>> I don't want to derail this decision if CTR has general approval.
>> I
>>>> would
>>>>>>> be happy with a clear checklist document that we can all agree to
>>>> follow
>>>>>>> before commits.
>>>>>>>
>>>>>>> On Mon, Sep 14, 2015 at 9:24 AM, jay vyas <
>>> jayunit100.apache@gmail.com
>>>>>
>>>>>>> wrote:
>>>>>>>
>>>>>>>> i think we moved this discussion here
>>>>>>>> https://issues.apache.org/jira/browse/BIGTOP-1249
>>>>>>>>
>>>>>>>> The goal is definetely to get automated reviews.
>>>>>>>>
>>>>>>>> we hacked around successfully with some prototypes but never
>>>> productionized
>>>>>>>> them.
>>>>>>>>
>>>>
>>>
>>
>>
>>
>> --
>> Best regards,
>>
>> - Andy
>>
>> Problems worthy of attack prove their worth by hitting back. - Piet Hein
>> (via Tom White)
>>
Re: To speed up the development: shall we become a CTR project?
Posted by Evans Ye <ev...@apache.org>.
There're some points made by Olaf and I think they're valuable. But I think
we can get the benefit of reviewing process by applying some policy to our
CTR.
For example, one is forced to drop a patch on JIRA and wait for a certain
while before commit.
Someone interested in it may take a look at patch and left a comment.
Comments need to be addressed as well as consensus should be reached then a
patch can be committed.
The benefit of CTR to me is that some minor improvement or bugfix that do
not have design issue can be fixed earlier and then things can move
forward. I see sometimes patch get stalled and no one is looking into it,
which is sort of depressing to either committer or contributor who creates
it. But I do know everyone is busy and we might just being lack of
resources. If we adopt CTR and committers' load can be alleviated. We can
spend time on things that need to be discussed more. We can spend time
helping more contributors on board.
Getting back to CI, maybe this is a good chance to improve it based on what
we really need in the field by adopting CTR. What I mean is what I proposed
earlier might looks like the best case for our CI, but maybe there're
something we don't really need that much. So, if we have our CI at least
cover all the major functionality, then we should be good to go.
Evans
2015年9月15日 上午6:07於 "Andrew Purtell" <ap...@apache.org>寫道：
> Yes, please! :-)
>
> On Mon, Sep 14, 2015 at 10:33 AM, Andrew Musselman <
> andrew.musselman@gmail.com> wrote:
>
> > If you guys are looking for some help with
> > https://issues.apache.org/jira/browse/BIGTOP-1249 I will ask around at
> > work
> > to see who might have the interest and bandwidth.
> >
> > On Mon, Sep 14, 2015 at 10:00 AM, Andrew Purtell <
> andrew.purtell@gmail.com
> > >
> > wrote:
> >
> > > Just to be clear I didn't simply describe what the HBase community is
> > > doing in this regard but also submitted those ideas for consideration
> > here.
> > > I could make the same dismissive statement about your pointer to the
> > Ignite
> > > lists.
> > >
> > >
> > > > On Sep 14, 2015, at 9:54 AM, Konstantin Boudnik <co...@apache.org>
> > wrote:
> > > >
> > > > What Andrew describes is a good step forward CTR process and I am
> sure
> > > HBase
> > > > community will find a process that works for them the best. I still
> > > think CTR
> > > > and yet another step further. I believe if a person has commit-bit it
> > is,
> > > > essentially, means that his judgement is trusted and he knows what's
> > > good to
> > > > the project and won't hurt the code intentionally. Mistakes will be
> > > happening
> > > > under either of the processes. But the trust in your community
> fellows
> > > goes
> > > > long way, I think.
> > > >
> > > > We had this discussion on Ignite dev@ list just about a month ago
> [1].
> > > And all
> > > > sorts of arguments were expressed there, and I'd encourage everyone
> to
> > > spend
> > > > a little bit of time reviewing it. The great points were made by
> Brane
> > > [2],
> > > > [3], and [4]. They aren't that long and esp. [3] is very deep, in my
> > > option.
> > > >
> > > > Considering that I really agree with what Brane and myself (doug ;)
> > have
> > > said
> > > > on that thread I won't repeat myself here, but just ask to look at
> the
> > > last
> > > > three emails from below.
> > > >
> > > > BTW, Ignite is on the CTR process for about a month now - nothing
> > morbid
> > > had
> > > > happened to it. And the rate of the development in this project is
> > pretty
> > > > high, actually.
> > > >
> > > > Thanks,
> > > > Cos
> > > >
> > > > [1]
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1822.html
> > > >
> > > > [2]
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1850.html
> > > > [3]
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1885.html
> > > > [4]
> > >
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1859.html
> > > >
> > > >> On Mon, Sep 14, 2015 at 08:51AM, Andrew Purtell wrote:
> > > >> I made this argument over on the dev@hbase list: If the community
> > > considers
> > > >> quality a priority (and we do, right? (Smile)) then we should have a
> > > strong
> > > >> code review ethic whether technically bound to have one (RTC) or not
> > > (CTR).
> > > >>
> > > >> I started a discussion to move over to CTR on HBase because some
> > > components
> > > >> or niche concerns don't draw prompt reviews, slowing down the
> > > >> contributor/committer because their next steps depend on the current
> > > patch.
> > > >> We had this discussion on our dev@ list. You can find it in the
> > public
> > > >> archives if curious. However I was mostly convinced we have
> sufficient
> > > tools
> > > >> without CTR so that's not necessary, eg: - Any committer can check
> > > anything
> > > >> into a dev branch (non release branch) without review; review comes
> > > later at
> > > >> the branch merge vote. Haven't checked if we have a branch merge
> > > policy. We
> > > >> can always add one.
> > > >> - Small fixes or test only changes are given leeway to the
> committer's
> > > >> discretion. Try to wait long enough if a volunteer wants to show up
> > and
> > > do a
> > > >> review. - We have an informal consensus practice where as long as
> the
> > > >> change doesn't have major impact (again, committer discretion) then
> > > after an
> > > >> issue sits a day or two one might post "going to commit this later
> > today
> > > >> unless objection" - and, if no objection, this is a "lazy review"
> and
> > > >> commit.
> > > >>
> > > >> For your consideration.
> > > >>
> > > >>
> > > >>> On Sep 14, 2015, at 7:33 AM, RJ Nowling <rn...@gmail.com>
> wrote:
> > > >>>
> > > >>> I don't want to derail this decision if CTR has general approval.
> I
> > > would
> > > >>> be happy with a clear checklist document that we can all agree to
> > > follow
> > > >>> before commits.
> > > >>>
> > > >>> On Mon, Sep 14, 2015 at 9:24 AM, jay vyas <
> > jayunit100.apache@gmail.com
> > > >
> > > >>> wrote:
> > > >>>
> > > >>>> i think we moved this discussion here
> > > >>>> https://issues.apache.org/jira/browse/BIGTOP-1249
> > > >>>>
> > > >>>> The goal is definetely to get automated reviews.
> > > >>>>
> > > >>>> we hacked around successfully with some prototypes but never
> > > productionized
> > > >>>> them.
> > > >>>>
> > >
> >
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein
> (via Tom White)
>
Re: To speed up the development: shall we become a CTR project?
Posted by Andrew Purtell <ap...@apache.org>.
Yes, please! :-)
On Mon, Sep 14, 2015 at 10:33 AM, Andrew Musselman <
andrew.musselman@gmail.com> wrote:
> If you guys are looking for some help with
> https://issues.apache.org/jira/browse/BIGTOP-1249 I will ask around at
> work
> to see who might have the interest and bandwidth.
>
> On Mon, Sep 14, 2015 at 10:00 AM, Andrew Purtell <andrew.purtell@gmail.com
> >
> wrote:
>
> > Just to be clear I didn't simply describe what the HBase community is
> > doing in this regard but also submitted those ideas for consideration
> here.
> > I could make the same dismissive statement about your pointer to the
> Ignite
> > lists.
> >
> >
> > > On Sep 14, 2015, at 9:54 AM, Konstantin Boudnik <co...@apache.org>
> wrote:
> > >
> > > What Andrew describes is a good step forward CTR process and I am sure
> > HBase
> > > community will find a process that works for them the best. I still
> > think CTR
> > > and yet another step further. I believe if a person has commit-bit it
> is,
> > > essentially, means that his judgement is trusted and he knows what's
> > good to
> > > the project and won't hurt the code intentionally. Mistakes will be
> > happening
> > > under either of the processes. But the trust in your community fellows
> > goes
> > > long way, I think.
> > >
> > > We had this discussion on Ignite dev@ list just about a month ago [1].
> > And all
> > > sorts of arguments were expressed there, and I'd encourage everyone to
> > spend
> > > a little bit of time reviewing it. The great points were made by Brane
> > [2],
> > > [3], and [4]. They aren't that long and esp. [3] is very deep, in my
> > option.
> > >
> > > Considering that I really agree with what Brane and myself (doug ;)
> have
> > said
> > > on that thread I won't repeat myself here, but just ask to look at the
> > last
> > > three emails from below.
> > >
> > > BTW, Ignite is on the CTR process for about a month now - nothing
> morbid
> > had
> > > happened to it. And the rate of the development in this project is
> pretty
> > > high, actually.
> > >
> > > Thanks,
> > > Cos
> > >
> > > [1]
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1822.html
> > >
> > > [2]
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1850.html
> > > [3]
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1885.html
> > > [4]
> >
> http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1859.html
> > >
> > >> On Mon, Sep 14, 2015 at 08:51AM, Andrew Purtell wrote:
> > >> I made this argument over on the dev@hbase list: If the community
> > considers
> > >> quality a priority (and we do, right? (Smile)) then we should have a
> > strong
> > >> code review ethic whether technically bound to have one (RTC) or not
> > (CTR).
> > >>
> > >> I started a discussion to move over to CTR on HBase because some
> > components
> > >> or niche concerns don't draw prompt reviews, slowing down the
> > >> contributor/committer because their next steps depend on the current
> > patch.
> > >> We had this discussion on our dev@ list. You can find it in the
> public
> > >> archives if curious. However I was mostly convinced we have sufficient
> > tools
> > >> without CTR so that's not necessary, eg: - Any committer can check
> > anything
> > >> into a dev branch (non release branch) without review; review comes
> > later at
> > >> the branch merge vote. Haven't checked if we have a branch merge
> > policy. We
> > >> can always add one.
> > >> - Small fixes or test only changes are given leeway to the committer's
> > >> discretion. Try to wait long enough if a volunteer wants to show up
> and
> > do a
> > >> review. - We have an informal consensus practice where as long as the
> > >> change doesn't have major impact (again, committer discretion) then
> > after an
> > >> issue sits a day or two one might post "going to commit this later
> today
> > >> unless objection" - and, if no objection, this is a "lazy review" and
> > >> commit.
> > >>
> > >> For your consideration.
> > >>
> > >>
> > >>> On Sep 14, 2015, at 7:33 AM, RJ Nowling <rn...@gmail.com> wrote:
> > >>>
> > >>> I don't want to derail this decision if CTR has general approval. I
> > would
> > >>> be happy with a clear checklist document that we can all agree to
> > follow
> > >>> before commits.
> > >>>
> > >>> On Mon, Sep 14, 2015 at 9:24 AM, jay vyas <
> jayunit100.apache@gmail.com
> > >
> > >>> wrote:
> > >>>
> > >>>> i think we moved this discussion here
> > >>>> https://issues.apache.org/jira/browse/BIGTOP-1249
> > >>>>
> > >>>> The goal is definetely to get automated reviews.
> > >>>>
> > >>>> we hacked around successfully with some prototypes but never
> > productionized
> > >>>> them.
> > >>>>
> >
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: To speed up the development: shall we become a CTR project?
Posted by Andrew Musselman <an...@gmail.com>.
If you guys are looking for some help with
https://issues.apache.org/jira/browse/BIGTOP-1249 I will ask around at work
to see who might have the interest and bandwidth.
On Mon, Sep 14, 2015 at 10:00 AM, Andrew Purtell <an...@gmail.com>
wrote:
> Just to be clear I didn't simply describe what the HBase community is
> doing in this regard but also submitted those ideas for consideration here.
> I could make the same dismissive statement about your pointer to the Ignite
> lists.
>
>
> > On Sep 14, 2015, at 9:54 AM, Konstantin Boudnik <co...@apache.org> wrote:
> >
> > What Andrew describes is a good step forward CTR process and I am sure
> HBase
> > community will find a process that works for them the best. I still
> think CTR
> > and yet another step further. I believe if a person has commit-bit it is,
> > essentially, means that his judgement is trusted and he knows what's
> good to
> > the project and won't hurt the code intentionally. Mistakes will be
> happening
> > under either of the processes. But the trust in your community fellows
> goes
> > long way, I think.
> >
> > We had this discussion on Ignite dev@ list just about a month ago [1].
> And all
> > sorts of arguments were expressed there, and I'd encourage everyone to
> spend
> > a little bit of time reviewing it. The great points were made by Brane
> [2],
> > [3], and [4]. They aren't that long and esp. [3] is very deep, in my
> option.
> >
> > Considering that I really agree with what Brane and myself (doug ;) have
> said
> > on that thread I won't repeat myself here, but just ask to look at the
> last
> > three emails from below.
> >
> > BTW, Ignite is on the CTR process for about a month now - nothing morbid
> had
> > happened to it. And the rate of the development in this project is pretty
> > high, actually.
> >
> > Thanks,
> > Cos
> >
> > [1]
> http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1822.html
> >
> > [2]
> http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1850.html
> > [3]
> http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1885.html
> > [4]
> http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1859.html
> >
> >> On Mon, Sep 14, 2015 at 08:51AM, Andrew Purtell wrote:
> >> I made this argument over on the dev@hbase list: If the community
> considers
> >> quality a priority (and we do, right? (Smile)) then we should have a
> strong
> >> code review ethic whether technically bound to have one (RTC) or not
> (CTR).
> >>
> >> I started a discussion to move over to CTR on HBase because some
> components
> >> or niche concerns don't draw prompt reviews, slowing down the
> >> contributor/committer because their next steps depend on the current
> patch.
> >> We had this discussion on our dev@ list. You can find it in the public
> >> archives if curious. However I was mostly convinced we have sufficient
> tools
> >> without CTR so that's not necessary, eg: - Any committer can check
> anything
> >> into a dev branch (non release branch) without review; review comes
> later at
> >> the branch merge vote. Haven't checked if we have a branch merge
> policy. We
> >> can always add one.
> >> - Small fixes or test only changes are given leeway to the committer's
> >> discretion. Try to wait long enough if a volunteer wants to show up and
> do a
> >> review. - We have an informal consensus practice where as long as the
> >> change doesn't have major impact (again, committer discretion) then
> after an
> >> issue sits a day or two one might post "going to commit this later today
> >> unless objection" - and, if no objection, this is a "lazy review" and
> >> commit.
> >>
> >> For your consideration.
> >>
> >>
> >>> On Sep 14, 2015, at 7:33 AM, RJ Nowling <rn...@gmail.com> wrote:
> >>>
> >>> I don't want to derail this decision if CTR has general approval. I
> would
> >>> be happy with a clear checklist document that we can all agree to
> follow
> >>> before commits.
> >>>
> >>> On Mon, Sep 14, 2015 at 9:24 AM, jay vyas <jayunit100.apache@gmail.com
> >
> >>> wrote:
> >>>
> >>>> i think we moved this discussion here
> >>>> https://issues.apache.org/jira/browse/BIGTOP-1249
> >>>>
> >>>> The goal is definetely to get automated reviews.
> >>>>
> >>>> we hacked around successfully with some prototypes but never
> productionized
> >>>> them.
> >>>>
>
Re: To speed up the development: shall we become a CTR project?
Posted by Andrew Purtell <an...@gmail.com>.
Just to be clear I didn't simply describe what the HBase community is doing in this regard but also submitted those ideas for consideration here. I could make the same dismissive statement about your pointer to the Ignite lists.
> On Sep 14, 2015, at 9:54 AM, Konstantin Boudnik <co...@apache.org> wrote:
>
> What Andrew describes is a good step forward CTR process and I am sure HBase
> community will find a process that works for them the best. I still think CTR
> and yet another step further. I believe if a person has commit-bit it is,
> essentially, means that his judgement is trusted and he knows what's good to
> the project and won't hurt the code intentionally. Mistakes will be happening
> under either of the processes. But the trust in your community fellows goes
> long way, I think.
>
> We had this discussion on Ignite dev@ list just about a month ago [1]. And all
> sorts of arguments were expressed there, and I'd encourage everyone to spend
> a little bit of time reviewing it. The great points were made by Brane [2],
> [3], and [4]. They aren't that long and esp. [3] is very deep, in my option.
>
> Considering that I really agree with what Brane and myself (doug ;) have said
> on that thread I won't repeat myself here, but just ask to look at the last
> three emails from below.
>
> BTW, Ignite is on the CTR process for about a month now - nothing morbid had
> happened to it. And the rate of the development in this project is pretty
> high, actually.
>
> Thanks,
> Cos
>
> [1] http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1822.html
>
> [2] http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1850.html
> [3] http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1885.html
> [4] http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1859.html
>
>> On Mon, Sep 14, 2015 at 08:51AM, Andrew Purtell wrote:
>> I made this argument over on the dev@hbase list: If the community considers
>> quality a priority (and we do, right? (Smile)) then we should have a strong
>> code review ethic whether technically bound to have one (RTC) or not (CTR).
>>
>> I started a discussion to move over to CTR on HBase because some components
>> or niche concerns don't draw prompt reviews, slowing down the
>> contributor/committer because their next steps depend on the current patch.
>> We had this discussion on our dev@ list. You can find it in the public
>> archives if curious. However I was mostly convinced we have sufficient tools
>> without CTR so that's not necessary, eg: - Any committer can check anything
>> into a dev branch (non release branch) without review; review comes later at
>> the branch merge vote. Haven't checked if we have a branch merge policy. We
>> can always add one.
>> - Small fixes or test only changes are given leeway to the committer's
>> discretion. Try to wait long enough if a volunteer wants to show up and do a
>> review. - We have an informal consensus practice where as long as the
>> change doesn't have major impact (again, committer discretion) then after an
>> issue sits a day or two one might post "going to commit this later today
>> unless objection" - and, if no objection, this is a "lazy review" and
>> commit.
>>
>> For your consideration.
>>
>>
>>> On Sep 14, 2015, at 7:33 AM, RJ Nowling <rn...@gmail.com> wrote:
>>>
>>> I don't want to derail this decision if CTR has general approval. I would
>>> be happy with a clear checklist document that we can all agree to follow
>>> before commits.
>>>
>>> On Mon, Sep 14, 2015 at 9:24 AM, jay vyas <ja...@gmail.com>
>>> wrote:
>>>
>>>> i think we moved this discussion here
>>>> https://issues.apache.org/jira/browse/BIGTOP-1249
>>>>
>>>> The goal is definetely to get automated reviews.
>>>>
>>>> we hacked around successfully with some prototypes but never productionized
>>>> them.
>>>>
Re: To speed up the development: shall we become a CTR project?
Posted by Konstantin Boudnik <co...@apache.org>.
What Andrew describes is a good step forward CTR process and I am sure HBase
community will find a process that works for them the best. I still think CTR
and yet another step further. I believe if a person has commit-bit it is,
essentially, means that his judgement is trusted and he knows what's good to
the project and won't hurt the code intentionally. Mistakes will be happening
under either of the processes. But the trust in your community fellows goes
long way, I think.
We had this discussion on Ignite dev@ list just about a month ago [1]. And all
sorts of arguments were expressed there, and I'd encourage everyone to spend
a little bit of time reviewing it. The great points were made by Brane [2],
[3], and [4]. They aren't that long and esp. [3] is very deep, in my option.
Considering that I really agree with what Brane and myself (doug ;) have said
on that thread I won't repeat myself here, but just ask to look at the last
three emails from below.
BTW, Ignite is on the CTR process for about a month now - nothing morbid had
happened to it. And the rate of the development in this project is pretty
high, actually.
Thanks,
Cos
[1] http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1822.html
[2] http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1850.html
[3] http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1885.html
[4] http://apache-ignite-developers.2346864.n4.nabble.com/Jira-Process-tp1816p1859.html
On Mon, Sep 14, 2015 at 08:51AM, Andrew Purtell wrote:
> I made this argument over on the dev@hbase list: If the community considers
> quality a priority (and we do, right? (Smile)) then we should have a strong
> code review ethic whether technically bound to have one (RTC) or not (CTR).
>
> I started a discussion to move over to CTR on HBase because some components
> or niche concerns don't draw prompt reviews, slowing down the
> contributor/committer because their next steps depend on the current patch.
> We had this discussion on our dev@ list. You can find it in the public
> archives if curious. However I was mostly convinced we have sufficient tools
> without CTR so that's not necessary, eg: - Any committer can check anything
> into a dev branch (non release branch) without review; review comes later at
> the branch merge vote. Haven't checked if we have a branch merge policy. We
> can always add one.
> - Small fixes or test only changes are given leeway to the committer's
> discretion. Try to wait long enough if a volunteer wants to show up and do a
> review. - We have an informal consensus practice where as long as the
> change doesn't have major impact (again, committer discretion) then after an
> issue sits a day or two one might post "going to commit this later today
> unless objection" - and, if no objection, this is a "lazy review" and
> commit.
>
> For your consideration.
>
>
> > On Sep 14, 2015, at 7:33 AM, RJ Nowling <rn...@gmail.com> wrote:
> >
> > I don't want to derail this decision if CTR has general approval. I would
> > be happy with a clear checklist document that we can all agree to follow
> > before commits.
> >
> > On Mon, Sep 14, 2015 at 9:24 AM, jay vyas <ja...@gmail.com>
> > wrote:
> >
> >> i think we moved this discussion here
> >> https://issues.apache.org/jira/browse/BIGTOP-1249
> >>
> >> The goal is definetely to get automated reviews.
> >>
> >> we hacked around successfully with some prototypes but never productionized
> >> them.
> >>
Re: To speed up the development: shall we become a CTR project?
Posted by Andrew Purtell <an...@gmail.com>.
I made this argument over on the dev@hbase list: If the community considers quality a priority (and we do, right? (Smile)) then we should have a strong code review ethic whether technically bound to have one (RTC) or not (CTR).
I started a discussion to move over to CTR on HBase because some components or niche concerns don't draw prompt reviews, slowing down the contributor/committer because their next steps depend on the current patch. We had this discussion on our dev@ list. You can find it in the public archives if curious. However I was mostly convinced we have sufficient tools without CTR so that's not necessary, eg:
- Any committer can check anything into a dev branch (non release branch) without review; review comes later at the branch merge vote. Haven't checked if we have a branch merge policy. We can always add one.
- Small fixes or test only changes are given leeway to the committer's discretion. Try to wait long enough if a volunteer wants to show up and do a review.
- We have an informal consensus practice where as long as the change doesn't have major impact (again, committer discretion) then after an issue sits a day or two one might post "going to commit this later today unless objection" - and, if no objection, this is a "lazy review" and commit.
For your consideration.
> On Sep 14, 2015, at 7:33 AM, RJ Nowling <rn...@gmail.com> wrote:
>
> I don't want to derail this decision if CTR has general approval. I would
> be happy with a clear checklist document that we can all agree to follow
> before commits.
>
> On Mon, Sep 14, 2015 at 9:24 AM, jay vyas <ja...@gmail.com>
> wrote:
>
>> i think we moved this discussion here
>> https://issues.apache.org/jira/browse/BIGTOP-1249
>>
>> The goal is definetely to get automated reviews.
>>
>> we hacked around successfully with some prototypes but never productionized
>> them.
>>
Re: To speed up the development: shall we become a CTR project?
Posted by RJ Nowling <rn...@gmail.com>.
I don't want to derail this decision if CTR has general approval. I would
be happy with a clear checklist document that we can all agree to follow
before commits.
On Mon, Sep 14, 2015 at 9:24 AM, jay vyas <ja...@gmail.com>
wrote:
> i think we moved this discussion here
> https://issues.apache.org/jira/browse/BIGTOP-1249
>
> The goal is definetely to get automated reviews.
>
> we hacked around successfully with some prototypes but never productionized
> them.
>
Re: To speed up the development: shall we become a CTR project?
Posted by jay vyas <ja...@gmail.com>.
i think we moved this discussion here
https://issues.apache.org/jira/browse/BIGTOP-1249
The goal is definetely to get automated reviews.
we hacked around successfully with some prototypes but never productionized
them.
Re: To speed up the development: shall we become a CTR project?
Posted by RJ Nowling <rn...@gmail.com>.
I'd like to ask for thoughts on a compromise between CTR and RCT. I
suggest that we connect the CI to JIRA and either run it automatically or
add provide a mechanism for users to trigger the CI. CI should then report
the results to the JIRA as a comment.
If CI comes back +1 on a committer's patch, then we can commit without
further review. (Essentially automated RCT). If CI returns -1 for
whatever reason, a committer can request a +1 from another committer to
override and commit.
I believe this would streamline the process and provide something similar
to CTR but with some added protection of RCT.
If we don't want to wait for CI integration, can we at least create a
"checklist" documenting all conditions / tests a committer must follow
before committing?
On Mon, Sep 14, 2015 at 2:09 AM, Konstantin Boudnik <co...@apache.org> wrote:
> I think I am even more relaxed with the initial requirements for the CI.
> With
> a few bugs that BIGTOP-1494 (yes, shame on me) the CI was able to catch
> them.
> And the fact that more than one pair of eye was reviewing the code and
> doing
> the testing didn't prevent the bugs from going in.
>
> I say CI where it is today should allow us to start doing CTR. I'd suggest
> we
> add a post commit job that will run the RAT check and at least compile all
> the
> code to quickly see if anything is wrong.
>
> What you have in the list is the idea situation, but perhaps we can start
> adding this _after_ we are the CTR. What do you think?
>
> Cos
>
> On Mon, Sep 14, 2015 at 02:46PM, Evans Ye wrote:
> > I notice the CTR discussion in ignite community which Cos mentioned
> Bigtop
> > there.
> > I pretty much champion the CTR model since sometimes I fix a bug at
> local,
> > but just don't have the energy to put it on the table. And we're not
> being
> > able to adopt CTR because of our CI is not fully functional yet.
> > Which, I'd like to know how comfortable you're if we have our CI being
> able
> > to do this.
> > To be precisely, this gets me cross the line to be able to adopt CTR :)
> >
> > Bigtop CI features:
> > * Nightly build for bigtop/slaves images (test bigtop toolchain)
> > * Build each component on each OS using above nightly build images
> > * Take Bigtop Puppet and run deploy test using multiple config template
> > (non-HA, HA, kerberos, etc)
> > * Deploy a cluster and run fully smoke tests
> > * Deploy a cluster and run fully integration tests
> >
> > If you feel the same, then we can try to make this happened.
> >
> > Evans
> >
> >
> > 2015-01-29 4:57 GMT+08:00 Roman Shaposhnik <ro...@shaposhnik.org>:
> >
> > > On Mon, Jan 26, 2015 at 11:55 AM, Konstantin Boudnik <co...@apache.org>
> > > wrote:
> > > > It seems like a reasonable course of actions to me. As I have strated
> > > this
> > > > conversation, I think I am responsible to at least do the first stab
> at
> > > the
> > > > workflow. Let me do it and send the URL to this thread.
> > >
> > > Sounds good!
> > >
> > > Thanks,
> > > Roman.
> > >
>
Re: To speed up the development: shall we become a CTR project?
Posted by Konstantin Boudnik <co...@apache.org>.
I think I am even more relaxed with the initial requirements for the CI. With
a few bugs that BIGTOP-1494 (yes, shame on me) the CI was able to catch them.
And the fact that more than one pair of eye was reviewing the code and doing
the testing didn't prevent the bugs from going in.
I say CI where it is today should allow us to start doing CTR. I'd suggest we
add a post commit job that will run the RAT check and at least compile all the
code to quickly see if anything is wrong.
What you have in the list is the idea situation, but perhaps we can start
adding this _after_ we are the CTR. What do you think?
Cos
On Mon, Sep 14, 2015 at 02:46PM, Evans Ye wrote:
> I notice the CTR discussion in ignite community which Cos mentioned Bigtop
> there.
> I pretty much champion the CTR model since sometimes I fix a bug at local,
> but just don't have the energy to put it on the table. And we're not being
> able to adopt CTR because of our CI is not fully functional yet.
> Which, I'd like to know how comfortable you're if we have our CI being able
> to do this.
> To be precisely, this gets me cross the line to be able to adopt CTR :)
>
> Bigtop CI features:
> * Nightly build for bigtop/slaves images (test bigtop toolchain)
> * Build each component on each OS using above nightly build images
> * Take Bigtop Puppet and run deploy test using multiple config template
> (non-HA, HA, kerberos, etc)
> * Deploy a cluster and run fully smoke tests
> * Deploy a cluster and run fully integration tests
>
> If you feel the same, then we can try to make this happened.
>
> Evans
>
>
> 2015-01-29 4:57 GMT+08:00 Roman Shaposhnik <ro...@shaposhnik.org>:
>
> > On Mon, Jan 26, 2015 at 11:55 AM, Konstantin Boudnik <co...@apache.org>
> > wrote:
> > > It seems like a reasonable course of actions to me. As I have strated
> > this
> > > conversation, I think I am responsible to at least do the first stab at
> > the
> > > workflow. Let me do it and send the URL to this thread.
> >
> > Sounds good!
> >
> > Thanks,
> > Roman.
> >
Re: To speed up the development: shall we become a CTR project?
Posted by Evans Ye <ev...@apache.org>.
I notice the CTR discussion in ignite community which Cos mentioned Bigtop
there.
I pretty much champion the CTR model since sometimes I fix a bug at local,
but just don't have the energy to put it on the table. And we're not being
able to adopt CTR because of our CI is not fully functional yet.
Which, I'd like to know how comfortable you're if we have our CI being able
to do this.
To be precisely, this gets me cross the line to be able to adopt CTR :)
Bigtop CI features:
* Nightly build for bigtop/slaves images (test bigtop toolchain)
* Build each component on each OS using above nightly build images
* Take Bigtop Puppet and run deploy test using multiple config template
(non-HA, HA, kerberos, etc)
* Deploy a cluster and run fully smoke tests
* Deploy a cluster and run fully integration tests
If you feel the same, then we can try to make this happened.
Evans
2015-01-29 4:57 GMT+08:00 Roman Shaposhnik <ro...@shaposhnik.org>:
> On Mon, Jan 26, 2015 at 11:55 AM, Konstantin Boudnik <co...@apache.org>
> wrote:
> > It seems like a reasonable course of actions to me. As I have strated
> this
> > conversation, I think I am responsible to at least do the first stab at
> the
> > workflow. Let me do it and send the URL to this thread.
>
> Sounds good!
>
> Thanks,
> Roman.
>
Re: To speed up the development: shall we become a CTR project?
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Mon, Jan 26, 2015 at 11:55 AM, Konstantin Boudnik <co...@apache.org> wrote:
> It seems like a reasonable course of actions to me. As I have strated this
> conversation, I think I am responsible to at least do the first stab at the
> workflow. Let me do it and send the URL to this thread.
Sounds good!
Thanks,
Roman.
Re: To speed up the development: shall we become a CTR project?
Posted by Konstantin Boudnik <co...@apache.org>.
It seems like a reasonable course of actions to me. As I have strated this
conversation, I think I am responsible to at least do the first stab at the
workflow. Let me do it and send the URL to this thread.
Cos
On Wed, Jan 07, 2015 at 10:50AM, jay vyas wrote:
> Shall we just propose a commit workflow on bigtop wiki, and vote on that
> (b4 or after the CI) ?A
>
> Here is why i think this is a good approach ....
>
> 1) CTR is as people have mentioned, dangerous.A
> 2)CTR is a good thing, but as i know it, its more an implementation detail
> which usually is associated with
> some other framework (gitflow, gerrit, etc..) ....... which is built to
> review and track commited code and automatically
> merge it?
>
> Its ok w/ me to cast a vote on CTR, but just want to propose this as
> possibly a more comprehensive vote, which is
> gauranteed to have the desired effect (streamline our workflow).
> On Wed, Jan 7, 2015 at 2:13 AM, Konstantin Boudnik <co...@apache.org> wrote:
>
> So, to wrap up the conversation: I see that overall attitude is positive
> towards the CTR approach, but it is hanging on the availability of the
> new CI.
>
> Let's wait until the CI is ready and then I will start a formal [VOTE]
> on
> this.
>
> Thanks,
> A cos
> On Wed, Dec 24, 2014 at 05:16PM, Konstantin Boudnik wrote:
> > I've been reading this discussion on Ignite (incubating) dev@ list
> > http://s.apache.org/wPA and it clicked with the thread we were having
> in
> > the last few days around the community and development processes.
> >
> > What do you guys think if we'll try CTR model? Committers here went
> through
> > the process of gaining their karma and proved with their contributions
> that
> > they don't need peer-reviews for a lot of things that are coming into
> the
> > project on the daily basis. The RTC is especially annoying for trivial
> changes
> > and is really making things slower than they could've been.
> >
> > So, what do you think guys?
> >
> > --
> > Take care,
> >A A A A Cos
> > 2CAC 8312 4870 D885 8616A 6115 220F 6980 1F27 E622
> > Cos' pubkey: http://people.apache.org/~cos/cos.asc
> >
> >A A A A A ---- Wisdom of the hour ----
> >
> > FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #4
> > A:A A Go west, young man, go west!
> > Q:A A What do wabbits do when they get tiwed of wunning awound?
>
> --
> jay vyas
Re: To speed up the development: shall we become a CTR project?
Posted by Konstantin Boudnik <co...@apache.org>.
It seems like a reasonable course of actions to me. As I have strated this
conversation, I think I am responsible to at least do the first stab at the
workflow. Let me do it and send the URL to this thread.
Cos
On Wed, Jan 07, 2015 at 10:50AM, jay vyas wrote:
> Shall we just propose a commit workflow on bigtop wiki, and vote on that
> (b4 or after the CI) ?A
>
> Here is why i think this is a good approach ....
>
> 1) CTR is as people have mentioned, dangerous.A
> 2)CTR is a good thing, but as i know it, its more an implementation detail
> which usually is associated with
> some other framework (gitflow, gerrit, etc..) ....... which is built to
> review and track commited code and automatically
> merge it?
>
> Its ok w/ me to cast a vote on CTR, but just want to propose this as
> possibly a more comprehensive vote, which is
> gauranteed to have the desired effect (streamline our workflow).
> On Wed, Jan 7, 2015 at 2:13 AM, Konstantin Boudnik <co...@apache.org> wrote:
>
> So, to wrap up the conversation: I see that overall attitude is positive
> towards the CTR approach, but it is hanging on the availability of the
> new CI.
>
> Let's wait until the CI is ready and then I will start a formal [VOTE]
> on
> this.
>
> Thanks,
> A cos
> On Wed, Dec 24, 2014 at 05:16PM, Konstantin Boudnik wrote:
> > I've been reading this discussion on Ignite (incubating) dev@ list
> > http://s.apache.org/wPA and it clicked with the thread we were having
> in
> > the last few days around the community and development processes.
> >
> > What do you guys think if we'll try CTR model? Committers here went
> through
> > the process of gaining their karma and proved with their contributions
> that
> > they don't need peer-reviews for a lot of things that are coming into
> the
> > project on the daily basis. The RTC is especially annoying for trivial
> changes
> > and is really making things slower than they could've been.
> >
> > So, what do you think guys?
> >
> > --
> > Take care,
> >A A A A Cos
> > 2CAC 8312 4870 D885 8616A 6115 220F 6980 1F27 E622
> > Cos' pubkey: http://people.apache.org/~cos/cos.asc
> >
> >A A A A A ---- Wisdom of the hour ----
> >
> > FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #4
> > A:A A Go west, young man, go west!
> > Q:A A What do wabbits do when they get tiwed of wunning awound?
>
> --
> jay vyas
Re: To speed up the development: shall we become a CTR project?
Posted by jay vyas <ja...@gmail.com>.
Shall we just propose a commit workflow on bigtop wiki, and vote on that
(b4 or after the CI) ?
Here is why i think this is a good approach ....
1) CTR is as people have mentioned, dangerous.
2)CTR is a good thing, but as i know it, its more an implementation detail
which usually is associated with
some other framework (gitflow, gerrit, etc..) ....... which is built to
review and track commited code and automatically
merge it?
Its ok w/ me to cast a vote on CTR, but just want to propose this as
possibly a more comprehensive vote, which is
gauranteed to have the desired effect (streamline our workflow).
On Wed, Jan 7, 2015 at 2:13 AM, Konstantin Boudnik <co...@apache.org> wrote:
> So, to wrap up the conversation: I see that overall attitude is positive
> towards the CTR approach, but it is hanging on the availability of the new
> CI.
>
> Let's wait until the CI is ready and then I will start a formal [VOTE] on
> this.
>
> Thanks,
> cos
>
> On Wed, Dec 24, 2014 at 05:16PM, Konstantin Boudnik wrote:
> > I've been reading this discussion on Ignite (incubating) dev@ list
> > http://s.apache.org/wPA and it clicked with the thread we were having in
> > the last few days around the community and development processes.
> >
> > What do you guys think if we'll try CTR model? Committers here went
> through
> > the process of gaining their karma and proved with their contributions
> that
> > they don't need peer-reviews for a lot of things that are coming into the
> > project on the daily basis. The RTC is especially annoying for trivial
> changes
> > and is really making things slower than they could've been.
> >
> > So, what do you think guys?
> >
> > --
> > Take care,
> > Cos
> > 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
> > Cos' pubkey: http://people.apache.org/~cos/cos.asc
> >
> > ---- Wisdom of the hour ----
> >
> > FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #4
> > A: Go west, young man, go west!
> > Q: What do wabbits do when they get tiwed of wunning awound?
>
>
>
--
jay vyas
Re: To speed up the development: shall we become a CTR project?
Posted by jay vyas <ja...@gmail.com>.
Shall we just propose a commit workflow on bigtop wiki, and vote on that
(b4 or after the CI) ?
Here is why i think this is a good approach ....
1) CTR is as people have mentioned, dangerous.
2)CTR is a good thing, but as i know it, its more an implementation detail
which usually is associated with
some other framework (gitflow, gerrit, etc..) ....... which is built to
review and track commited code and automatically
merge it?
Its ok w/ me to cast a vote on CTR, but just want to propose this as
possibly a more comprehensive vote, which is
gauranteed to have the desired effect (streamline our workflow).
On Wed, Jan 7, 2015 at 2:13 AM, Konstantin Boudnik <co...@apache.org> wrote:
> So, to wrap up the conversation: I see that overall attitude is positive
> towards the CTR approach, but it is hanging on the availability of the new
> CI.
>
> Let's wait until the CI is ready and then I will start a formal [VOTE] on
> this.
>
> Thanks,
> cos
>
> On Wed, Dec 24, 2014 at 05:16PM, Konstantin Boudnik wrote:
> > I've been reading this discussion on Ignite (incubating) dev@ list
> > http://s.apache.org/wPA and it clicked with the thread we were having in
> > the last few days around the community and development processes.
> >
> > What do you guys think if we'll try CTR model? Committers here went
> through
> > the process of gaining their karma and proved with their contributions
> that
> > they don't need peer-reviews for a lot of things that are coming into the
> > project on the daily basis. The RTC is especially annoying for trivial
> changes
> > and is really making things slower than they could've been.
> >
> > So, what do you think guys?
> >
> > --
> > Take care,
> > Cos
> > 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
> > Cos' pubkey: http://people.apache.org/~cos/cos.asc
> >
> > ---- Wisdom of the hour ----
> >
> > FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #4
> > A: Go west, young man, go west!
> > Q: What do wabbits do when they get tiwed of wunning awound?
>
>
>
--
jay vyas
Re: To speed up the development: shall we become a CTR project?
Posted by Konstantin Boudnik <co...@apache.org>.
So, to wrap up the conversation: I see that overall attitude is positive
towards the CTR approach, but it is hanging on the availability of the new CI.
Let's wait until the CI is ready and then I will start a formal [VOTE] on
this.
Thanks,
cos
On Wed, Dec 24, 2014 at 05:16PM, Konstantin Boudnik wrote:
> I've been reading this discussion on Ignite (incubating) dev@ list
> http://s.apache.org/wPA and it clicked with the thread we were having in
> the last few days around the community and development processes.
>
> What do you guys think if we'll try CTR model? Committers here went through
> the process of gaining their karma and proved with their contributions that
> they don't need peer-reviews for a lot of things that are coming into the
> project on the daily basis. The RTC is especially annoying for trivial changes
> and is really making things slower than they could've been.
>
> So, what do you think guys?
>
> --
> Take care,
> Cos
> 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
> Cos' pubkey: http://people.apache.org/~cos/cos.asc
>
> ---- Wisdom of the hour ----
>
> FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #4
> A: Go west, young man, go west!
> Q: What do wabbits do when they get tiwed of wunning awound?
Re: To speed up the development: shall we become a CTR project?
Posted by Andrew Purtell <an...@gmail.com>.
I suggest agreeing about CTR or not, then agree on shared workflow.
> On Dec 27, 2014, at 1:28 PM, Jay Vyas <ja...@gmail.com> wrote:
>
> Branches are never irrelevant in git :), not really clear . I'm totally in agreement that we can implement CtR ...
>
> but I just want to make sure that it's clear what model we are agreeing on. Because the power is in the unified and transparent workflow, not just the raw CtrR rule .
>
>> On Dec 27, 2014, at 1:30 PM, Konstantin Boudnik <co...@apache.org> wrote:
>>
>> Branches are irrelevant to how the we allow the commits to get in.
>>
>> Branches are needed for more complex features that require a collaborate
>> effort and/or prolonged development time. Does it make sense?
>>
>> Cos
>>
>>> On Sat, Dec 27, 2014 at 09:26AM, Jay Vyas wrote:
>>> If we wanna do CTR ...
>>> Can we just do it into master?
>>> I realize it will break but that what CI is for.
>>>
>>> I wanna make sure we aren't just creating a backlog of unmerged branches.
>>>
>>>> On Dec 26, 2014, at 4:23 PM, Andrew Purtell <ap...@apache.org> wrote:
>>>>
>>>> +1 from me
>>>>
>>>>> On Wed, Dec 24, 2014 at 5:16 PM, Konstantin Boudnik <co...@apache.org> wrote:
>>>>> I've been reading this discussion on Ignite (incubating) dev@ list
>>>>> http://s.apache.org/wPA and it clicked with the thread we were having in
>>>>> the last few days around the community and development processes.
>>>>>
>>>>> What do you guys think if we'll try CTR model? Committers here went through
>>>>> the process of gaining their karma and proved with their contributions that
>>>>> they don't need peer-reviews for a lot of things that are coming into the
>>>>> project on the daily basis. The RTC is especially annoying for trivial changes
>>>>> and is really making things slower than they could've been.
>>>>>
>>>>> So, what do you think guys?
>>>>>
>>>>> --
>>>>> Take care,
>>>>> Cos
>>>>> 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
>>>>> Cos' pubkey: http://people.apache.org/~cos/cos.asc
>>>>>
>>>>> ---- Wisdom of the hour ----
>>>>>
>>>>> FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #4
>>>>> A: Go west, young man, go west!
>>>>> Q: What do wabbits do when they get tiwed of wunning awound?
>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>>
>>>> - Andy
>>>>
>>>> Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
Re: To speed up the development: shall we become a CTR project?
Posted by Andrew Purtell <an...@gmail.com>.
I suggest agreeing about CTR or not, then agree on shared workflow.
> On Dec 27, 2014, at 1:28 PM, Jay Vyas <ja...@gmail.com> wrote:
>
> Branches are never irrelevant in git :), not really clear . I'm totally in agreement that we can implement CtR ...
>
> but I just want to make sure that it's clear what model we are agreeing on. Because the power is in the unified and transparent workflow, not just the raw CtrR rule .
>
>> On Dec 27, 2014, at 1:30 PM, Konstantin Boudnik <co...@apache.org> wrote:
>>
>> Branches are irrelevant to how the we allow the commits to get in.
>>
>> Branches are needed for more complex features that require a collaborate
>> effort and/or prolonged development time. Does it make sense?
>>
>> Cos
>>
>>> On Sat, Dec 27, 2014 at 09:26AM, Jay Vyas wrote:
>>> If we wanna do CTR ...
>>> Can we just do it into master?
>>> I realize it will break but that what CI is for.
>>>
>>> I wanna make sure we aren't just creating a backlog of unmerged branches.
>>>
>>>> On Dec 26, 2014, at 4:23 PM, Andrew Purtell <ap...@apache.org> wrote:
>>>>
>>>> +1 from me
>>>>
>>>>> On Wed, Dec 24, 2014 at 5:16 PM, Konstantin Boudnik <co...@apache.org> wrote:
>>>>> I've been reading this discussion on Ignite (incubating) dev@ list
>>>>> http://s.apache.org/wPA and it clicked with the thread we were having in
>>>>> the last few days around the community and development processes.
>>>>>
>>>>> What do you guys think if we'll try CTR model? Committers here went through
>>>>> the process of gaining their karma and proved with their contributions that
>>>>> they don't need peer-reviews for a lot of things that are coming into the
>>>>> project on the daily basis. The RTC is especially annoying for trivial changes
>>>>> and is really making things slower than they could've been.
>>>>>
>>>>> So, what do you think guys?
>>>>>
>>>>> --
>>>>> Take care,
>>>>> Cos
>>>>> 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
>>>>> Cos' pubkey: http://people.apache.org/~cos/cos.asc
>>>>>
>>>>> ---- Wisdom of the hour ----
>>>>>
>>>>> FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #4
>>>>> A: Go west, young man, go west!
>>>>> Q: What do wabbits do when they get tiwed of wunning awound?
>>>>
>>>>
>>>>
>>>> --
>>>> Best regards,
>>>>
>>>> - Andy
>>>>
>>>> Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
Re: To speed up the development: shall we become a CTR project?
Posted by Jay Vyas <ja...@gmail.com>.
Branches are never irrelevant in git :), not really clear . I'm totally in agreement that we can implement CtR ...
but I just want to make sure that it's clear what model we are agreeing on. Because the power is in the unified and transparent workflow, not just the raw CtrR rule .
> On Dec 27, 2014, at 1:30 PM, Konstantin Boudnik <co...@apache.org> wrote:
>
> Branches are irrelevant to how the we allow the commits to get in.
>
> Branches are needed for more complex features that require a collaborate
> effort and/or prolonged development time. Does it make sense?
>
> Cos
>
>> On Sat, Dec 27, 2014 at 09:26AM, Jay Vyas wrote:
>> If we wanna do CTR ...
>> Can we just do it into master?
>> I realize it will break but that what CI is for.
>>
>> I wanna make sure we aren't just creating a backlog of unmerged branches.
>>
>>> On Dec 26, 2014, at 4:23 PM, Andrew Purtell <ap...@apache.org> wrote:
>>>
>>> +1 from me
>>>
>>>> On Wed, Dec 24, 2014 at 5:16 PM, Konstantin Boudnik <co...@apache.org> wrote:
>>>> I've been reading this discussion on Ignite (incubating) dev@ list
>>>> http://s.apache.org/wPA and it clicked with the thread we were having in
>>>> the last few days around the community and development processes.
>>>>
>>>> What do you guys think if we'll try CTR model? Committers here went through
>>>> the process of gaining their karma and proved with their contributions that
>>>> they don't need peer-reviews for a lot of things that are coming into the
>>>> project on the daily basis. The RTC is especially annoying for trivial changes
>>>> and is really making things slower than they could've been.
>>>>
>>>> So, what do you think guys?
>>>>
>>>> --
>>>> Take care,
>>>> Cos
>>>> 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
>>>> Cos' pubkey: http://people.apache.org/~cos/cos.asc
>>>>
>>>> ---- Wisdom of the hour ----
>>>>
>>>> FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #4
>>>> A: Go west, young man, go west!
>>>> Q: What do wabbits do when they get tiwed of wunning awound?
>>>
>>>
>>>
>>> --
>>> Best regards,
>>>
>>> - Andy
>>>
>>> Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
Re: To speed up the development: shall we become a CTR project?
Posted by Jay Vyas <ja...@gmail.com>.
Branches are never irrelevant in git :), not really clear . I'm totally in agreement that we can implement CtR ...
but I just want to make sure that it's clear what model we are agreeing on. Because the power is in the unified and transparent workflow, not just the raw CtrR rule .
> On Dec 27, 2014, at 1:30 PM, Konstantin Boudnik <co...@apache.org> wrote:
>
> Branches are irrelevant to how the we allow the commits to get in.
>
> Branches are needed for more complex features that require a collaborate
> effort and/or prolonged development time. Does it make sense?
>
> Cos
>
>> On Sat, Dec 27, 2014 at 09:26AM, Jay Vyas wrote:
>> If we wanna do CTR ...
>> Can we just do it into master?
>> I realize it will break but that what CI is for.
>>
>> I wanna make sure we aren't just creating a backlog of unmerged branches.
>>
>>> On Dec 26, 2014, at 4:23 PM, Andrew Purtell <ap...@apache.org> wrote:
>>>
>>> +1 from me
>>>
>>>> On Wed, Dec 24, 2014 at 5:16 PM, Konstantin Boudnik <co...@apache.org> wrote:
>>>> I've been reading this discussion on Ignite (incubating) dev@ list
>>>> http://s.apache.org/wPA and it clicked with the thread we were having in
>>>> the last few days around the community and development processes.
>>>>
>>>> What do you guys think if we'll try CTR model? Committers here went through
>>>> the process of gaining their karma and proved with their contributions that
>>>> they don't need peer-reviews for a lot of things that are coming into the
>>>> project on the daily basis. The RTC is especially annoying for trivial changes
>>>> and is really making things slower than they could've been.
>>>>
>>>> So, what do you think guys?
>>>>
>>>> --
>>>> Take care,
>>>> Cos
>>>> 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
>>>> Cos' pubkey: http://people.apache.org/~cos/cos.asc
>>>>
>>>> ---- Wisdom of the hour ----
>>>>
>>>> FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #4
>>>> A: Go west, young man, go west!
>>>> Q: What do wabbits do when they get tiwed of wunning awound?
>>>
>>>
>>>
>>> --
>>> Best regards,
>>>
>>> - Andy
>>>
>>> Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
Re: To speed up the development: shall we become a CTR project?
Posted by Konstantin Boudnik <co...@apache.org>.
Branches are irrelevant to how the we allow the commits to get in.
Branches are needed for more complex features that require a collaborate
effort and/or prolonged development time. Does it make sense?
Cos
On Sat, Dec 27, 2014 at 09:26AM, Jay Vyas wrote:
> If we wanna do CTR ...
> Can we just do it into master?
> I realize it will break but that what CI is for.
>
> I wanna make sure we aren't just creating a backlog of unmerged branches.
>
> > On Dec 26, 2014, at 4:23 PM, Andrew Purtell <ap...@apache.org> wrote:
> >
> > +1 from me
> >
> >> On Wed, Dec 24, 2014 at 5:16 PM, Konstantin Boudnik <co...@apache.org> wrote:
> >> I've been reading this discussion on Ignite (incubating) dev@ list
> >> http://s.apache.org/wPA and it clicked with the thread we were having in
> >> the last few days around the community and development processes.
> >>
> >> What do you guys think if we'll try CTR model? Committers here went through
> >> the process of gaining their karma and proved with their contributions that
> >> they don't need peer-reviews for a lot of things that are coming into the
> >> project on the daily basis. The RTC is especially annoying for trivial changes
> >> and is really making things slower than they could've been.
> >>
> >> So, what do you think guys?
> >>
> >> --
> >> Take care,
> >> Cos
> >> 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
> >> Cos' pubkey: http://people.apache.org/~cos/cos.asc
> >>
> >> ---- Wisdom of the hour ----
> >>
> >> FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #4
> >> A: Go west, young man, go west!
> >> Q: What do wabbits do when they get tiwed of wunning awound?
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
Re: To speed up the development: shall we become a CTR project?
Posted by Konstantin Boudnik <co...@apache.org>.
Branches are irrelevant to how the we allow the commits to get in.
Branches are needed for more complex features that require a collaborate
effort and/or prolonged development time. Does it make sense?
Cos
On Sat, Dec 27, 2014 at 09:26AM, Jay Vyas wrote:
> If we wanna do CTR ...
> Can we just do it into master?
> I realize it will break but that what CI is for.
>
> I wanna make sure we aren't just creating a backlog of unmerged branches.
>
> > On Dec 26, 2014, at 4:23 PM, Andrew Purtell <ap...@apache.org> wrote:
> >
> > +1 from me
> >
> >> On Wed, Dec 24, 2014 at 5:16 PM, Konstantin Boudnik <co...@apache.org> wrote:
> >> I've been reading this discussion on Ignite (incubating) dev@ list
> >> http://s.apache.org/wPA and it clicked with the thread we were having in
> >> the last few days around the community and development processes.
> >>
> >> What do you guys think if we'll try CTR model? Committers here went through
> >> the process of gaining their karma and proved with their contributions that
> >> they don't need peer-reviews for a lot of things that are coming into the
> >> project on the daily basis. The RTC is especially annoying for trivial changes
> >> and is really making things slower than they could've been.
> >>
> >> So, what do you think guys?
> >>
> >> --
> >> Take care,
> >> Cos
> >> 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
> >> Cos' pubkey: http://people.apache.org/~cos/cos.asc
> >>
> >> ---- Wisdom of the hour ----
> >>
> >> FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #4
> >> A: Go west, young man, go west!
> >> Q: What do wabbits do when they get tiwed of wunning awound?
> >
> >
> >
> > --
> > Best regards,
> >
> > - Andy
> >
> > Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
Re: To speed up the development: shall we become a CTR project?
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Sat, Dec 27, 2014 at 8:46 PM, Konstantin Boudnik <co...@apache.org> wrote:
> Arguably, CI is a must to have for any commit model. If there's no CI then
> reviewer has to apply the patch and do build-n-test dance to make sure that
> modifications aren't breaking the build. Thus, CTR isn't really hanging on a
> need for a robust CI; but CI would be a great help for sure.
Sure, but the chances of things going wrong increase with CTR, hence
my comment.
Thanks,
Roman.
Re: To speed up the development: shall we become a CTR project?
Posted by Konstantin Boudnik <co...@apache.org>.
Arguably, CI is a must to have for any commit model. If there's no CI then
reviewer has to apply the patch and do build-n-test dance to make sure that
modifications aren't breaking the build. Thus, CTR isn't really hanging on a
need for a robust CI; but CI would be a great help for sure.
Cos
On Sat, Dec 27, 2014 at 11:37PM, Mark Grover wrote:
> I completely agree with Roman and Peter. Right now, we don't have good
> altering/monitoring that enable us to have a quick turnaround time to fix
> things when they break. I'd think that'd be a pre-requisite for making the
> project CTR. I am glad and excited to see it being very close to done.
>
> On Sat, Dec 27, 2014 at 11:21 PM, Peter Linnell <pl...@apache.org> wrote:
>
> > On Sat, 27 Dec 2014 18:28:31 -0800
> > Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> >
> > > On Sat, Dec 27, 2014 at 7:26 AM, Jay Vyas
> > > <ja...@gmail.com> wrote:
> > > > If we wanna do CTR ...
> > > > Can we just do it into master?
> > > > I realize it will break but that what CI is for.
> > >
> > > On that note, I'd be a strong +1 on CTR once we get
> > > our CI fully functional again. Without it, I guess I'm -0.
> > >
> > > The good news is, I think I'm pretty close to getting
> > > it done by the end of the year ;-)
> > >
> > > Thanks,
> > > Roman.
> >
> > I had been pondering this and read all the threads. My instinctive
> > reaction was no, but as Roman pointed out, we need a reliable CI setup
> > we can all monitor easily. With that fixed I'm a +1.
> >
> > @Roman, what can we do to help getting the CI system right side?
> >
> > Thanks,
> >
> > Peter
> >
Re: To speed up the development: shall we become a CTR project?
Posted by Mark Grover <ma...@apache.org>.
I completely agree with Roman and Peter. Right now, we don't have good
altering/monitoring that enable us to have a quick turnaround time to fix
things when they break. I'd think that'd be a pre-requisite for making the
project CTR. I am glad and excited to see it being very close to done.
On Sat, Dec 27, 2014 at 11:21 PM, Peter Linnell <pl...@apache.org> wrote:
> On Sat, 27 Dec 2014 18:28:31 -0800
> Roman Shaposhnik <ro...@shaposhnik.org> wrote:
>
> > On Sat, Dec 27, 2014 at 7:26 AM, Jay Vyas
> > <ja...@gmail.com> wrote:
> > > If we wanna do CTR ...
> > > Can we just do it into master?
> > > I realize it will break but that what CI is for.
> >
> > On that note, I'd be a strong +1 on CTR once we get
> > our CI fully functional again. Without it, I guess I'm -0.
> >
> > The good news is, I think I'm pretty close to getting
> > it done by the end of the year ;-)
> >
> > Thanks,
> > Roman.
>
> I had been pondering this and read all the threads. My instinctive
> reaction was no, but as Roman pointed out, we need a reliable CI setup
> we can all monitor easily. With that fixed I'm a +1.
>
> @Roman, what can we do to help getting the CI system right side?
>
> Thanks,
>
> Peter
>
Re: To speed up the development: shall we become a CTR project?
Posted by Peter Linnell <pl...@apache.org>.
On Sat, 27 Dec 2014 18:28:31 -0800
Roman Shaposhnik <ro...@shaposhnik.org> wrote:
> On Sat, Dec 27, 2014 at 7:26 AM, Jay Vyas
> <ja...@gmail.com> wrote:
> > If we wanna do CTR ...
> > Can we just do it into master?
> > I realize it will break but that what CI is for.
>
> On that note, I'd be a strong +1 on CTR once we get
> our CI fully functional again. Without it, I guess I'm -0.
>
> The good news is, I think I'm pretty close to getting
> it done by the end of the year ;-)
>
> Thanks,
> Roman.
I had been pondering this and read all the threads. My instinctive
reaction was no, but as Roman pointed out, we need a reliable CI setup
we can all monitor easily. With that fixed I'm a +1.
@Roman, what can we do to help getting the CI system right side?
Thanks,
Peter
Re: To speed up the development: shall we become a CTR project?
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Sat, Dec 27, 2014 at 7:26 AM, Jay Vyas <ja...@gmail.com> wrote:
> If we wanna do CTR ...
> Can we just do it into master?
> I realize it will break but that what CI is for.
On that note, I'd be a strong +1 on CTR once we get
our CI fully functional again. Without it, I guess I'm -0.
The good news is, I think I'm pretty close to getting
it done by the end of the year ;-)
Thanks,
Roman.
Re: To speed up the development: shall we become a CTR project?
Posted by Roman Shaposhnik <ro...@shaposhnik.org>.
On Sat, Dec 27, 2014 at 7:26 AM, Jay Vyas <ja...@gmail.com> wrote:
> If we wanna do CTR ...
> Can we just do it into master?
> I realize it will break but that what CI is for.
On that note, I'd be a strong +1 on CTR once we get
our CI fully functional again. Without it, I guess I'm -0.
The good news is, I think I'm pretty close to getting
it done by the end of the year ;-)
Thanks,
Roman.
Re: To speed up the development: shall we become a CTR project?
Posted by Jay Vyas <ja...@gmail.com>.
If we wanna do CTR ...
Can we just do it into master?
I realize it will break but that what CI is for.
I wanna make sure we aren't just creating a backlog of unmerged branches.
> On Dec 26, 2014, at 4:23 PM, Andrew Purtell <ap...@apache.org> wrote:
>
> +1 from me
>
>> On Wed, Dec 24, 2014 at 5:16 PM, Konstantin Boudnik <co...@apache.org> wrote:
>> I've been reading this discussion on Ignite (incubating) dev@ list
>> http://s.apache.org/wPA and it clicked with the thread we were having in
>> the last few days around the community and development processes.
>>
>> What do you guys think if we'll try CTR model? Committers here went through
>> the process of gaining their karma and proved with their contributions that
>> they don't need peer-reviews for a lot of things that are coming into the
>> project on the daily basis. The RTC is especially annoying for trivial changes
>> and is really making things slower than they could've been.
>>
>> So, what do you think guys?
>>
>> --
>> Take care,
>> Cos
>> 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
>> Cos' pubkey: http://people.apache.org/~cos/cos.asc
>>
>> ---- Wisdom of the hour ----
>>
>> FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #4
>> A: Go west, young man, go west!
>> Q: What do wabbits do when they get tiwed of wunning awound?
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
Re: To speed up the development: shall we become a CTR project?
Posted by Jay Vyas <ja...@gmail.com>.
If we wanna do CTR ...
Can we just do it into master?
I realize it will break but that what CI is for.
I wanna make sure we aren't just creating a backlog of unmerged branches.
> On Dec 26, 2014, at 4:23 PM, Andrew Purtell <ap...@apache.org> wrote:
>
> +1 from me
>
>> On Wed, Dec 24, 2014 at 5:16 PM, Konstantin Boudnik <co...@apache.org> wrote:
>> I've been reading this discussion on Ignite (incubating) dev@ list
>> http://s.apache.org/wPA and it clicked with the thread we were having in
>> the last few days around the community and development processes.
>>
>> What do you guys think if we'll try CTR model? Committers here went through
>> the process of gaining their karma and proved with their contributions that
>> they don't need peer-reviews for a lot of things that are coming into the
>> project on the daily basis. The RTC is especially annoying for trivial changes
>> and is really making things slower than they could've been.
>>
>> So, what do you think guys?
>>
>> --
>> Take care,
>> Cos
>> 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
>> Cos' pubkey: http://people.apache.org/~cos/cos.asc
>>
>> ---- Wisdom of the hour ----
>>
>> FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #4
>> A: Go west, young man, go west!
>> Q: What do wabbits do when they get tiwed of wunning awound?
>
>
>
> --
> Best regards,
>
> - Andy
>
> Problems worthy of attack prove their worth by hitting back. - Piet Hein (via Tom White)
Re: To speed up the development: shall we become a CTR project?
Posted by Andrew Purtell <ap...@apache.org>.
+1 from me
On Wed, Dec 24, 2014 at 5:16 PM, Konstantin Boudnik <co...@apache.org> wrote:
> I've been reading this discussion on Ignite (incubating) dev@ list
> http://s.apache.org/wPA and it clicked with the thread we were having in
> the last few days around the community and development processes.
>
> What do you guys think if we'll try CTR model? Committers here went through
> the process of gaining their karma and proved with their contributions that
> they don't need peer-reviews for a lot of things that are coming into the
> project on the daily basis. The RTC is especially annoying for trivial
> changes
> and is really making things slower than they could've been.
>
> So, what do you think guys?
>
> --
> Take care,
> Cos
> 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
> Cos' pubkey: http://people.apache.org/~cos/cos.asc
>
> ---- Wisdom of the hour ----
>
> FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #4
> A: Go west, young man, go west!
> Q: What do wabbits do when they get tiwed of wunning awound?
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: To speed up the development: shall we become a CTR project?
Posted by Andrew Purtell <ap...@apache.org>.
+1 from me
On Wed, Dec 24, 2014 at 5:16 PM, Konstantin Boudnik <co...@apache.org> wrote:
> I've been reading this discussion on Ignite (incubating) dev@ list
> http://s.apache.org/wPA and it clicked with the thread we were having in
> the last few days around the community and development processes.
>
> What do you guys think if we'll try CTR model? Committers here went through
> the process of gaining their karma and proved with their contributions that
> they don't need peer-reviews for a lot of things that are coming into the
> project on the daily basis. The RTC is especially annoying for trivial
> changes
> and is really making things slower than they could've been.
>
> So, what do you think guys?
>
> --
> Take care,
> Cos
> 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
> Cos' pubkey: http://people.apache.org/~cos/cos.asc
>
> ---- Wisdom of the hour ----
>
> FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #4
> A: Go west, young man, go west!
> Q: What do wabbits do when they get tiwed of wunning awound?
>
--
Best regards,
- Andy
Problems worthy of attack prove their worth by hitting back. - Piet Hein
(via Tom White)
Re: To speed up the development: shall we become a CTR project?
Posted by Konstantin Boudnik <co...@apache.org>.
The workflow will be pretty much the same as now with small modification:
- open a JIRA and put in the usual amount of the details; keep a discussion
on it if needed
- once a patch is ready it's getting committed to the branch (master or else
if some people are working on a feature branch)
- people get the message on commits@ list and go in and check the changes
-- if a commit has issues then a new JIRA is opened to iron it out
-- it'd be great to have an update the JIRA when the commit happens, but
it'd be nice in any case. Does anyone know what is needed for that?
- for contributors without the commiter-bit the process will remain the same
RTC as today
Makes sense?
Cos
On Thu, Dec 25, 2014 at 11:27AM, Jay Vyas wrote:
> Commit-then-review? Intriguing. Can you propose the exact workflow you're suggesting?
>
> > On Dec 24, 2014, at 7:16 PM, Konstantin Boudnik <co...@apache.org> wrote:
> >
> > I've been reading this discussion on Ignite (incubating) dev@ list
> > http://s.apache.org/wPA and it clicked with the thread we were having in
> > the last few days around the community and development processes.
> >
> > What do you guys think if we'll try CTR model? Committers here went through
> > the process of gaining their karma and proved with their contributions that
> > they don't need peer-reviews for a lot of things that are coming into the
> > project on the daily basis. The RTC is especially annoying for trivial changes
> > and is really making things slower than they could've been.
> >
> > So, what do you think guys?
> >
> > --
> > Take care,
> > Cos
> > 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
> > Cos' pubkey: http://people.apache.org/~cos/cos.asc
> >
> > ---- Wisdom of the hour ----
> >
> > FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #4
> > A: Go west, young man, go west!
> > Q: What do wabbits do when they get tiwed of wunning awound?
Re: To speed up the development: shall we become a CTR project?
Posted by Konstantin Boudnik <co...@apache.org>.
The workflow will be pretty much the same as now with small modification:
- open a JIRA and put in the usual amount of the details; keep a discussion
on it if needed
- once a patch is ready it's getting committed to the branch (master or else
if some people are working on a feature branch)
- people get the message on commits@ list and go in and check the changes
-- if a commit has issues then a new JIRA is opened to iron it out
-- it'd be great to have an update the JIRA when the commit happens, but
it'd be nice in any case. Does anyone know what is needed for that?
- for contributors without the commiter-bit the process will remain the same
RTC as today
Makes sense?
Cos
On Thu, Dec 25, 2014 at 11:27AM, Jay Vyas wrote:
> Commit-then-review? Intriguing. Can you propose the exact workflow you're suggesting?
>
> > On Dec 24, 2014, at 7:16 PM, Konstantin Boudnik <co...@apache.org> wrote:
> >
> > I've been reading this discussion on Ignite (incubating) dev@ list
> > http://s.apache.org/wPA and it clicked with the thread we were having in
> > the last few days around the community and development processes.
> >
> > What do you guys think if we'll try CTR model? Committers here went through
> > the process of gaining their karma and proved with their contributions that
> > they don't need peer-reviews for a lot of things that are coming into the
> > project on the daily basis. The RTC is especially annoying for trivial changes
> > and is really making things slower than they could've been.
> >
> > So, what do you think guys?
> >
> > --
> > Take care,
> > Cos
> > 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
> > Cos' pubkey: http://people.apache.org/~cos/cos.asc
> >
> > ---- Wisdom of the hour ----
> >
> > FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #4
> > A: Go west, young man, go west!
> > Q: What do wabbits do when they get tiwed of wunning awound?
Re: To speed up the development: shall we become a CTR project?
Posted by Jay Vyas <ja...@gmail.com>.
Commit-then-review? Intriguing. Can you propose the exact workflow you're suggesting?
> On Dec 24, 2014, at 7:16 PM, Konstantin Boudnik <co...@apache.org> wrote:
>
> I've been reading this discussion on Ignite (incubating) dev@ list
> http://s.apache.org/wPA and it clicked with the thread we were having in
> the last few days around the community and development processes.
>
> What do you guys think if we'll try CTR model? Committers here went through
> the process of gaining their karma and proved with their contributions that
> they don't need peer-reviews for a lot of things that are coming into the
> project on the daily basis. The RTC is especially annoying for trivial changes
> and is really making things slower than they could've been.
>
> So, what do you think guys?
>
> --
> Take care,
> Cos
> 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
> Cos' pubkey: http://people.apache.org/~cos/cos.asc
>
> ---- Wisdom of the hour ----
>
> FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #4
> A: Go west, young man, go west!
> Q: What do wabbits do when they get tiwed of wunning awound?
Re: To speed up the development: shall we become a CTR project?
Posted by Konstantin Boudnik <co...@apache.org>.
So, to wrap up the conversation: I see that overall attitude is positive
towards the CTR approach, but it is hanging on the availability of the new CI.
Let's wait until the CI is ready and then I will start a formal [VOTE] on
this.
Thanks,
cos
On Wed, Dec 24, 2014 at 05:16PM, Konstantin Boudnik wrote:
> I've been reading this discussion on Ignite (incubating) dev@ list
> http://s.apache.org/wPA and it clicked with the thread we were having in
> the last few days around the community and development processes.
>
> What do you guys think if we'll try CTR model? Committers here went through
> the process of gaining their karma and proved with their contributions that
> they don't need peer-reviews for a lot of things that are coming into the
> project on the daily basis. The RTC is especially annoying for trivial changes
> and is really making things slower than they could've been.
>
> So, what do you think guys?
>
> --
> Take care,
> Cos
> 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
> Cos' pubkey: http://people.apache.org/~cos/cos.asc
>
> ---- Wisdom of the hour ----
>
> FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #4
> A: Go west, young man, go west!
> Q: What do wabbits do when they get tiwed of wunning awound?
Re: To speed up the development: shall we become a CTR project?
Posted by Jay Vyas <ja...@gmail.com>.
Commit-then-review? Intriguing. Can you propose the exact workflow you're suggesting?
> On Dec 24, 2014, at 7:16 PM, Konstantin Boudnik <co...@apache.org> wrote:
>
> I've been reading this discussion on Ignite (incubating) dev@ list
> http://s.apache.org/wPA and it clicked with the thread we were having in
> the last few days around the community and development processes.
>
> What do you guys think if we'll try CTR model? Committers here went through
> the process of gaining their karma and proved with their contributions that
> they don't need peer-reviews for a lot of things that are coming into the
> project on the daily basis. The RTC is especially annoying for trivial changes
> and is really making things slower than they could've been.
>
> So, what do you think guys?
>
> --
> Take care,
> Cos
> 2CAC 8312 4870 D885 8616 6115 220F 6980 1F27 E622
> Cos' pubkey: http://people.apache.org/~cos/cos.asc
>
> ---- Wisdom of the hour ----
>
> FORTUNE PROVIDES QUESTIONS FOR THE GREAT ANSWERS: #4
> A: Go west, young man, go west!
> Q: What do wabbits do when they get tiwed of wunning awound?