[DISCUSSION] workflow and review policy

[Hyunsik Choi <hy...@apache.org>]

Hi folks,

We need to discuss the development workflow and review policy. Many of
committers may be new to ASF development process, and each ASF project
has its own bylaws based on common process. Hence, we need to discuss
and decide them now.

First of all, you guys need to read the following documentation:

http://www.apache.org/foundation/voting.html#votes-on-code-modification
http://www.apache.org/foundation/glossary.html#CommitThenReview
http://www.apache.org/foundation/glossary.html#ReviewThenCommit

Most of the code modifications should involve voting process.
According to whether you guys follow lazy consensus or not, you can
choose CTR (commit then review) and RTC (review then commit).

Simply, RTC requires +1 from at least one committer without -1 before
the patch commit. CTS can get +1 even after the patch commit, but the
patch can be reverted according to the result of reviews.

Which policy do you guys prefer?

Best regards,
Hyunsik

Re: [DISCUSSION] workflow and review policy

[Hyunsik Choi <hy...@apache.org>]

Thanks a lot!

On Fri, Jan 8, 2016 at 5:37 AM, Jaesang Kim <ho...@gmail.com> wrote:
> Hello folks.
>
> Our Github mirror repository is created.
> https://github.com/apache/incubator-s2graph
>
>
> 2016년 1월 5일 (화) 오후 6:49, Hyunsik Choi <hy...@apache.org>님이 작성:
>
>> Many guys seem to prefer github and the workflow Do Young. I'll ask
>> INFRA team to add Github mirror for S2Graph. If we use github PR, it
>> will require the code review before pushing. Actually, it is like RTC
>> in my point of view. If I'm wrong about it, please let me know.
>>
>> Also, the important thing is that we should consistently follow the
>> bylaw of our community after we decide something.
>>
>> Best regards,
>> Hyunsik
>>
>> On Mon, Jan 4, 2016 at 9:32 PM, Jaesang Kim <ho...@gmail.com> wrote:
>> > make a Github mirror +1
>> >
>> >
>> > 2016년 1월 5일 (화) 오후 12:54, Kim, Min-Seok <ms...@gmail.com>님이 작성:
>> >
>> >> Whether the result is CTR or RTC, it's very convenience that the Github
>> >> mirror is made.
>> >>
>> >> Folks who agree to make a Github mirror or not, give me a comment,
>> please.
>> >> (make a Github mirror +1 or -1)
>> >>
>> >> Hyunsik, could you ask INFRA team to make Github?
>> >>
>> >> Sincerely yours
>> >>
>> >> Minseok
>> >>
>> >> On Mon, Jan 4, 2016 at 1:16 AM, Jaesang Kim <ho...@gmail.com>
>> wrote:
>> >>
>> >> > I vote +1 to CTR.
>> >> > I also like RTC, but currently our project is immature, we need many
>> code
>> >> > modifications.
>> >> > So, I think that CTR is more suitable to us. After a few releases, it
>> is
>> >> > better to change to RTC.
>> >> >
>> >> > Best regards,
>> >> > Jaesang
>> >> >
>> >> >
>> >> > 2015년 12월 31일 (목) 오전 11:59, Hyunsung Jo <hy...@gmail.com>님이 작성:
>> >> >
>> >> > > I think, in order for the previous workflow to truly fall into RTC
>> >> > > category, the review process should be more thorough.
>> >> > > By the looks, Apache Review Board (https://reviews.apache.org)
>> seems
>> >> > like
>> >> > > a
>> >> > > nice tool to achieve this.
>> >> > > I also support GitHub mirroring.
>> >> > >
>> >> > > Regards,
>> >> > > Jo
>> >> > >
>> >> > > On Thu, Dec 31, 2015 at 1:24 AM DO YUNG YOON <sh...@gmail.com>
>> wrote:
>> >> > >
>> >> > > > Had no idea it was RTC.
>> >> > > > if workflow I wrote is RTC then I am +1 with RTC. thanks for
>> >> > correction.
>> >> > > >
>> >> > > > I prefer PR through Github over Jira path.
>> >> > > > also like Luke suggested, +1 for applying Review Board and CI from
>> >> > INFRA.
>> >> > > >
>> >> > > >
>> >> > > >
>> >> > > > On Wed, Dec 30, 2015 at 3:56 PM, Hyunsik Choi <hyunsik@apache.org
>> >
>> >> > > wrote:
>> >> > > >
>> >> > > > > Thank you for comments. IMO, the workflow that Do Young
>> mentioned
>> >> is
>> >> > > > > RTC. It may be caused by some ambiguous terms around traditional
>> >> and
>> >> > > > > modern SCM tools. CTR and RTC in the ASF documentation seem to
>> be
>> >> > > > > based on traditional SCM tools like SVN and CVS. So, each commit
>> >> here
>> >> > > > > may mean pushed commit logs in GIT.
>> >> > > > >
>> >> > > > > Anyway, the workflow looks great to me.
>> >> > > > >
>> >> > > > > If you want to use github, we need to ask INFRA team to make
>> Github
>> >> > > > > mirror and enable PR on the github repo. If you guys agree with
>> >> that,
>> >> > > > > I'll ask it.
>> >> > > > >
>> >> > > > > Best regards,
>> >> > > > > Hyunsik
>> >> > > > >
>> >> > > > > On Mon, Dec 28, 2015 at 11:57 PM, blueiur <bl...@gmail.com>
>> >> wrote:
>> >> > > > > > CTR +1
>> >> > > > > >
>> >> > > > > >
>> >> > > > > > On Tue, Dec 29, 2015 at 4:48 PM Hyunsung Jo <
>> >> hyunsung.jo@gmail.com
>> >> > >
>> >> > > > > wrote:
>> >> > > > > >
>> >> > > > > >> I have no problem with the pre-apache workflow as long as it
>> >> > > complies
>> >> > > > > >> with ASF standards.
>> >> > > > > >> So one up for CTR.
>> >> > > > > >>
>> >> > > > > >> On Tue, Dec 29, 2015 at 1:31 PM Luke Han <lu...@gmail.com>
>> >> > wrote:
>> >> > > > > >>
>> >> > > > > >> > CTR is more easy for new committer to join and practice in
>> our
>> >> > > > > community.
>> >> > > > > >> >
>> >> > > > > >> > We also could apply Review Board and CI from INFRA to
>> leverage
>> >> > > such
>> >> > > > > >> tools.
>> >> > > > > >> >
>> >> > > > > >> > And, we also should discuss about to continue leverage
>> >> > github.com
>> >> > > > PR
>> >> > > > > or
>> >> > > > > >> > JIRA patch.
>> >> > > > > >> > Github.com code repo is just mirrored from Apache git repo
>> >> which
>> >> > > do
>> >> > > > > not
>> >> > > > > >> > support PR yet, so we need additional step to merge any PR
>> >> from
>> >> > > > > >> github.com
>> >> > > > > >> > .
>> >> > > > > >> >
>> >> > > > > >> > Thanks.
>> >> > > > > >> >
>> >> > > > > >> >
>> >> > > > > >> > Best Regards!
>> >> > > > > >> > ---------------------
>> >> > > > > >> >
>> >> > > > > >> > Luke Han
>> >> > > > > >> >
>> >> > > > > >> > On Tue, Dec 29, 2015 at 10:10 AM, Kim, Min-Seok <
>> >> > > > mskim.org@gmail.com>
>> >> > > > > >> > wrote:
>> >> > > > > >> >
>> >> > > > > >> > > As Do Yung mentioned, I have worked as the process.
>> >> > > > > >> > >
>> >> > > > > >> > > So I prefer CTR, but I am also willing to learn if there
>> is
>> >> a
>> >> > > > better
>> >> > > > > >> way.
>> >> > > > > >> > >
>> >> > > > > >> > > Minseok
>> >> > > > > >> > >
>> >> > > > > >> > > On Tue, Dec 29, 2015 at 10:33 AM, DO YUNG YOON <
>> >> > > shom83@gmail.com>
>> >> > > > > >> wrote:
>> >> > > > > >> > >
>> >> > > > > >> > > > regarding to workflow, following was how I have worked
>> >> with
>> >> > > > > S2Graph
>> >> > > > > >> > > before
>> >> > > > > >> > > > ASF incubation.
>> >> > > > > >> > > >
>> >> > > > > >> > > > 1. create Issue.
>> >> > > > > >> > > > 2. create branch with Issue number.
>> >> > > > > >> > > > 3. all works related to issue committed into Issue
>> branch.
>> >> > > > > >> > > > 4. create PR.
>> >> > > > > >> > > > 5. review through github.
>> >> > > > > >> > > > 6. squash and merge them into develop.
>> >> > > > > >> > > > 7. run all test cases on develop branch.
>> >> > > > > >> > > > 8. merge develop into master.
>> >> > > > > >> > > >
>> >> > > > > >> > > > above has been works pretty well for me so I prefer
>> CTR,
>> >> > but I
>> >> > > > am
>> >> > > > > >> > willing
>> >> > > > > >> > > > to learn if there is better way.
>> >> > > > > >> > > >
>> >> > > > > >> > > >
>> >> > > > > >> > > >
>> >> > > > > >> > > >
>> >> > > > > >> > > > On Mon, Dec 28, 2015 at 2:11 PM Hyunsik Choi <
>> >> > > > hyunsik@apache.org>
>> >> > > > > >> > wrote:
>> >> > > > > >> > > >
>> >> > > > > >> > > > > Hi folks,
>> >> > > > > >> > > > >
>> >> > > > > >> > > > > We need to discuss the development workflow and
>> review
>> >> > > policy.
>> >> > > > > Many
>> >> > > > > >> > of
>> >> > > > > >> > > > > committers may be new to ASF development process, and
>> >> each
>> >> > > ASF
>> >> > > > > >> > project
>> >> > > > > >> > > > > has its own bylaws based on common process. Hence, we
>> >> need
>> >> > > to
>> >> > > > > >> discuss
>> >> > > > > >> > > > > and decide them now.
>> >> > > > > >> > > > >
>> >> > > > > >> > > > > First of all, you guys need to read the following
>> >> > > > documentation:
>> >> > > > > >> > > > >
>> >> > > > > >> > > > >
>> >> > > > > >> > >
>> >> > > > > >>
>> >> > > >
>> >> >
>> http://www.apache.org/foundation/voting.html#votes-on-code-modification
>> >> > > > > >> > > > >
>> >> > > > http://www.apache.org/foundation/glossary.html#CommitThenReview
>> >> > > > > >> > > > >
>> >> > > > http://www.apache.org/foundation/glossary.html#ReviewThenCommit
>> >> > > > > >> > > > >
>> >> > > > > >> > > > > Most of the code modifications should involve voting
>> >> > > process.
>> >> > > > > >> > > > > According to whether you guys follow lazy consensus
>> or
>> >> > not,
>> >> > > > you
>> >> > > > > can
>> >> > > > > >> > > > > choose CTR (commit then review) and RTC (review then
>> >> > > commit).
>> >> > > > > >> > > > >
>> >> > > > > >> > > > > Simply, RTC requires +1 from at least one committer
>> >> > without
>> >> > > -1
>> >> > > > > >> before
>> >> > > > > >> > > > > the patch commit. CTS can get +1 even after the patch
>> >> > > commit,
>> >> > > > > but
>> >> > > > > >> the
>> >> > > > > >> > > > > patch can be reverted according to the result of
>> >> reviews.
>> >> > > > > >> > > > >
>> >> > > > > >> > > > > Which policy do you guys prefer?
>> >> > > > > >> > > > >
>> >> > > > > >> > > > > Best regards,
>> >> > > > > >> > > > > Hyunsik
>> >> > > > > >> > > > >
>> >> > > > > >> > > >
>> >> > > > > >> > >
>> >> > > > > >> >
>> >> > > > > >>
>> >> > > > >
>> >> > > >
>> >> > >
>> >> >
>> >>
>> > --
>> > Best regards,
>> > Jaesang
>>
> --
> Best regards,
> Jaesang

Re: [DISCUSSION] workflow and review policy

[Jaesang Kim <ho...@gmail.com>]

Hello folks.

Our Github mirror repository is created.
https://github.com/apache/incubator-s2graph


2016년 1월 5일 (화) 오후 6:49, Hyunsik Choi <hy...@apache.org>님이 작성:

> Many guys seem to prefer github and the workflow Do Young. I'll ask
> INFRA team to add Github mirror for S2Graph. If we use github PR, it
> will require the code review before pushing. Actually, it is like RTC
> in my point of view. If I'm wrong about it, please let me know.
>
> Also, the important thing is that we should consistently follow the
> bylaw of our community after we decide something.
>
> Best regards,
> Hyunsik
>
> On Mon, Jan 4, 2016 at 9:32 PM, Jaesang Kim <ho...@gmail.com> wrote:
> > make a Github mirror +1
> >
> >
> > 2016년 1월 5일 (화) 오후 12:54, Kim, Min-Seok <ms...@gmail.com>님이 작성:
> >
> >> Whether the result is CTR or RTC, it's very convenience that the Github
> >> mirror is made.
> >>
> >> Folks who agree to make a Github mirror or not, give me a comment,
> please.
> >> (make a Github mirror +1 or -1)
> >>
> >> Hyunsik, could you ask INFRA team to make Github?
> >>
> >> Sincerely yours
> >>
> >> Minseok
> >>
> >> On Mon, Jan 4, 2016 at 1:16 AM, Jaesang Kim <ho...@gmail.com>
> wrote:
> >>
> >> > I vote +1 to CTR.
> >> > I also like RTC, but currently our project is immature, we need many
> code
> >> > modifications.
> >> > So, I think that CTR is more suitable to us. After a few releases, it
> is
> >> > better to change to RTC.
> >> >
> >> > Best regards,
> >> > Jaesang
> >> >
> >> >
> >> > 2015년 12월 31일 (목) 오전 11:59, Hyunsung Jo <hy...@gmail.com>님이 작성:
> >> >
> >> > > I think, in order for the previous workflow to truly fall into RTC
> >> > > category, the review process should be more thorough.
> >> > > By the looks, Apache Review Board (https://reviews.apache.org)
> seems
> >> > like
> >> > > a
> >> > > nice tool to achieve this.
> >> > > I also support GitHub mirroring.
> >> > >
> >> > > Regards,
> >> > > Jo
> >> > >
> >> > > On Thu, Dec 31, 2015 at 1:24 AM DO YUNG YOON <sh...@gmail.com>
> wrote:
> >> > >
> >> > > > Had no idea it was RTC.
> >> > > > if workflow I wrote is RTC then I am +1 with RTC. thanks for
> >> > correction.
> >> > > >
> >> > > > I prefer PR through Github over Jira path.
> >> > > > also like Luke suggested, +1 for applying Review Board and CI from
> >> > INFRA.
> >> > > >
> >> > > >
> >> > > >
> >> > > > On Wed, Dec 30, 2015 at 3:56 PM, Hyunsik Choi <hyunsik@apache.org
> >
> >> > > wrote:
> >> > > >
> >> > > > > Thank you for comments. IMO, the workflow that Do Young
> mentioned
> >> is
> >> > > > > RTC. It may be caused by some ambiguous terms around traditional
> >> and
> >> > > > > modern SCM tools. CTR and RTC in the ASF documentation seem to
> be
> >> > > > > based on traditional SCM tools like SVN and CVS. So, each commit
> >> here
> >> > > > > may mean pushed commit logs in GIT.
> >> > > > >
> >> > > > > Anyway, the workflow looks great to me.
> >> > > > >
> >> > > > > If you want to use github, we need to ask INFRA team to make
> Github
> >> > > > > mirror and enable PR on the github repo. If you guys agree with
> >> that,
> >> > > > > I'll ask it.
> >> > > > >
> >> > > > > Best regards,
> >> > > > > Hyunsik
> >> > > > >
> >> > > > > On Mon, Dec 28, 2015 at 11:57 PM, blueiur <bl...@gmail.com>
> >> wrote:
> >> > > > > > CTR +1
> >> > > > > >
> >> > > > > >
> >> > > > > > On Tue, Dec 29, 2015 at 4:48 PM Hyunsung Jo <
> >> hyunsung.jo@gmail.com
> >> > >
> >> > > > > wrote:
> >> > > > > >
> >> > > > > >> I have no problem with the pre-apache workflow as long as it
> >> > > complies
> >> > > > > >> with ASF standards.
> >> > > > > >> So one up for CTR.
> >> > > > > >>
> >> > > > > >> On Tue, Dec 29, 2015 at 1:31 PM Luke Han <lu...@gmail.com>
> >> > wrote:
> >> > > > > >>
> >> > > > > >> > CTR is more easy for new committer to join and practice in
> our
> >> > > > > community.
> >> > > > > >> >
> >> > > > > >> > We also could apply Review Board and CI from INFRA to
> leverage
> >> > > such
> >> > > > > >> tools.
> >> > > > > >> >
> >> > > > > >> > And, we also should discuss about to continue leverage
> >> > github.com
> >> > > > PR
> >> > > > > or
> >> > > > > >> > JIRA patch.
> >> > > > > >> > Github.com code repo is just mirrored from Apache git repo
> >> which
> >> > > do
> >> > > > > not
> >> > > > > >> > support PR yet, so we need additional step to merge any PR
> >> from
> >> > > > > >> github.com
> >> > > > > >> > .
> >> > > > > >> >
> >> > > > > >> > Thanks.
> >> > > > > >> >
> >> > > > > >> >
> >> > > > > >> > Best Regards!
> >> > > > > >> > ---------------------
> >> > > > > >> >
> >> > > > > >> > Luke Han
> >> > > > > >> >
> >> > > > > >> > On Tue, Dec 29, 2015 at 10:10 AM, Kim, Min-Seok <
> >> > > > mskim.org@gmail.com>
> >> > > > > >> > wrote:
> >> > > > > >> >
> >> > > > > >> > > As Do Yung mentioned, I have worked as the process.
> >> > > > > >> > >
> >> > > > > >> > > So I prefer CTR, but I am also willing to learn if there
> is
> >> a
> >> > > > better
> >> > > > > >> way.
> >> > > > > >> > >
> >> > > > > >> > > Minseok
> >> > > > > >> > >
> >> > > > > >> > > On Tue, Dec 29, 2015 at 10:33 AM, DO YUNG YOON <
> >> > > shom83@gmail.com>
> >> > > > > >> wrote:
> >> > > > > >> > >
> >> > > > > >> > > > regarding to workflow, following was how I have worked
> >> with
> >> > > > > S2Graph
> >> > > > > >> > > before
> >> > > > > >> > > > ASF incubation.
> >> > > > > >> > > >
> >> > > > > >> > > > 1. create Issue.
> >> > > > > >> > > > 2. create branch with Issue number.
> >> > > > > >> > > > 3. all works related to issue committed into Issue
> branch.
> >> > > > > >> > > > 4. create PR.
> >> > > > > >> > > > 5. review through github.
> >> > > > > >> > > > 6. squash and merge them into develop.
> >> > > > > >> > > > 7. run all test cases on develop branch.
> >> > > > > >> > > > 8. merge develop into master.
> >> > > > > >> > > >
> >> > > > > >> > > > above has been works pretty well for me so I prefer
> CTR,
> >> > but I
> >> > > > am
> >> > > > > >> > willing
> >> > > > > >> > > > to learn if there is better way.
> >> > > > > >> > > >
> >> > > > > >> > > >
> >> > > > > >> > > >
> >> > > > > >> > > >
> >> > > > > >> > > > On Mon, Dec 28, 2015 at 2:11 PM Hyunsik Choi <
> >> > > > hyunsik@apache.org>
> >> > > > > >> > wrote:
> >> > > > > >> > > >
> >> > > > > >> > > > > Hi folks,
> >> > > > > >> > > > >
> >> > > > > >> > > > > We need to discuss the development workflow and
> review
> >> > > policy.
> >> > > > > Many
> >> > > > > >> > of
> >> > > > > >> > > > > committers may be new to ASF development process, and
> >> each
> >> > > ASF
> >> > > > > >> > project
> >> > > > > >> > > > > has its own bylaws based on common process. Hence, we
> >> need
> >> > > to
> >> > > > > >> discuss
> >> > > > > >> > > > > and decide them now.
> >> > > > > >> > > > >
> >> > > > > >> > > > > First of all, you guys need to read the following
> >> > > > documentation:
> >> > > > > >> > > > >
> >> > > > > >> > > > >
> >> > > > > >> > >
> >> > > > > >>
> >> > > >
> >> >
> http://www.apache.org/foundation/voting.html#votes-on-code-modification
> >> > > > > >> > > > >
> >> > > > http://www.apache.org/foundation/glossary.html#CommitThenReview
> >> > > > > >> > > > >
> >> > > > http://www.apache.org/foundation/glossary.html#ReviewThenCommit
> >> > > > > >> > > > >
> >> > > > > >> > > > > Most of the code modifications should involve voting
> >> > > process.
> >> > > > > >> > > > > According to whether you guys follow lazy consensus
> or
> >> > not,
> >> > > > you
> >> > > > > can
> >> > > > > >> > > > > choose CTR (commit then review) and RTC (review then
> >> > > commit).
> >> > > > > >> > > > >
> >> > > > > >> > > > > Simply, RTC requires +1 from at least one committer
> >> > without
> >> > > -1
> >> > > > > >> before
> >> > > > > >> > > > > the patch commit. CTS can get +1 even after the patch
> >> > > commit,
> >> > > > > but
> >> > > > > >> the
> >> > > > > >> > > > > patch can be reverted according to the result of
> >> reviews.
> >> > > > > >> > > > >
> >> > > > > >> > > > > Which policy do you guys prefer?
> >> > > > > >> > > > >
> >> > > > > >> > > > > Best regards,
> >> > > > > >> > > > > Hyunsik
> >> > > > > >> > > > >
> >> > > > > >> > > >
> >> > > > > >> > >
> >> > > > > >> >
> >> > > > > >>
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
> > --
> > Best regards,
> > Jaesang
>
-- 
Best regards,
Jaesang

Re: [DISCUSSION] workflow and review policy

[Hyunsik Choi <hy...@apache.org>]

Many guys seem to prefer github and the workflow Do Young. I'll ask
INFRA team to add Github mirror for S2Graph. If we use github PR, it
will require the code review before pushing. Actually, it is like RTC
in my point of view. If I'm wrong about it, please let me know.

Also, the important thing is that we should consistently follow the
bylaw of our community after we decide something.

Best regards,
Hyunsik

On Mon, Jan 4, 2016 at 9:32 PM, Jaesang Kim <ho...@gmail.com> wrote:
> make a Github mirror +1
>
>
> 2016년 1월 5일 (화) 오후 12:54, Kim, Min-Seok <ms...@gmail.com>님이 작성:
>
>> Whether the result is CTR or RTC, it's very convenience that the Github
>> mirror is made.
>>
>> Folks who agree to make a Github mirror or not, give me a comment, please.
>> (make a Github mirror +1 or -1)
>>
>> Hyunsik, could you ask INFRA team to make Github?
>>
>> Sincerely yours
>>
>> Minseok
>>
>> On Mon, Jan 4, 2016 at 1:16 AM, Jaesang Kim <ho...@gmail.com> wrote:
>>
>> > I vote +1 to CTR.
>> > I also like RTC, but currently our project is immature, we need many code
>> > modifications.
>> > So, I think that CTR is more suitable to us. After a few releases, it is
>> > better to change to RTC.
>> >
>> > Best regards,
>> > Jaesang
>> >
>> >
>> > 2015년 12월 31일 (목) 오전 11:59, Hyunsung Jo <hy...@gmail.com>님이 작성:
>> >
>> > > I think, in order for the previous workflow to truly fall into RTC
>> > > category, the review process should be more thorough.
>> > > By the looks, Apache Review Board (https://reviews.apache.org) seems
>> > like
>> > > a
>> > > nice tool to achieve this.
>> > > I also support GitHub mirroring.
>> > >
>> > > Regards,
>> > > Jo
>> > >
>> > > On Thu, Dec 31, 2015 at 1:24 AM DO YUNG YOON <sh...@gmail.com> wrote:
>> > >
>> > > > Had no idea it was RTC.
>> > > > if workflow I wrote is RTC then I am +1 with RTC. thanks for
>> > correction.
>> > > >
>> > > > I prefer PR through Github over Jira path.
>> > > > also like Luke suggested, +1 for applying Review Board and CI from
>> > INFRA.
>> > > >
>> > > >
>> > > >
>> > > > On Wed, Dec 30, 2015 at 3:56 PM, Hyunsik Choi <hy...@apache.org>
>> > > wrote:
>> > > >
>> > > > > Thank you for comments. IMO, the workflow that Do Young mentioned
>> is
>> > > > > RTC. It may be caused by some ambiguous terms around traditional
>> and
>> > > > > modern SCM tools. CTR and RTC in the ASF documentation seem to be
>> > > > > based on traditional SCM tools like SVN and CVS. So, each commit
>> here
>> > > > > may mean pushed commit logs in GIT.
>> > > > >
>> > > > > Anyway, the workflow looks great to me.
>> > > > >
>> > > > > If you want to use github, we need to ask INFRA team to make Github
>> > > > > mirror and enable PR on the github repo. If you guys agree with
>> that,
>> > > > > I'll ask it.
>> > > > >
>> > > > > Best regards,
>> > > > > Hyunsik
>> > > > >
>> > > > > On Mon, Dec 28, 2015 at 11:57 PM, blueiur <bl...@gmail.com>
>> wrote:
>> > > > > > CTR +1
>> > > > > >
>> > > > > >
>> > > > > > On Tue, Dec 29, 2015 at 4:48 PM Hyunsung Jo <
>> hyunsung.jo@gmail.com
>> > >
>> > > > > wrote:
>> > > > > >
>> > > > > >> I have no problem with the pre-apache workflow as long as it
>> > > complies
>> > > > > >> with ASF standards.
>> > > > > >> So one up for CTR.
>> > > > > >>
>> > > > > >> On Tue, Dec 29, 2015 at 1:31 PM Luke Han <lu...@gmail.com>
>> > wrote:
>> > > > > >>
>> > > > > >> > CTR is more easy for new committer to join and practice in our
>> > > > > community.
>> > > > > >> >
>> > > > > >> > We also could apply Review Board and CI from INFRA to leverage
>> > > such
>> > > > > >> tools.
>> > > > > >> >
>> > > > > >> > And, we also should discuss about to continue leverage
>> > github.com
>> > > > PR
>> > > > > or
>> > > > > >> > JIRA patch.
>> > > > > >> > Github.com code repo is just mirrored from Apache git repo
>> which
>> > > do
>> > > > > not
>> > > > > >> > support PR yet, so we need additional step to merge any PR
>> from
>> > > > > >> github.com
>> > > > > >> > .
>> > > > > >> >
>> > > > > >> > Thanks.
>> > > > > >> >
>> > > > > >> >
>> > > > > >> > Best Regards!
>> > > > > >> > ---------------------
>> > > > > >> >
>> > > > > >> > Luke Han
>> > > > > >> >
>> > > > > >> > On Tue, Dec 29, 2015 at 10:10 AM, Kim, Min-Seok <
>> > > > mskim.org@gmail.com>
>> > > > > >> > wrote:
>> > > > > >> >
>> > > > > >> > > As Do Yung mentioned, I have worked as the process.
>> > > > > >> > >
>> > > > > >> > > So I prefer CTR, but I am also willing to learn if there is
>> a
>> > > > better
>> > > > > >> way.
>> > > > > >> > >
>> > > > > >> > > Minseok
>> > > > > >> > >
>> > > > > >> > > On Tue, Dec 29, 2015 at 10:33 AM, DO YUNG YOON <
>> > > shom83@gmail.com>
>> > > > > >> wrote:
>> > > > > >> > >
>> > > > > >> > > > regarding to workflow, following was how I have worked
>> with
>> > > > > S2Graph
>> > > > > >> > > before
>> > > > > >> > > > ASF incubation.
>> > > > > >> > > >
>> > > > > >> > > > 1. create Issue.
>> > > > > >> > > > 2. create branch with Issue number.
>> > > > > >> > > > 3. all works related to issue committed into Issue branch.
>> > > > > >> > > > 4. create PR.
>> > > > > >> > > > 5. review through github.
>> > > > > >> > > > 6. squash and merge them into develop.
>> > > > > >> > > > 7. run all test cases on develop branch.
>> > > > > >> > > > 8. merge develop into master.
>> > > > > >> > > >
>> > > > > >> > > > above has been works pretty well for me so I prefer CTR,
>> > but I
>> > > > am
>> > > > > >> > willing
>> > > > > >> > > > to learn if there is better way.
>> > > > > >> > > >
>> > > > > >> > > >
>> > > > > >> > > >
>> > > > > >> > > >
>> > > > > >> > > > On Mon, Dec 28, 2015 at 2:11 PM Hyunsik Choi <
>> > > > hyunsik@apache.org>
>> > > > > >> > wrote:
>> > > > > >> > > >
>> > > > > >> > > > > Hi folks,
>> > > > > >> > > > >
>> > > > > >> > > > > We need to discuss the development workflow and review
>> > > policy.
>> > > > > Many
>> > > > > >> > of
>> > > > > >> > > > > committers may be new to ASF development process, and
>> each
>> > > ASF
>> > > > > >> > project
>> > > > > >> > > > > has its own bylaws based on common process. Hence, we
>> need
>> > > to
>> > > > > >> discuss
>> > > > > >> > > > > and decide them now.
>> > > > > >> > > > >
>> > > > > >> > > > > First of all, you guys need to read the following
>> > > > documentation:
>> > > > > >> > > > >
>> > > > > >> > > > >
>> > > > > >> > >
>> > > > > >>
>> > > >
>> > http://www.apache.org/foundation/voting.html#votes-on-code-modification
>> > > > > >> > > > >
>> > > > http://www.apache.org/foundation/glossary.html#CommitThenReview
>> > > > > >> > > > >
>> > > > http://www.apache.org/foundation/glossary.html#ReviewThenCommit
>> > > > > >> > > > >
>> > > > > >> > > > > Most of the code modifications should involve voting
>> > > process.
>> > > > > >> > > > > According to whether you guys follow lazy consensus or
>> > not,
>> > > > you
>> > > > > can
>> > > > > >> > > > > choose CTR (commit then review) and RTC (review then
>> > > commit).
>> > > > > >> > > > >
>> > > > > >> > > > > Simply, RTC requires +1 from at least one committer
>> > without
>> > > -1
>> > > > > >> before
>> > > > > >> > > > > the patch commit. CTS can get +1 even after the patch
>> > > commit,
>> > > > > but
>> > > > > >> the
>> > > > > >> > > > > patch can be reverted according to the result of
>> reviews.
>> > > > > >> > > > >
>> > > > > >> > > > > Which policy do you guys prefer?
>> > > > > >> > > > >
>> > > > > >> > > > > Best regards,
>> > > > > >> > > > > Hyunsik
>> > > > > >> > > > >
>> > > > > >> > > >
>> > > > > >> > >
>> > > > > >> >
>> > > > > >>
>> > > > >
>> > > >
>> > >
>> >
>>
> --
> Best regards,
> Jaesang

Re: [DISCUSSION] workflow and review policy

[Jaesang Kim <ho...@gmail.com>]

make a Github mirror +1


2016년 1월 5일 (화) 오후 12:54, Kim, Min-Seok <ms...@gmail.com>님이 작성:

> Whether the result is CTR or RTC, it's very convenience that the Github
> mirror is made.
>
> Folks who agree to make a Github mirror or not, give me a comment, please.
> (make a Github mirror +1 or -1)
>
> Hyunsik, could you ask INFRA team to make Github?
>
> Sincerely yours
>
> Minseok
>
> On Mon, Jan 4, 2016 at 1:16 AM, Jaesang Kim <ho...@gmail.com> wrote:
>
> > I vote +1 to CTR.
> > I also like RTC, but currently our project is immature, we need many code
> > modifications.
> > So, I think that CTR is more suitable to us. After a few releases, it is
> > better to change to RTC.
> >
> > Best regards,
> > Jaesang
> >
> >
> > 2015년 12월 31일 (목) 오전 11:59, Hyunsung Jo <hy...@gmail.com>님이 작성:
> >
> > > I think, in order for the previous workflow to truly fall into RTC
> > > category, the review process should be more thorough.
> > > By the looks, Apache Review Board (https://reviews.apache.org) seems
> > like
> > > a
> > > nice tool to achieve this.
> > > I also support GitHub mirroring.
> > >
> > > Regards,
> > > Jo
> > >
> > > On Thu, Dec 31, 2015 at 1:24 AM DO YUNG YOON <sh...@gmail.com> wrote:
> > >
> > > > Had no idea it was RTC.
> > > > if workflow I wrote is RTC then I am +1 with RTC. thanks for
> > correction.
> > > >
> > > > I prefer PR through Github over Jira path.
> > > > also like Luke suggested, +1 for applying Review Board and CI from
> > INFRA.
> > > >
> > > >
> > > >
> > > > On Wed, Dec 30, 2015 at 3:56 PM, Hyunsik Choi <hy...@apache.org>
> > > wrote:
> > > >
> > > > > Thank you for comments. IMO, the workflow that Do Young mentioned
> is
> > > > > RTC. It may be caused by some ambiguous terms around traditional
> and
> > > > > modern SCM tools. CTR and RTC in the ASF documentation seem to be
> > > > > based on traditional SCM tools like SVN and CVS. So, each commit
> here
> > > > > may mean pushed commit logs in GIT.
> > > > >
> > > > > Anyway, the workflow looks great to me.
> > > > >
> > > > > If you want to use github, we need to ask INFRA team to make Github
> > > > > mirror and enable PR on the github repo. If you guys agree with
> that,
> > > > > I'll ask it.
> > > > >
> > > > > Best regards,
> > > > > Hyunsik
> > > > >
> > > > > On Mon, Dec 28, 2015 at 11:57 PM, blueiur <bl...@gmail.com>
> wrote:
> > > > > > CTR +1
> > > > > >
> > > > > >
> > > > > > On Tue, Dec 29, 2015 at 4:48 PM Hyunsung Jo <
> hyunsung.jo@gmail.com
> > >
> > > > > wrote:
> > > > > >
> > > > > >> I have no problem with the pre-apache workflow as long as it
> > > complies
> > > > > >> with ASF standards.
> > > > > >> So one up for CTR.
> > > > > >>
> > > > > >> On Tue, Dec 29, 2015 at 1:31 PM Luke Han <lu...@gmail.com>
> > wrote:
> > > > > >>
> > > > > >> > CTR is more easy for new committer to join and practice in our
> > > > > community.
> > > > > >> >
> > > > > >> > We also could apply Review Board and CI from INFRA to leverage
> > > such
> > > > > >> tools.
> > > > > >> >
> > > > > >> > And, we also should discuss about to continue leverage
> > github.com
> > > > PR
> > > > > or
> > > > > >> > JIRA patch.
> > > > > >> > Github.com code repo is just mirrored from Apache git repo
> which
> > > do
> > > > > not
> > > > > >> > support PR yet, so we need additional step to merge any PR
> from
> > > > > >> github.com
> > > > > >> > .
> > > > > >> >
> > > > > >> > Thanks.
> > > > > >> >
> > > > > >> >
> > > > > >> > Best Regards!
> > > > > >> > ---------------------
> > > > > >> >
> > > > > >> > Luke Han
> > > > > >> >
> > > > > >> > On Tue, Dec 29, 2015 at 10:10 AM, Kim, Min-Seok <
> > > > mskim.org@gmail.com>
> > > > > >> > wrote:
> > > > > >> >
> > > > > >> > > As Do Yung mentioned, I have worked as the process.
> > > > > >> > >
> > > > > >> > > So I prefer CTR, but I am also willing to learn if there is
> a
> > > > better
> > > > > >> way.
> > > > > >> > >
> > > > > >> > > Minseok
> > > > > >> > >
> > > > > >> > > On Tue, Dec 29, 2015 at 10:33 AM, DO YUNG YOON <
> > > shom83@gmail.com>
> > > > > >> wrote:
> > > > > >> > >
> > > > > >> > > > regarding to workflow, following was how I have worked
> with
> > > > > S2Graph
> > > > > >> > > before
> > > > > >> > > > ASF incubation.
> > > > > >> > > >
> > > > > >> > > > 1. create Issue.
> > > > > >> > > > 2. create branch with Issue number.
> > > > > >> > > > 3. all works related to issue committed into Issue branch.
> > > > > >> > > > 4. create PR.
> > > > > >> > > > 5. review through github.
> > > > > >> > > > 6. squash and merge them into develop.
> > > > > >> > > > 7. run all test cases on develop branch.
> > > > > >> > > > 8. merge develop into master.
> > > > > >> > > >
> > > > > >> > > > above has been works pretty well for me so I prefer CTR,
> > but I
> > > > am
> > > > > >> > willing
> > > > > >> > > > to learn if there is better way.
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > >
> > > > > >> > > > On Mon, Dec 28, 2015 at 2:11 PM Hyunsik Choi <
> > > > hyunsik@apache.org>
> > > > > >> > wrote:
> > > > > >> > > >
> > > > > >> > > > > Hi folks,
> > > > > >> > > > >
> > > > > >> > > > > We need to discuss the development workflow and review
> > > policy.
> > > > > Many
> > > > > >> > of
> > > > > >> > > > > committers may be new to ASF development process, and
> each
> > > ASF
> > > > > >> > project
> > > > > >> > > > > has its own bylaws based on common process. Hence, we
> need
> > > to
> > > > > >> discuss
> > > > > >> > > > > and decide them now.
> > > > > >> > > > >
> > > > > >> > > > > First of all, you guys need to read the following
> > > > documentation:
> > > > > >> > > > >
> > > > > >> > > > >
> > > > > >> > >
> > > > > >>
> > > >
> > http://www.apache.org/foundation/voting.html#votes-on-code-modification
> > > > > >> > > > >
> > > > http://www.apache.org/foundation/glossary.html#CommitThenReview
> > > > > >> > > > >
> > > > http://www.apache.org/foundation/glossary.html#ReviewThenCommit
> > > > > >> > > > >
> > > > > >> > > > > Most of the code modifications should involve voting
> > > process.
> > > > > >> > > > > According to whether you guys follow lazy consensus or
> > not,
> > > > you
> > > > > can
> > > > > >> > > > > choose CTR (commit then review) and RTC (review then
> > > commit).
> > > > > >> > > > >
> > > > > >> > > > > Simply, RTC requires +1 from at least one committer
> > without
> > > -1
> > > > > >> before
> > > > > >> > > > > the patch commit. CTS can get +1 even after the patch
> > > commit,
> > > > > but
> > > > > >> the
> > > > > >> > > > > patch can be reverted according to the result of
> reviews.
> > > > > >> > > > >
> > > > > >> > > > > Which policy do you guys prefer?
> > > > > >> > > > >
> > > > > >> > > > > Best regards,
> > > > > >> > > > > Hyunsik
> > > > > >> > > > >
> > > > > >> > > >
> > > > > >> > >
> > > > > >> >
> > > > > >>
> > > > >
> > > >
> > >
> >
>
-- 
Best regards,
Jaesang

Re: [DISCUSSION] workflow and review policy

["Kim, Min-Seok" <ms...@gmail.com>]

Whether the result is CTR or RTC, it's very convenience that the Github
mirror is made.

Folks who agree to make a Github mirror or not, give me a comment, please.
(make a Github mirror +1 or -1)

Hyunsik, could you ask INFRA team to make Github?

Sincerely yours

Minseok

On Mon, Jan 4, 2016 at 1:16 AM, Jaesang Kim <ho...@gmail.com> wrote:

> I vote +1 to CTR.
> I also like RTC, but currently our project is immature, we need many code
> modifications.
> So, I think that CTR is more suitable to us. After a few releases, it is
> better to change to RTC.
>
> Best regards,
> Jaesang
>
>
> 2015년 12월 31일 (목) 오전 11:59, Hyunsung Jo <hy...@gmail.com>님이 작성:
>
> > I think, in order for the previous workflow to truly fall into RTC
> > category, the review process should be more thorough.
> > By the looks, Apache Review Board (https://reviews.apache.org) seems
> like
> > a
> > nice tool to achieve this.
> > I also support GitHub mirroring.
> >
> > Regards,
> > Jo
> >
> > On Thu, Dec 31, 2015 at 1:24 AM DO YUNG YOON <sh...@gmail.com> wrote:
> >
> > > Had no idea it was RTC.
> > > if workflow I wrote is RTC then I am +1 with RTC. thanks for
> correction.
> > >
> > > I prefer PR through Github over Jira path.
> > > also like Luke suggested, +1 for applying Review Board and CI from
> INFRA.
> > >
> > >
> > >
> > > On Wed, Dec 30, 2015 at 3:56 PM, Hyunsik Choi <hy...@apache.org>
> > wrote:
> > >
> > > > Thank you for comments. IMO, the workflow that Do Young mentioned is
> > > > RTC. It may be caused by some ambiguous terms around traditional and
> > > > modern SCM tools. CTR and RTC in the ASF documentation seem to be
> > > > based on traditional SCM tools like SVN and CVS. So, each commit here
> > > > may mean pushed commit logs in GIT.
> > > >
> > > > Anyway, the workflow looks great to me.
> > > >
> > > > If you want to use github, we need to ask INFRA team to make Github
> > > > mirror and enable PR on the github repo. If you guys agree with that,
> > > > I'll ask it.
> > > >
> > > > Best regards,
> > > > Hyunsik
> > > >
> > > > On Mon, Dec 28, 2015 at 11:57 PM, blueiur <bl...@gmail.com> wrote:
> > > > > CTR +1
> > > > >
> > > > >
> > > > > On Tue, Dec 29, 2015 at 4:48 PM Hyunsung Jo <hyunsung.jo@gmail.com
> >
> > > > wrote:
> > > > >
> > > > >> I have no problem with the pre-apache workflow as long as it
> > complies
> > > > >> with ASF standards.
> > > > >> So one up for CTR.
> > > > >>
> > > > >> On Tue, Dec 29, 2015 at 1:31 PM Luke Han <lu...@gmail.com>
> wrote:
> > > > >>
> > > > >> > CTR is more easy for new committer to join and practice in our
> > > > community.
> > > > >> >
> > > > >> > We also could apply Review Board and CI from INFRA to leverage
> > such
> > > > >> tools.
> > > > >> >
> > > > >> > And, we also should discuss about to continue leverage
> github.com
> > > PR
> > > > or
> > > > >> > JIRA patch.
> > > > >> > Github.com code repo is just mirrored from Apache git repo which
> > do
> > > > not
> > > > >> > support PR yet, so we need additional step to merge any PR from
> > > > >> github.com
> > > > >> > .
> > > > >> >
> > > > >> > Thanks.
> > > > >> >
> > > > >> >
> > > > >> > Best Regards!
> > > > >> > ---------------------
> > > > >> >
> > > > >> > Luke Han
> > > > >> >
> > > > >> > On Tue, Dec 29, 2015 at 10:10 AM, Kim, Min-Seok <
> > > mskim.org@gmail.com>
> > > > >> > wrote:
> > > > >> >
> > > > >> > > As Do Yung mentioned, I have worked as the process.
> > > > >> > >
> > > > >> > > So I prefer CTR, but I am also willing to learn if there is a
> > > better
> > > > >> way.
> > > > >> > >
> > > > >> > > Minseok
> > > > >> > >
> > > > >> > > On Tue, Dec 29, 2015 at 10:33 AM, DO YUNG YOON <
> > shom83@gmail.com>
> > > > >> wrote:
> > > > >> > >
> > > > >> > > > regarding to workflow, following was how I have worked with
> > > > S2Graph
> > > > >> > > before
> > > > >> > > > ASF incubation.
> > > > >> > > >
> > > > >> > > > 1. create Issue.
> > > > >> > > > 2. create branch with Issue number.
> > > > >> > > > 3. all works related to issue committed into Issue branch.
> > > > >> > > > 4. create PR.
> > > > >> > > > 5. review through github.
> > > > >> > > > 6. squash and merge them into develop.
> > > > >> > > > 7. run all test cases on develop branch.
> > > > >> > > > 8. merge develop into master.
> > > > >> > > >
> > > > >> > > > above has been works pretty well for me so I prefer CTR,
> but I
> > > am
> > > > >> > willing
> > > > >> > > > to learn if there is better way.
> > > > >> > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > >
> > > > >> > > > On Mon, Dec 28, 2015 at 2:11 PM Hyunsik Choi <
> > > hyunsik@apache.org>
> > > > >> > wrote:
> > > > >> > > >
> > > > >> > > > > Hi folks,
> > > > >> > > > >
> > > > >> > > > > We need to discuss the development workflow and review
> > policy.
> > > > Many
> > > > >> > of
> > > > >> > > > > committers may be new to ASF development process, and each
> > ASF
> > > > >> > project
> > > > >> > > > > has its own bylaws based on common process. Hence, we need
> > to
> > > > >> discuss
> > > > >> > > > > and decide them now.
> > > > >> > > > >
> > > > >> > > > > First of all, you guys need to read the following
> > > documentation:
> > > > >> > > > >
> > > > >> > > > >
> > > > >> > >
> > > > >>
> > >
> http://www.apache.org/foundation/voting.html#votes-on-code-modification
> > > > >> > > > >
> > > http://www.apache.org/foundation/glossary.html#CommitThenReview
> > > > >> > > > >
> > > http://www.apache.org/foundation/glossary.html#ReviewThenCommit
> > > > >> > > > >
> > > > >> > > > > Most of the code modifications should involve voting
> > process.
> > > > >> > > > > According to whether you guys follow lazy consensus or
> not,
> > > you
> > > > can
> > > > >> > > > > choose CTR (commit then review) and RTC (review then
> > commit).
> > > > >> > > > >
> > > > >> > > > > Simply, RTC requires +1 from at least one committer
> without
> > -1
> > > > >> before
> > > > >> > > > > the patch commit. CTS can get +1 even after the patch
> > commit,
> > > > but
> > > > >> the
> > > > >> > > > > patch can be reverted according to the result of reviews.
> > > > >> > > > >
> > > > >> > > > > Which policy do you guys prefer?
> > > > >> > > > >
> > > > >> > > > > Best regards,
> > > > >> > > > > Hyunsik
> > > > >> > > > >
> > > > >> > > >
> > > > >> > >
> > > > >> >
> > > > >>
> > > >
> > >
> >
>

Re: [DISCUSSION] workflow and review policy

[Jaesang Kim <ho...@gmail.com>]

I vote +1 to CTR.
I also like RTC, but currently our project is immature, we need many code
modifications.
So, I think that CTR is more suitable to us. After a few releases, it is
better to change to RTC.

Best regards,
Jaesang


2015년 12월 31일 (목) 오전 11:59, Hyunsung Jo <hy...@gmail.com>님이 작성:

> I think, in order for the previous workflow to truly fall into RTC
> category, the review process should be more thorough.
> By the looks, Apache Review Board (https://reviews.apache.org) seems like
> a
> nice tool to achieve this.
> I also support GitHub mirroring.
>
> Regards,
> Jo
>
> On Thu, Dec 31, 2015 at 1:24 AM DO YUNG YOON <sh...@gmail.com> wrote:
>
> > Had no idea it was RTC.
> > if workflow I wrote is RTC then I am +1 with RTC. thanks for correction.
> >
> > I prefer PR through Github over Jira path.
> > also like Luke suggested, +1 for applying Review Board and CI from INFRA.
> >
> >
> >
> > On Wed, Dec 30, 2015 at 3:56 PM, Hyunsik Choi <hy...@apache.org>
> wrote:
> >
> > > Thank you for comments. IMO, the workflow that Do Young mentioned is
> > > RTC. It may be caused by some ambiguous terms around traditional and
> > > modern SCM tools. CTR and RTC in the ASF documentation seem to be
> > > based on traditional SCM tools like SVN and CVS. So, each commit here
> > > may mean pushed commit logs in GIT.
> > >
> > > Anyway, the workflow looks great to me.
> > >
> > > If you want to use github, we need to ask INFRA team to make Github
> > > mirror and enable PR on the github repo. If you guys agree with that,
> > > I'll ask it.
> > >
> > > Best regards,
> > > Hyunsik
> > >
> > > On Mon, Dec 28, 2015 at 11:57 PM, blueiur <bl...@gmail.com> wrote:
> > > > CTR +1
> > > >
> > > >
> > > > On Tue, Dec 29, 2015 at 4:48 PM Hyunsung Jo <hy...@gmail.com>
> > > wrote:
> > > >
> > > >> I have no problem with the pre-apache workflow as long as it
> complies
> > > >> with ASF standards.
> > > >> So one up for CTR.
> > > >>
> > > >> On Tue, Dec 29, 2015 at 1:31 PM Luke Han <lu...@gmail.com> wrote:
> > > >>
> > > >> > CTR is more easy for new committer to join and practice in our
> > > community.
> > > >> >
> > > >> > We also could apply Review Board and CI from INFRA to leverage
> such
> > > >> tools.
> > > >> >
> > > >> > And, we also should discuss about to continue leverage github.com
> > PR
> > > or
> > > >> > JIRA patch.
> > > >> > Github.com code repo is just mirrored from Apache git repo which
> do
> > > not
> > > >> > support PR yet, so we need additional step to merge any PR from
> > > >> github.com
> > > >> > .
> > > >> >
> > > >> > Thanks.
> > > >> >
> > > >> >
> > > >> > Best Regards!
> > > >> > ---------------------
> > > >> >
> > > >> > Luke Han
> > > >> >
> > > >> > On Tue, Dec 29, 2015 at 10:10 AM, Kim, Min-Seok <
> > mskim.org@gmail.com>
> > > >> > wrote:
> > > >> >
> > > >> > > As Do Yung mentioned, I have worked as the process.
> > > >> > >
> > > >> > > So I prefer CTR, but I am also willing to learn if there is a
> > better
> > > >> way.
> > > >> > >
> > > >> > > Minseok
> > > >> > >
> > > >> > > On Tue, Dec 29, 2015 at 10:33 AM, DO YUNG YOON <
> shom83@gmail.com>
> > > >> wrote:
> > > >> > >
> > > >> > > > regarding to workflow, following was how I have worked with
> > > S2Graph
> > > >> > > before
> > > >> > > > ASF incubation.
> > > >> > > >
> > > >> > > > 1. create Issue.
> > > >> > > > 2. create branch with Issue number.
> > > >> > > > 3. all works related to issue committed into Issue branch.
> > > >> > > > 4. create PR.
> > > >> > > > 5. review through github.
> > > >> > > > 6. squash and merge them into develop.
> > > >> > > > 7. run all test cases on develop branch.
> > > >> > > > 8. merge develop into master.
> > > >> > > >
> > > >> > > > above has been works pretty well for me so I prefer CTR, but I
> > am
> > > >> > willing
> > > >> > > > to learn if there is better way.
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > >
> > > >> > > > On Mon, Dec 28, 2015 at 2:11 PM Hyunsik Choi <
> > hyunsik@apache.org>
> > > >> > wrote:
> > > >> > > >
> > > >> > > > > Hi folks,
> > > >> > > > >
> > > >> > > > > We need to discuss the development workflow and review
> policy.
> > > Many
> > > >> > of
> > > >> > > > > committers may be new to ASF development process, and each
> ASF
> > > >> > project
> > > >> > > > > has its own bylaws based on common process. Hence, we need
> to
> > > >> discuss
> > > >> > > > > and decide them now.
> > > >> > > > >
> > > >> > > > > First of all, you guys need to read the following
> > documentation:
> > > >> > > > >
> > > >> > > > >
> > > >> > >
> > > >>
> > http://www.apache.org/foundation/voting.html#votes-on-code-modification
> > > >> > > > >
> > http://www.apache.org/foundation/glossary.html#CommitThenReview
> > > >> > > > >
> > http://www.apache.org/foundation/glossary.html#ReviewThenCommit
> > > >> > > > >
> > > >> > > > > Most of the code modifications should involve voting
> process.
> > > >> > > > > According to whether you guys follow lazy consensus or not,
> > you
> > > can
> > > >> > > > > choose CTR (commit then review) and RTC (review then
> commit).
> > > >> > > > >
> > > >> > > > > Simply, RTC requires +1 from at least one committer without
> -1
> > > >> before
> > > >> > > > > the patch commit. CTS can get +1 even after the patch
> commit,
> > > but
> > > >> the
> > > >> > > > > patch can be reverted according to the result of reviews.
> > > >> > > > >
> > > >> > > > > Which policy do you guys prefer?
> > > >> > > > >
> > > >> > > > > Best regards,
> > > >> > > > > Hyunsik
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
>

Re: [DISCUSSION] workflow and review policy

[Hyunsung Jo <hy...@gmail.com>]

I think, in order for the previous workflow to truly fall into RTC
category, the review process should be more thorough.
By the looks, Apache Review Board (https://reviews.apache.org) seems like a
nice tool to achieve this.
I also support GitHub mirroring.

Regards,
Jo

On Thu, Dec 31, 2015 at 1:24 AM DO YUNG YOON <sh...@gmail.com> wrote:

> Had no idea it was RTC.
> if workflow I wrote is RTC then I am +1 with RTC. thanks for correction.
>
> I prefer PR through Github over Jira path.
> also like Luke suggested, +1 for applying Review Board and CI from INFRA.
>
>
>
> On Wed, Dec 30, 2015 at 3:56 PM, Hyunsik Choi <hy...@apache.org> wrote:
>
> > Thank you for comments. IMO, the workflow that Do Young mentioned is
> > RTC. It may be caused by some ambiguous terms around traditional and
> > modern SCM tools. CTR and RTC in the ASF documentation seem to be
> > based on traditional SCM tools like SVN and CVS. So, each commit here
> > may mean pushed commit logs in GIT.
> >
> > Anyway, the workflow looks great to me.
> >
> > If you want to use github, we need to ask INFRA team to make Github
> > mirror and enable PR on the github repo. If you guys agree with that,
> > I'll ask it.
> >
> > Best regards,
> > Hyunsik
> >
> > On Mon, Dec 28, 2015 at 11:57 PM, blueiur <bl...@gmail.com> wrote:
> > > CTR +1
> > >
> > >
> > > On Tue, Dec 29, 2015 at 4:48 PM Hyunsung Jo <hy...@gmail.com>
> > wrote:
> > >
> > >> I have no problem with the pre-apache workflow as long as it complies
> > >> with ASF standards.
> > >> So one up for CTR.
> > >>
> > >> On Tue, Dec 29, 2015 at 1:31 PM Luke Han <lu...@gmail.com> wrote:
> > >>
> > >> > CTR is more easy for new committer to join and practice in our
> > community.
> > >> >
> > >> > We also could apply Review Board and CI from INFRA to leverage such
> > >> tools.
> > >> >
> > >> > And, we also should discuss about to continue leverage github.com
> PR
> > or
> > >> > JIRA patch.
> > >> > Github.com code repo is just mirrored from Apache git repo which do
> > not
> > >> > support PR yet, so we need additional step to merge any PR from
> > >> github.com
> > >> > .
> > >> >
> > >> > Thanks.
> > >> >
> > >> >
> > >> > Best Regards!
> > >> > ---------------------
> > >> >
> > >> > Luke Han
> > >> >
> > >> > On Tue, Dec 29, 2015 at 10:10 AM, Kim, Min-Seok <
> mskim.org@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > As Do Yung mentioned, I have worked as the process.
> > >> > >
> > >> > > So I prefer CTR, but I am also willing to learn if there is a
> better
> > >> way.
> > >> > >
> > >> > > Minseok
> > >> > >
> > >> > > On Tue, Dec 29, 2015 at 10:33 AM, DO YUNG YOON <sh...@gmail.com>
> > >> wrote:
> > >> > >
> > >> > > > regarding to workflow, following was how I have worked with
> > S2Graph
> > >> > > before
> > >> > > > ASF incubation.
> > >> > > >
> > >> > > > 1. create Issue.
> > >> > > > 2. create branch with Issue number.
> > >> > > > 3. all works related to issue committed into Issue branch.
> > >> > > > 4. create PR.
> > >> > > > 5. review through github.
> > >> > > > 6. squash and merge them into develop.
> > >> > > > 7. run all test cases on develop branch.
> > >> > > > 8. merge develop into master.
> > >> > > >
> > >> > > > above has been works pretty well for me so I prefer CTR, but I
> am
> > >> > willing
> > >> > > > to learn if there is better way.
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > On Mon, Dec 28, 2015 at 2:11 PM Hyunsik Choi <
> hyunsik@apache.org>
> > >> > wrote:
> > >> > > >
> > >> > > > > Hi folks,
> > >> > > > >
> > >> > > > > We need to discuss the development workflow and review policy.
> > Many
> > >> > of
> > >> > > > > committers may be new to ASF development process, and each ASF
> > >> > project
> > >> > > > > has its own bylaws based on common process. Hence, we need to
> > >> discuss
> > >> > > > > and decide them now.
> > >> > > > >
> > >> > > > > First of all, you guys need to read the following
> documentation:
> > >> > > > >
> > >> > > > >
> > >> > >
> > >>
> http://www.apache.org/foundation/voting.html#votes-on-code-modification
> > >> > > > >
> http://www.apache.org/foundation/glossary.html#CommitThenReview
> > >> > > > >
> http://www.apache.org/foundation/glossary.html#ReviewThenCommit
> > >> > > > >
> > >> > > > > Most of the code modifications should involve voting process.
> > >> > > > > According to whether you guys follow lazy consensus or not,
> you
> > can
> > >> > > > > choose CTR (commit then review) and RTC (review then commit).
> > >> > > > >
> > >> > > > > Simply, RTC requires +1 from at least one committer without -1
> > >> before
> > >> > > > > the patch commit. CTS can get +1 even after the patch commit,
> > but
> > >> the
> > >> > > > > patch can be reverted according to the result of reviews.
> > >> > > > >
> > >> > > > > Which policy do you guys prefer?
> > >> > > > >
> > >> > > > > Best regards,
> > >> > > > > Hyunsik
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
>

Re: [DISCUSSION] workflow and review policy

["Kim, Min-Seok" <ms...@gmail.com>]

It was RTC, thanks.

RTC +1

If we use github, is Review Board required?
AFAIK, we can review using github features such as commenting to PRs or
Issues.

Minseok

On Thu, Dec 31, 2015 at 1:24 AM, DO YUNG YOON <sh...@gmail.com> wrote:

> Had no idea it was RTC.
> if workflow I wrote is RTC then I am +1 with RTC. thanks for correction.
>
> I prefer PR through Github over Jira path.
> also like Luke suggested, +1 for applying Review Board and CI from INFRA.
>
>
>
> On Wed, Dec 30, 2015 at 3:56 PM, Hyunsik Choi <hy...@apache.org> wrote:
>
> > Thank you for comments. IMO, the workflow that Do Young mentioned is
> > RTC. It may be caused by some ambiguous terms around traditional and
> > modern SCM tools. CTR and RTC in the ASF documentation seem to be
> > based on traditional SCM tools like SVN and CVS. So, each commit here
> > may mean pushed commit logs in GIT.
> >
> > Anyway, the workflow looks great to me.
> >
> > If you want to use github, we need to ask INFRA team to make Github
> > mirror and enable PR on the github repo. If you guys agree with that,
> > I'll ask it.
> >
> > Best regards,
> > Hyunsik
> >
> > On Mon, Dec 28, 2015 at 11:57 PM, blueiur <bl...@gmail.com> wrote:
> > > CTR +1
> > >
> > >
> > > On Tue, Dec 29, 2015 at 4:48 PM Hyunsung Jo <hy...@gmail.com>
> > wrote:
> > >
> > >> I have no problem with the pre-apache workflow as long as it complies
> > >> with ASF standards.
> > >> So one up for CTR.
> > >>
> > >> On Tue, Dec 29, 2015 at 1:31 PM Luke Han <lu...@gmail.com> wrote:
> > >>
> > >> > CTR is more easy for new committer to join and practice in our
> > community.
> > >> >
> > >> > We also could apply Review Board and CI from INFRA to leverage such
> > >> tools.
> > >> >
> > >> > And, we also should discuss about to continue leverage github.com
> PR
> > or
> > >> > JIRA patch.
> > >> > Github.com code repo is just mirrored from Apache git repo which do
> > not
> > >> > support PR yet, so we need additional step to merge any PR from
> > >> github.com
> > >> > .
> > >> >
> > >> > Thanks.
> > >> >
> > >> >
> > >> > Best Regards!
> > >> > ---------------------
> > >> >
> > >> > Luke Han
> > >> >
> > >> > On Tue, Dec 29, 2015 at 10:10 AM, Kim, Min-Seok <
> mskim.org@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > As Do Yung mentioned, I have worked as the process.
> > >> > >
> > >> > > So I prefer CTR, but I am also willing to learn if there is a
> better
> > >> way.
> > >> > >
> > >> > > Minseok
> > >> > >
> > >> > > On Tue, Dec 29, 2015 at 10:33 AM, DO YUNG YOON <sh...@gmail.com>
> > >> wrote:
> > >> > >
> > >> > > > regarding to workflow, following was how I have worked with
> > S2Graph
> > >> > > before
> > >> > > > ASF incubation.
> > >> > > >
> > >> > > > 1. create Issue.
> > >> > > > 2. create branch with Issue number.
> > >> > > > 3. all works related to issue committed into Issue branch.
> > >> > > > 4. create PR.
> > >> > > > 5. review through github.
> > >> > > > 6. squash and merge them into develop.
> > >> > > > 7. run all test cases on develop branch.
> > >> > > > 8. merge develop into master.
> > >> > > >
> > >> > > > above has been works pretty well for me so I prefer CTR, but I
> am
> > >> > willing
> > >> > > > to learn if there is better way.
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > On Mon, Dec 28, 2015 at 2:11 PM Hyunsik Choi <
> hyunsik@apache.org>
> > >> > wrote:
> > >> > > >
> > >> > > > > Hi folks,
> > >> > > > >
> > >> > > > > We need to discuss the development workflow and review policy.
> > Many
> > >> > of
> > >> > > > > committers may be new to ASF development process, and each ASF
> > >> > project
> > >> > > > > has its own bylaws based on common process. Hence, we need to
> > >> discuss
> > >> > > > > and decide them now.
> > >> > > > >
> > >> > > > > First of all, you guys need to read the following
> documentation:
> > >> > > > >
> > >> > > > >
> > >> > >
> > >>
> http://www.apache.org/foundation/voting.html#votes-on-code-modification
> > >> > > > >
> http://www.apache.org/foundation/glossary.html#CommitThenReview
> > >> > > > >
> http://www.apache.org/foundation/glossary.html#ReviewThenCommit
> > >> > > > >
> > >> > > > > Most of the code modifications should involve voting process.
> > >> > > > > According to whether you guys follow lazy consensus or not,
> you
> > can
> > >> > > > > choose CTR (commit then review) and RTC (review then commit).
> > >> > > > >
> > >> > > > > Simply, RTC requires +1 from at least one committer without -1
> > >> before
> > >> > > > > the patch commit. CTS can get +1 even after the patch commit,
> > but
> > >> the
> > >> > > > > patch can be reverted according to the result of reviews.
> > >> > > > >
> > >> > > > > Which policy do you guys prefer?
> > >> > > > >
> > >> > > > > Best regards,
> > >> > > > > Hyunsik
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
>

Re: [DISCUSSION] workflow and review policy

[Hwansung Yu <de...@gmail.com>]

RTC was the way we worked so far.

I agree to RTC.


Best regards.

On Thu, Dec 31, 2015 at 1:24 AM, DO YUNG YOON <sh...@gmail.com> wrote:

> Had no idea it was RTC.
> if workflow I wrote is RTC then I am +1 with RTC. thanks for correction.
>
> I prefer PR through Github over Jira path.
> also like Luke suggested, +1 for applying Review Board and CI from INFRA.
>
>
>
> On Wed, Dec 30, 2015 at 3:56 PM, Hyunsik Choi <hy...@apache.org> wrote:
>
> > Thank you for comments. IMO, the workflow that Do Young mentioned is
> > RTC. It may be caused by some ambiguous terms around traditional and
> > modern SCM tools. CTR and RTC in the ASF documentation seem to be
> > based on traditional SCM tools like SVN and CVS. So, each commit here
> > may mean pushed commit logs in GIT.
> >
> > Anyway, the workflow looks great to me.
> >
> > If you want to use github, we need to ask INFRA team to make Github
> > mirror and enable PR on the github repo. If you guys agree with that,
> > I'll ask it.
> >
> > Best regards,
> > Hyunsik
> >
> > On Mon, Dec 28, 2015 at 11:57 PM, blueiur <bl...@gmail.com> wrote:
> > > CTR +1
> > >
> > >
> > > On Tue, Dec 29, 2015 at 4:48 PM Hyunsung Jo <hy...@gmail.com>
> > wrote:
> > >
> > >> I have no problem with the pre-apache workflow as long as it complies
> > >> with ASF standards.
> > >> So one up for CTR.
> > >>
> > >> On Tue, Dec 29, 2015 at 1:31 PM Luke Han <lu...@gmail.com> wrote:
> > >>
> > >> > CTR is more easy for new committer to join and practice in our
> > community.
> > >> >
> > >> > We also could apply Review Board and CI from INFRA to leverage such
> > >> tools.
> > >> >
> > >> > And, we also should discuss about to continue leverage github.com
> PR
> > or
> > >> > JIRA patch.
> > >> > Github.com code repo is just mirrored from Apache git repo which do
> > not
> > >> > support PR yet, so we need additional step to merge any PR from
> > >> github.com
> > >> > .
> > >> >
> > >> > Thanks.
> > >> >
> > >> >
> > >> > Best Regards!
> > >> > ---------------------
> > >> >
> > >> > Luke Han
> > >> >
> > >> > On Tue, Dec 29, 2015 at 10:10 AM, Kim, Min-Seok <
> mskim.org@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > As Do Yung mentioned, I have worked as the process.
> > >> > >
> > >> > > So I prefer CTR, but I am also willing to learn if there is a
> better
> > >> way.
> > >> > >
> > >> > > Minseok
> > >> > >
> > >> > > On Tue, Dec 29, 2015 at 10:33 AM, DO YUNG YOON <sh...@gmail.com>
> > >> wrote:
> > >> > >
> > >> > > > regarding to workflow, following was how I have worked with
> > S2Graph
> > >> > > before
> > >> > > > ASF incubation.
> > >> > > >
> > >> > > > 1. create Issue.
> > >> > > > 2. create branch with Issue number.
> > >> > > > 3. all works related to issue committed into Issue branch.
> > >> > > > 4. create PR.
> > >> > > > 5. review through github.
> > >> > > > 6. squash and merge them into develop.
> > >> > > > 7. run all test cases on develop branch.
> > >> > > > 8. merge develop into master.
> > >> > > >
> > >> > > > above has been works pretty well for me so I prefer CTR, but I
> am
> > >> > willing
> > >> > > > to learn if there is better way.
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > On Mon, Dec 28, 2015 at 2:11 PM Hyunsik Choi <
> hyunsik@apache.org>
> > >> > wrote:
> > >> > > >
> > >> > > > > Hi folks,
> > >> > > > >
> > >> > > > > We need to discuss the development workflow and review policy.
> > Many
> > >> > of
> > >> > > > > committers may be new to ASF development process, and each ASF
> > >> > project
> > >> > > > > has its own bylaws based on common process. Hence, we need to
> > >> discuss
> > >> > > > > and decide them now.
> > >> > > > >
> > >> > > > > First of all, you guys need to read the following
> documentation:
> > >> > > > >
> > >> > > > >
> > >> > >
> > >>
> http://www.apache.org/foundation/voting.html#votes-on-code-modification
> > >> > > > >
> http://www.apache.org/foundation/glossary.html#CommitThenReview
> > >> > > > >
> http://www.apache.org/foundation/glossary.html#ReviewThenCommit
> > >> > > > >
> > >> > > > > Most of the code modifications should involve voting process.
> > >> > > > > According to whether you guys follow lazy consensus or not,
> you
> > can
> > >> > > > > choose CTR (commit then review) and RTC (review then commit).
> > >> > > > >
> > >> > > > > Simply, RTC requires +1 from at least one committer without -1
> > >> before
> > >> > > > > the patch commit. CTS can get +1 even after the patch commit,
> > but
> > >> the
> > >> > > > > patch can be reverted according to the result of reviews.
> > >> > > > >
> > >> > > > > Which policy do you guys prefer?
> > >> > > > >
> > >> > > > > Best regards,
> > >> > > > > Hyunsik
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
>

Re: [DISCUSSION] workflow and review policy

[Jun Ki Kim <wi...@gmail.com>]

Hi folks,
I vote +1 to RTC as above mentioned way( like github PR and merge to target
branch, e.g. trunk branch).
I'm not a committer, but I just want to give my opinion. :)

Best regards.


2015년 12월 31일 (목) 오전 1:24, DO YUNG YOON <sh...@gmail.com>님이 작성:

> Had no idea it was RTC.
> if workflow I wrote is RTC then I am +1 with RTC. thanks for correction.
>
> I prefer PR through Github over Jira path.
> also like Luke suggested, +1 for applying Review Board and CI from INFRA.
>
>
>
> On Wed, Dec 30, 2015 at 3:56 PM, Hyunsik Choi <hy...@apache.org> wrote:
>
> > Thank you for comments. IMO, the workflow that Do Young mentioned is
> > RTC. It may be caused by some ambiguous terms around traditional and
> > modern SCM tools. CTR and RTC in the ASF documentation seem to be
> > based on traditional SCM tools like SVN and CVS. So, each commit here
> > may mean pushed commit logs in GIT.
> >
> > Anyway, the workflow looks great to me.
> >
> > If you want to use github, we need to ask INFRA team to make Github
> > mirror and enable PR on the github repo. If you guys agree with that,
> > I'll ask it.
> >
> > Best regards,
> > Hyunsik
> >
> > On Mon, Dec 28, 2015 at 11:57 PM, blueiur <bl...@gmail.com> wrote:
> > > CTR +1
> > >
> > >
> > > On Tue, Dec 29, 2015 at 4:48 PM Hyunsung Jo <hy...@gmail.com>
> > wrote:
> > >
> > >> I have no problem with the pre-apache workflow as long as it complies
> > >> with ASF standards.
> > >> So one up for CTR.
> > >>
> > >> On Tue, Dec 29, 2015 at 1:31 PM Luke Han <lu...@gmail.com> wrote:
> > >>
> > >> > CTR is more easy for new committer to join and practice in our
> > community.
> > >> >
> > >> > We also could apply Review Board and CI from INFRA to leverage such
> > >> tools.
> > >> >
> > >> > And, we also should discuss about to continue leverage github.com
> PR
> > or
> > >> > JIRA patch.
> > >> > Github.com code repo is just mirrored from Apache git repo which do
> > not
> > >> > support PR yet, so we need additional step to merge any PR from
> > >> github.com
> > >> > .
> > >> >
> > >> > Thanks.
> > >> >
> > >> >
> > >> > Best Regards!
> > >> > ---------------------
> > >> >
> > >> > Luke Han
> > >> >
> > >> > On Tue, Dec 29, 2015 at 10:10 AM, Kim, Min-Seok <
> mskim.org@gmail.com>
> > >> > wrote:
> > >> >
> > >> > > As Do Yung mentioned, I have worked as the process.
> > >> > >
> > >> > > So I prefer CTR, but I am also willing to learn if there is a
> better
> > >> way.
> > >> > >
> > >> > > Minseok
> > >> > >
> > >> > > On Tue, Dec 29, 2015 at 10:33 AM, DO YUNG YOON <sh...@gmail.com>
> > >> wrote:
> > >> > >
> > >> > > > regarding to workflow, following was how I have worked with
> > S2Graph
> > >> > > before
> > >> > > > ASF incubation.
> > >> > > >
> > >> > > > 1. create Issue.
> > >> > > > 2. create branch with Issue number.
> > >> > > > 3. all works related to issue committed into Issue branch.
> > >> > > > 4. create PR.
> > >> > > > 5. review through github.
> > >> > > > 6. squash and merge them into develop.
> > >> > > > 7. run all test cases on develop branch.
> > >> > > > 8. merge develop into master.
> > >> > > >
> > >> > > > above has been works pretty well for me so I prefer CTR, but I
> am
> > >> > willing
> > >> > > > to learn if there is better way.
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > >
> > >> > > > On Mon, Dec 28, 2015 at 2:11 PM Hyunsik Choi <
> hyunsik@apache.org>
> > >> > wrote:
> > >> > > >
> > >> > > > > Hi folks,
> > >> > > > >
> > >> > > > > We need to discuss the development workflow and review policy.
> > Many
> > >> > of
> > >> > > > > committers may be new to ASF development process, and each ASF
> > >> > project
> > >> > > > > has its own bylaws based on common process. Hence, we need to
> > >> discuss
> > >> > > > > and decide them now.
> > >> > > > >
> > >> > > > > First of all, you guys need to read the following
> documentation:
> > >> > > > >
> > >> > > > >
> > >> > >
> > >>
> http://www.apache.org/foundation/voting.html#votes-on-code-modification
> > >> > > > >
> http://www.apache.org/foundation/glossary.html#CommitThenReview
> > >> > > > >
> http://www.apache.org/foundation/glossary.html#ReviewThenCommit
> > >> > > > >
> > >> > > > > Most of the code modifications should involve voting process.
> > >> > > > > According to whether you guys follow lazy consensus or not,
> you
> > can
> > >> > > > > choose CTR (commit then review) and RTC (review then commit).
> > >> > > > >
> > >> > > > > Simply, RTC requires +1 from at least one committer without -1
> > >> before
> > >> > > > > the patch commit. CTS can get +1 even after the patch commit,
> > but
> > >> the
> > >> > > > > patch can be reverted according to the result of reviews.
> > >> > > > >
> > >> > > > > Which policy do you guys prefer?
> > >> > > > >
> > >> > > > > Best regards,
> > >> > > > > Hyunsik
> > >> > > > >
> > >> > > >
> > >> > >
> > >> >
> > >>
> >
>

Re: [DISCUSSION] workflow and review policy

[DO YUNG YOON <sh...@gmail.com>]

Had no idea it was RTC.
if workflow I wrote is RTC then I am +1 with RTC. thanks for correction.

I prefer PR through Github over Jira path.
also like Luke suggested, +1 for applying Review Board and CI from INFRA.



On Wed, Dec 30, 2015 at 3:56 PM, Hyunsik Choi <hy...@apache.org> wrote:

> Thank you for comments. IMO, the workflow that Do Young mentioned is
> RTC. It may be caused by some ambiguous terms around traditional and
> modern SCM tools. CTR and RTC in the ASF documentation seem to be
> based on traditional SCM tools like SVN and CVS. So, each commit here
> may mean pushed commit logs in GIT.
>
> Anyway, the workflow looks great to me.
>
> If you want to use github, we need to ask INFRA team to make Github
> mirror and enable PR on the github repo. If you guys agree with that,
> I'll ask it.
>
> Best regards,
> Hyunsik
>
> On Mon, Dec 28, 2015 at 11:57 PM, blueiur <bl...@gmail.com> wrote:
> > CTR +1
> >
> >
> > On Tue, Dec 29, 2015 at 4:48 PM Hyunsung Jo <hy...@gmail.com>
> wrote:
> >
> >> I have no problem with the pre-apache workflow as long as it complies
> >> with ASF standards.
> >> So one up for CTR.
> >>
> >> On Tue, Dec 29, 2015 at 1:31 PM Luke Han <lu...@gmail.com> wrote:
> >>
> >> > CTR is more easy for new committer to join and practice in our
> community.
> >> >
> >> > We also could apply Review Board and CI from INFRA to leverage such
> >> tools.
> >> >
> >> > And, we also should discuss about to continue leverage github.com PR
> or
> >> > JIRA patch.
> >> > Github.com code repo is just mirrored from Apache git repo which do
> not
> >> > support PR yet, so we need additional step to merge any PR from
> >> github.com
> >> > .
> >> >
> >> > Thanks.
> >> >
> >> >
> >> > Best Regards!
> >> > ---------------------
> >> >
> >> > Luke Han
> >> >
> >> > On Tue, Dec 29, 2015 at 10:10 AM, Kim, Min-Seok <ms...@gmail.com>
> >> > wrote:
> >> >
> >> > > As Do Yung mentioned, I have worked as the process.
> >> > >
> >> > > So I prefer CTR, but I am also willing to learn if there is a better
> >> way.
> >> > >
> >> > > Minseok
> >> > >
> >> > > On Tue, Dec 29, 2015 at 10:33 AM, DO YUNG YOON <sh...@gmail.com>
> >> wrote:
> >> > >
> >> > > > regarding to workflow, following was how I have worked with
> S2Graph
> >> > > before
> >> > > > ASF incubation.
> >> > > >
> >> > > > 1. create Issue.
> >> > > > 2. create branch with Issue number.
> >> > > > 3. all works related to issue committed into Issue branch.
> >> > > > 4. create PR.
> >> > > > 5. review through github.
> >> > > > 6. squash and merge them into develop.
> >> > > > 7. run all test cases on develop branch.
> >> > > > 8. merge develop into master.
> >> > > >
> >> > > > above has been works pretty well for me so I prefer CTR, but I am
> >> > willing
> >> > > > to learn if there is better way.
> >> > > >
> >> > > >
> >> > > >
> >> > > >
> >> > > > On Mon, Dec 28, 2015 at 2:11 PM Hyunsik Choi <hy...@apache.org>
> >> > wrote:
> >> > > >
> >> > > > > Hi folks,
> >> > > > >
> >> > > > > We need to discuss the development workflow and review policy.
> Many
> >> > of
> >> > > > > committers may be new to ASF development process, and each ASF
> >> > project
> >> > > > > has its own bylaws based on common process. Hence, we need to
> >> discuss
> >> > > > > and decide them now.
> >> > > > >
> >> > > > > First of all, you guys need to read the following documentation:
> >> > > > >
> >> > > > >
> >> > >
> >> http://www.apache.org/foundation/voting.html#votes-on-code-modification
> >> > > > > http://www.apache.org/foundation/glossary.html#CommitThenReview
> >> > > > > http://www.apache.org/foundation/glossary.html#ReviewThenCommit
> >> > > > >
> >> > > > > Most of the code modifications should involve voting process.
> >> > > > > According to whether you guys follow lazy consensus or not, you
> can
> >> > > > > choose CTR (commit then review) and RTC (review then commit).
> >> > > > >
> >> > > > > Simply, RTC requires +1 from at least one committer without -1
> >> before
> >> > > > > the patch commit. CTS can get +1 even after the patch commit,
> but
> >> the
> >> > > > > patch can be reverted according to the result of reviews.
> >> > > > >
> >> > > > > Which policy do you guys prefer?
> >> > > > >
> >> > > > > Best regards,
> >> > > > > Hyunsik
> >> > > > >
> >> > > >
> >> > >
> >> >
> >>
>

Re: [DISCUSSION] workflow and review policy

[Hyunsik Choi <hy...@apache.org>]

Thank you for comments. IMO, the workflow that Do Young mentioned is
RTC. It may be caused by some ambiguous terms around traditional and
modern SCM tools. CTR and RTC in the ASF documentation seem to be
based on traditional SCM tools like SVN and CVS. So, each commit here
may mean pushed commit logs in GIT.

Anyway, the workflow looks great to me.

If you want to use github, we need to ask INFRA team to make Github
mirror and enable PR on the github repo. If you guys agree with that,
I'll ask it.

Best regards,
Hyunsik

On Mon, Dec 28, 2015 at 11:57 PM, blueiur <bl...@gmail.com> wrote:
> CTR +1
>
>
> On Tue, Dec 29, 2015 at 4:48 PM Hyunsung Jo <hy...@gmail.com> wrote:
>
>> I have no problem with the pre-apache workflow as long as it complies
>> with ASF standards.
>> So one up for CTR.
>>
>> On Tue, Dec 29, 2015 at 1:31 PM Luke Han <lu...@gmail.com> wrote:
>>
>> > CTR is more easy for new committer to join and practice in our community.
>> >
>> > We also could apply Review Board and CI from INFRA to leverage such
>> tools.
>> >
>> > And, we also should discuss about to continue leverage github.com PR or
>> > JIRA patch.
>> > Github.com code repo is just mirrored from Apache git repo which do not
>> > support PR yet, so we need additional step to merge any PR from
>> github.com
>> > .
>> >
>> > Thanks.
>> >
>> >
>> > Best Regards!
>> > ---------------------
>> >
>> > Luke Han
>> >
>> > On Tue, Dec 29, 2015 at 10:10 AM, Kim, Min-Seok <ms...@gmail.com>
>> > wrote:
>> >
>> > > As Do Yung mentioned, I have worked as the process.
>> > >
>> > > So I prefer CTR, but I am also willing to learn if there is a better
>> way.
>> > >
>> > > Minseok
>> > >
>> > > On Tue, Dec 29, 2015 at 10:33 AM, DO YUNG YOON <sh...@gmail.com>
>> wrote:
>> > >
>> > > > regarding to workflow, following was how I have worked with S2Graph
>> > > before
>> > > > ASF incubation.
>> > > >
>> > > > 1. create Issue.
>> > > > 2. create branch with Issue number.
>> > > > 3. all works related to issue committed into Issue branch.
>> > > > 4. create PR.
>> > > > 5. review through github.
>> > > > 6. squash and merge them into develop.
>> > > > 7. run all test cases on develop branch.
>> > > > 8. merge develop into master.
>> > > >
>> > > > above has been works pretty well for me so I prefer CTR, but I am
>> > willing
>> > > > to learn if there is better way.
>> > > >
>> > > >
>> > > >
>> > > >
>> > > > On Mon, Dec 28, 2015 at 2:11 PM Hyunsik Choi <hy...@apache.org>
>> > wrote:
>> > > >
>> > > > > Hi folks,
>> > > > >
>> > > > > We need to discuss the development workflow and review policy. Many
>> > of
>> > > > > committers may be new to ASF development process, and each ASF
>> > project
>> > > > > has its own bylaws based on common process. Hence, we need to
>> discuss
>> > > > > and decide them now.
>> > > > >
>> > > > > First of all, you guys need to read the following documentation:
>> > > > >
>> > > > >
>> > >
>> http://www.apache.org/foundation/voting.html#votes-on-code-modification
>> > > > > http://www.apache.org/foundation/glossary.html#CommitThenReview
>> > > > > http://www.apache.org/foundation/glossary.html#ReviewThenCommit
>> > > > >
>> > > > > Most of the code modifications should involve voting process.
>> > > > > According to whether you guys follow lazy consensus or not, you can
>> > > > > choose CTR (commit then review) and RTC (review then commit).
>> > > > >
>> > > > > Simply, RTC requires +1 from at least one committer without -1
>> before
>> > > > > the patch commit. CTS can get +1 even after the patch commit, but
>> the
>> > > > > patch can be reverted according to the result of reviews.
>> > > > >
>> > > > > Which policy do you guys prefer?
>> > > > >
>> > > > > Best regards,
>> > > > > Hyunsik
>> > > > >
>> > > >
>> > >
>> >
>>

Re: [DISCUSSION] workflow and review policy

[blueiur <bl...@gmail.com>]

CTR +1


On Tue, Dec 29, 2015 at 4:48 PM Hyunsung Jo <hy...@gmail.com> wrote:

> I have no problem with the pre-apache workflow as long as it complies
> with ASF standards.
> So one up for CTR.
>
> On Tue, Dec 29, 2015 at 1:31 PM Luke Han <lu...@gmail.com> wrote:
>
> > CTR is more easy for new committer to join and practice in our community.
> >
> > We also could apply Review Board and CI from INFRA to leverage such
> tools.
> >
> > And, we also should discuss about to continue leverage github.com PR or
> > JIRA patch.
> > Github.com code repo is just mirrored from Apache git repo which do not
> > support PR yet, so we need additional step to merge any PR from
> github.com
> > .
> >
> > Thanks.
> >
> >
> > Best Regards!
> > ---------------------
> >
> > Luke Han
> >
> > On Tue, Dec 29, 2015 at 10:10 AM, Kim, Min-Seok <ms...@gmail.com>
> > wrote:
> >
> > > As Do Yung mentioned, I have worked as the process.
> > >
> > > So I prefer CTR, but I am also willing to learn if there is a better
> way.
> > >
> > > Minseok
> > >
> > > On Tue, Dec 29, 2015 at 10:33 AM, DO YUNG YOON <sh...@gmail.com>
> wrote:
> > >
> > > > regarding to workflow, following was how I have worked with S2Graph
> > > before
> > > > ASF incubation.
> > > >
> > > > 1. create Issue.
> > > > 2. create branch with Issue number.
> > > > 3. all works related to issue committed into Issue branch.
> > > > 4. create PR.
> > > > 5. review through github.
> > > > 6. squash and merge them into develop.
> > > > 7. run all test cases on develop branch.
> > > > 8. merge develop into master.
> > > >
> > > > above has been works pretty well for me so I prefer CTR, but I am
> > willing
> > > > to learn if there is better way.
> > > >
> > > >
> > > >
> > > >
> > > > On Mon, Dec 28, 2015 at 2:11 PM Hyunsik Choi <hy...@apache.org>
> > wrote:
> > > >
> > > > > Hi folks,
> > > > >
> > > > > We need to discuss the development workflow and review policy. Many
> > of
> > > > > committers may be new to ASF development process, and each ASF
> > project
> > > > > has its own bylaws based on common process. Hence, we need to
> discuss
> > > > > and decide them now.
> > > > >
> > > > > First of all, you guys need to read the following documentation:
> > > > >
> > > > >
> > >
> http://www.apache.org/foundation/voting.html#votes-on-code-modification
> > > > > http://www.apache.org/foundation/glossary.html#CommitThenReview
> > > > > http://www.apache.org/foundation/glossary.html#ReviewThenCommit
> > > > >
> > > > > Most of the code modifications should involve voting process.
> > > > > According to whether you guys follow lazy consensus or not, you can
> > > > > choose CTR (commit then review) and RTC (review then commit).
> > > > >
> > > > > Simply, RTC requires +1 from at least one committer without -1
> before
> > > > > the patch commit. CTS can get +1 even after the patch commit, but
> the
> > > > > patch can be reverted according to the result of reviews.
> > > > >
> > > > > Which policy do you guys prefer?
> > > > >
> > > > > Best regards,
> > > > > Hyunsik
> > > > >
> > > >
> > >
> >
>

Re: [DISCUSSION] workflow and review policy

[Hyunsung Jo <hy...@gmail.com>]

I have no problem with the pre-apache workflow as long as it complies
with ASF standards.
So one up for CTR.

On Tue, Dec 29, 2015 at 1:31 PM Luke Han <lu...@gmail.com> wrote:

> CTR is more easy for new committer to join and practice in our community.
>
> We also could apply Review Board and CI from INFRA to leverage such tools.
>
> And, we also should discuss about to continue leverage github.com PR or
> JIRA patch.
> Github.com code repo is just mirrored from Apache git repo which do not
> support PR yet, so we need additional step to merge any PR from github.com
> .
>
> Thanks.
>
>
> Best Regards!
> ---------------------
>
> Luke Han
>
> On Tue, Dec 29, 2015 at 10:10 AM, Kim, Min-Seok <ms...@gmail.com>
> wrote:
>
> > As Do Yung mentioned, I have worked as the process.
> >
> > So I prefer CTR, but I am also willing to learn if there is a better way.
> >
> > Minseok
> >
> > On Tue, Dec 29, 2015 at 10:33 AM, DO YUNG YOON <sh...@gmail.com> wrote:
> >
> > > regarding to workflow, following was how I have worked with S2Graph
> > before
> > > ASF incubation.
> > >
> > > 1. create Issue.
> > > 2. create branch with Issue number.
> > > 3. all works related to issue committed into Issue branch.
> > > 4. create PR.
> > > 5. review through github.
> > > 6. squash and merge them into develop.
> > > 7. run all test cases on develop branch.
> > > 8. merge develop into master.
> > >
> > > above has been works pretty well for me so I prefer CTR, but I am
> willing
> > > to learn if there is better way.
> > >
> > >
> > >
> > >
> > > On Mon, Dec 28, 2015 at 2:11 PM Hyunsik Choi <hy...@apache.org>
> wrote:
> > >
> > > > Hi folks,
> > > >
> > > > We need to discuss the development workflow and review policy. Many
> of
> > > > committers may be new to ASF development process, and each ASF
> project
> > > > has its own bylaws based on common process. Hence, we need to discuss
> > > > and decide them now.
> > > >
> > > > First of all, you guys need to read the following documentation:
> > > >
> > > >
> > http://www.apache.org/foundation/voting.html#votes-on-code-modification
> > > > http://www.apache.org/foundation/glossary.html#CommitThenReview
> > > > http://www.apache.org/foundation/glossary.html#ReviewThenCommit
> > > >
> > > > Most of the code modifications should involve voting process.
> > > > According to whether you guys follow lazy consensus or not, you can
> > > > choose CTR (commit then review) and RTC (review then commit).
> > > >
> > > > Simply, RTC requires +1 from at least one committer without -1 before
> > > > the patch commit. CTS can get +1 even after the patch commit, but the
> > > > patch can be reverted according to the result of reviews.
> > > >
> > > > Which policy do you guys prefer?
> > > >
> > > > Best regards,
> > > > Hyunsik
> > > >
> > >
> >
>

Re: [DISCUSSION] workflow and review policy

[Luke Han <lu...@gmail.com>]

CTR is more easy for new committer to join and practice in our community.

We also could apply Review Board and CI from INFRA to leverage such tools.

And, we also should discuss about to continue leverage github.com PR or
JIRA patch.
Github.com code repo is just mirrored from Apache git repo which do not
support PR yet, so we need additional step to merge any PR from github.com.

Thanks.


Best Regards!
---------------------

Luke Han

On Tue, Dec 29, 2015 at 10:10 AM, Kim, Min-Seok <ms...@gmail.com> wrote:

> As Do Yung mentioned, I have worked as the process.
>
> So I prefer CTR, but I am also willing to learn if there is a better way.
>
> Minseok
>
> On Tue, Dec 29, 2015 at 10:33 AM, DO YUNG YOON <sh...@gmail.com> wrote:
>
> > regarding to workflow, following was how I have worked with S2Graph
> before
> > ASF incubation.
> >
> > 1. create Issue.
> > 2. create branch with Issue number.
> > 3. all works related to issue committed into Issue branch.
> > 4. create PR.
> > 5. review through github.
> > 6. squash and merge them into develop.
> > 7. run all test cases on develop branch.
> > 8. merge develop into master.
> >
> > above has been works pretty well for me so I prefer CTR, but I am willing
> > to learn if there is better way.
> >
> >
> >
> >
> > On Mon, Dec 28, 2015 at 2:11 PM Hyunsik Choi <hy...@apache.org> wrote:
> >
> > > Hi folks,
> > >
> > > We need to discuss the development workflow and review policy. Many of
> > > committers may be new to ASF development process, and each ASF project
> > > has its own bylaws based on common process. Hence, we need to discuss
> > > and decide them now.
> > >
> > > First of all, you guys need to read the following documentation:
> > >
> > >
> http://www.apache.org/foundation/voting.html#votes-on-code-modification
> > > http://www.apache.org/foundation/glossary.html#CommitThenReview
> > > http://www.apache.org/foundation/glossary.html#ReviewThenCommit
> > >
> > > Most of the code modifications should involve voting process.
> > > According to whether you guys follow lazy consensus or not, you can
> > > choose CTR (commit then review) and RTC (review then commit).
> > >
> > > Simply, RTC requires +1 from at least one committer without -1 before
> > > the patch commit. CTS can get +1 even after the patch commit, but the
> > > patch can be reverted according to the result of reviews.
> > >
> > > Which policy do you guys prefer?
> > >
> > > Best regards,
> > > Hyunsik
> > >
> >
>

Re: [DISCUSSION] workflow and review policy

["Kim, Min-Seok" <ms...@gmail.com>]

As Do Yung mentioned, I have worked as the process.

So I prefer CTR, but I am also willing to learn if there is a better way.

Minseok

On Tue, Dec 29, 2015 at 10:33 AM, DO YUNG YOON <sh...@gmail.com> wrote:

> regarding to workflow, following was how I have worked with S2Graph before
> ASF incubation.
>
> 1. create Issue.
> 2. create branch with Issue number.
> 3. all works related to issue committed into Issue branch.
> 4. create PR.
> 5. review through github.
> 6. squash and merge them into develop.
> 7. run all test cases on develop branch.
> 8. merge develop into master.
>
> above has been works pretty well for me so I prefer CTR, but I am willing
> to learn if there is better way.
>
>
>
>
> On Mon, Dec 28, 2015 at 2:11 PM Hyunsik Choi <hy...@apache.org> wrote:
>
> > Hi folks,
> >
> > We need to discuss the development workflow and review policy. Many of
> > committers may be new to ASF development process, and each ASF project
> > has its own bylaws based on common process. Hence, we need to discuss
> > and decide them now.
> >
> > First of all, you guys need to read the following documentation:
> >
> > http://www.apache.org/foundation/voting.html#votes-on-code-modification
> > http://www.apache.org/foundation/glossary.html#CommitThenReview
> > http://www.apache.org/foundation/glossary.html#ReviewThenCommit
> >
> > Most of the code modifications should involve voting process.
> > According to whether you guys follow lazy consensus or not, you can
> > choose CTR (commit then review) and RTC (review then commit).
> >
> > Simply, RTC requires +1 from at least one committer without -1 before
> > the patch commit. CTS can get +1 even after the patch commit, but the
> > patch can be reverted according to the result of reviews.
> >
> > Which policy do you guys prefer?
> >
> > Best regards,
> > Hyunsik
> >
>

Re: [DISCUSSION] workflow and review policy

[DO YUNG YOON <sh...@gmail.com>]

regarding to workflow, following was how I have worked with S2Graph before
ASF incubation.

1. create Issue.
2. create branch with Issue number.
3. all works related to issue committed into Issue branch.
4. create PR.
5. review through github.
6. squash and merge them into develop.
7. run all test cases on develop branch.
8. merge develop into master.

above has been works pretty well for me so I prefer CTR, but I am willing
to learn if there is better way.




On Mon, Dec 28, 2015 at 2:11 PM Hyunsik Choi <hy...@apache.org> wrote:

> Hi folks,
>
> We need to discuss the development workflow and review policy. Many of
> committers may be new to ASF development process, and each ASF project
> has its own bylaws based on common process. Hence, we need to discuss
> and decide them now.
>
> First of all, you guys need to read the following documentation:
>
> http://www.apache.org/foundation/voting.html#votes-on-code-modification
> http://www.apache.org/foundation/glossary.html#CommitThenReview
> http://www.apache.org/foundation/glossary.html#ReviewThenCommit
>
> Most of the code modifications should involve voting process.
> According to whether you guys follow lazy consensus or not, you can
> choose CTR (commit then review) and RTC (review then commit).
>
> Simply, RTC requires +1 from at least one committer without -1 before
> the patch commit. CTS can get +1 even after the patch commit, but the
> patch can be reverted according to the result of reviews.
>
> Which policy do you guys prefer?
>
> Best regards,
> Hyunsik
>