You are viewing a plain text version of this content. The canonical link for it is here.

Posted to dev@zookeeper.apache.org by Michael Han <ha...@cloudera.com> on 2016/10/04 18:42:46 UTC

Re: [VOTE] move Apache Zookeeper to git

Hi,

Now we've moved to git, what is the policy for uploading patches and doing
code reviews? I am asking because I've seen recently there are git pull
requests coming in without associated patch file uploaded to JIRA. I've
checked
https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute,
looks like there is not much change regarding patch process - so presumably
we still need to generate and upload patch file to JIRA for the record,
while using github (maybe in addition of review board, or in the future
with gerrit) to do code reviews?


On Wed, Sep 21, 2016 at 6:05 AM, Edward Ribeiro <ed...@gmail.com>
wrote:

> Cool, just open https://issues.apache.org/jira/browse/ZOOKEEPER-2597
>
> PS: I removed the REPO_HOME global variable.
>
> On Wed, Sep 21, 2016 at 6:53 AM, Flavio Junqueira <fp...@apache.org> wrote:
>
> > Better to have that in the form of a pull request or diff.
> >
> > REPO_HOME does seem to be unused.
> >
> > -Flavio
> >
> > > On 20 Sep 2016, at 18:57, Edward Ribeiro <ed...@gmail.com>
> > wrote:
> > >
> > > Hey, I have started porting the kafka-merge.py to work on ZK repos. I
> > would
> > > need someone to review it and help me test it now.
> > >
> > > The files were uploaded below, but I will create a github repo yet
> today.
> > >
> > > https://www.dropbox.com/sh/od8bet2574jttm3/
> > AADv1DXTb8vfyVCmelFbYCEha?dl=0
> > >
> > > I uploaded the kafka version script so that you can use diff or Meld to
> > > spot my changes, but feel free to grasp the original file here:
> > > https://github.com/apache/kafka/blob/trunk/kafka-merge-pr.py
> > >
> > > PS: It's just me or REPO_HOME env variable is not used anywhere in the
> > > merge script???
> > >
> > > Cheers,
> > > Eddie
> > >
> > > On Tue, Sep 20, 2016 at 12:19 PM, Patrick Hunt <ph...@apache.org>
> wrote:
> > >
> > >> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin Reed <br...@apache.org>
> > wrote:
> > >>
> > >>> what you are suggesting sounds good, but i don't know how to do it?
> > since
> > >>> in the end we are still just accepting diffs on patches, the only
> thing
> > >>> that changes is that we use svn rather than git right?
> > >>>
> > >>>
> > >> Notice the workflow Kafka uses - which includes "git apply" and
> > specifying
> > >> the author tag when committers commit (so that the OP gets proper
> > >> attribution in the commit itself)
> > >>
> > >> https://cwiki.apache.org/confluence/display/KAFKA/
> > Manual+Commit+Workflow
> > >>
> > >> Patrick
> > >>
> > >>
> > >>
> > >>> i LOVE chris's idea! lets do it!
> > >>>
> > >>> ben
> > >>>
> > >>> On Sun, Sep 18, 2016 at 3:22 PM, Patrick Hunt <ph...@apache.org>
> > wrote:
> > >>>
> > >>>> Ben, do you also want to update the "Applying a patch" section to
> make
> > >> it
> > >>>> git specific?
> > >>>>
> > >>>> We (committers) should move to a model where authors get proper
> credit
> > >> in
> > >>>> git. Our old workflow in svn resulted in only the committer being
> > >> listed
> > >>>> (except that we listed the patch author in the commit message). We
> > >> should
> > >>>> move to a model where the author of the patch gets proper credit in
> > >> git.
> > >>> I
> > >>>> believe we will get that if we use git for patch
> creation/application?
> > >>>>
> > >>>> Chris brought up getting rid of CHANGES.txt recently on the dev list
> > >> in a
> > >>>> separate thread - Chris do you want to implement that change now
> that
> > >>> we've
> > >>>> moved to git?
> > >>>>
> > >>>> Patrick
> > >>>>
> > >>>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin Reed <br...@apache.org>
> > >> wrote:
> > >>>>
> > >>>>>> 1) actually in the previous step that was just adding new files.
> you
> > >>>>>> still
> > >>>>>>> need the commit -a for the rest of the changes. that's my normal
> > >>>>>> workflow.
> > >>>>>>
> > >>>>>> I think that will be confusing for most folks. They typically
> stage
> > >>>>>> all the changes and then commit or don't stage and use -a.
> > >>>>>>
> > >>>>>
> > >>>>> do you mind fixing it with your workflow. commit -a doesn't get new
> > >>>>> files, which is why you need to do the add, but i'm not the most
> > >>>>> sophisticated git user, so
> > >>>>>
> > >>>>>
> > >>>>>>
> > >>>>>>> 2) i figured since we are using git now that we should use git's
> > >>>>>> default.
> > >>>>>>> the patch should work (by default it seems to strip the first
> path
> > >>>>>> element).
> > >>>>>>> does it not work for you?
> > >>>>>>>
> > >>>>>>
> > >>>>>> It will fail precommit in it's current state.
> > >>>>>>
> > >>>>>
> > >>>>> fixed
> > >>>>>
> > >>>>
> > >>>>
> > >>>
> > >>
> >
> >
>



-- 
Cheers
Michael.

Re: [VOTE] move Apache Zookeeper to git

Posted by Flavio Junqueira <fp...@apache.org>.

Apparently, infra allowed Kafka to not have comments written to the dev list or jira. There is a thread discussing whether that decision should be reverted or not. Not sure how much value it adds to this discussion, but it is good to have another reference:

http://mail-archives.apache.org/mod_mbox/kafka-dev/201510.mbox/%3cCAD5tkZaEmmpvS9-6w6KsubhW1ddrowgOYvLs=dhcVL2P2KyBOg@mail.gmail.com%3e <http://mail-archives.apache.org/mod_mbox/kafka-dev/201510.mbox/%3CCAD5tkZaEmmpvS9-6w6KsubhW1ddrowgOYvLs=dhcVL2P2KyBOg@mail.gmail.com%3E>

-Flavio

> On 04 Oct 2016, at 22:40, Michael Han <ha...@cloudera.com> wrote:
> 
>>> as long as the opening/closing/commenting all get sent to the mailing
> list or recorded in jira
> Yeah, this is my impression as well, that we need to keep certain paper
> trail regarding activities and comments on ASF side (JIRA or mail list).
> Infra page said:
> 
>   - Any Pull Request that gets opened, closed, reopened or **commented**
>   on now gets recorded on the project's mailing list
>   - If a project has a JIRA instance, any PRs or *comments* on PRs that
>   include a JIRA ticket ID will trigger an update on that specific ticket
> 
> I checked a couple Kafka and Spark JIRAs but I don't see any of the
> comments made in github PR were posted on JIRA, except the activities (open
> a PR, close a PR). Since both projects have been using github for a while I
> assume such practice of NOT integrating comments between github and ASF
> JIRA is acceptable? Though I feel it would be really useful if comments
> could converge in a single place as well, that will provide a clear history
> for a given technical issue.
> 
> On Tue, Oct 4, 2016 at 12:06 PM, Flavio Junqueira <fpj@apache.org <ma...@apache.org>> wrote:
> 
>> Until ZOOKEEPER-2597 <https://issues.apache.org/jira/browse/ZOOKEEPER-2597 <https://issues.apache.org/jira/browse/ZOOKEEPER-2597>>
>> is fixed, we can't merge via github.
>> 
>> For code reviews, we can use GH as long as the opening/closing/commenting
>> all get sent to the mailing list or recorded in jira. I don't think we have
>> that yet, but it is possible according to this:
>> 
>> https://blogs.apache.org/infra/entry/improved_ <https://blogs.apache.org/infra/entry/improved_>
>> integration_between_apache_and <https://blogs.apache.org/ <https://blogs.apache.org/>
>> infra/entry/improved_integration_between_apache_and>
>> 
>> For now, we do need to upload patches and converge using jira.
>> 
>> I think Eddie has been looking at this process trying to replicate the
>> Kafka setup, so perhaps he can give an update if I'm right. Kafka doesn't
>> send every comment to the mailing list, though, but I'm not sure if that's
>> acceptable according to the ASF, I need to double-check.
>> 
>> -Flavio
>> 
>>> On 04 Oct 2016, at 19:42, Michael Han <ha...@cloudera.com> wrote:
>>> 
>>> Hi,
>>> 
>>> Now we've moved to git, what is the policy for uploading patches and
>> doing
>>> code reviews? I am asking because I've seen recently there are git pull
>>> requests coming in without associated patch file uploaded to JIRA. I've
>>> checked
>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute,
>>> looks like there is not much change regarding patch process - so
>> presumably
>>> we still need to generate and upload patch file to JIRA for the record,
>>> while using github (maybe in addition of review board, or in the future
>>> with gerrit) to do code reviews?
>>> 
>>> 
>>> On Wed, Sep 21, 2016 at 6:05 AM, Edward Ribeiro <
>> edward.ribeiro@gmail.com>
>>> wrote:
>>> 
>>>> Cool, just open https://issues.apache.org/jira/browse/ZOOKEEPER-2597
>>>> 
>>>> PS: I removed the REPO_HOME global variable.
>>>> 
>>>> On Wed, Sep 21, 2016 at 6:53 AM, Flavio Junqueira <fp...@apache.org>
>> wrote:
>>>> 
>>>>> Better to have that in the form of a pull request or diff.
>>>>> 
>>>>> REPO_HOME does seem to be unused.
>>>>> 
>>>>> -Flavio
>>>>> 
>>>>>> On 20 Sep 2016, at 18:57, Edward Ribeiro <ed...@gmail.com>
>>>>> wrote:
>>>>>> 
>>>>>> Hey, I have started porting the kafka-merge.py to work on ZK repos. I
>>>>> would
>>>>>> need someone to review it and help me test it now.
>>>>>> 
>>>>>> The files were uploaded below, but I will create a github repo yet
>>>> today.
>>>>>> 
>>>>>> https://www.dropbox.com/sh/od8bet2574jttm3/
>>>>> AADv1DXTb8vfyVCmelFbYCEha?dl=0
>>>>>> 
>>>>>> I uploaded the kafka version script so that you can use diff or Meld
>> to
>>>>>> spot my changes, but feel free to grasp the original file here:
>>>>>> https://github.com/apache/kafka/blob/trunk/kafka-merge-pr.py
>>>>>> 
>>>>>> PS: It's just me or REPO_HOME env variable is not used anywhere in the
>>>>>> merge script???
>>>>>> 
>>>>>> Cheers,
>>>>>> Eddie
>>>>>> 
>>>>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick Hunt <ph...@apache.org>
>>>> wrote:
>>>>>> 
>>>>>>> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin Reed <br...@apache.org>
>>>>> wrote:
>>>>>>> 
>>>>>>>> what you are suggesting sounds good, but i don't know how to do it?
>>>>> since
>>>>>>>> in the end we are still just accepting diffs on patches, the only
>>>> thing
>>>>>>>> that changes is that we use svn rather than git right?
>>>>>>>> 
>>>>>>>> 
>>>>>>> Notice the workflow Kafka uses - which includes "git apply" and
>>>>> specifying
>>>>>>> the author tag when committers commit (so that the OP gets proper
>>>>>>> attribution in the commit itself)
>>>>>>> 
>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/
>>>>> Manual+Commit+Workflow
>>>>>>> 
>>>>>>> Patrick
>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>>> i LOVE chris's idea! lets do it!
>>>>>>>> 
>>>>>>>> ben
>>>>>>>> 
>>>>>>>> On Sun, Sep 18, 2016 at 3:22 PM, Patrick Hunt <ph...@apache.org>
>>>>> wrote:
>>>>>>>> 
>>>>>>>>> Ben, do you also want to update the "Applying a patch" section to
>>>> make
>>>>>>> it
>>>>>>>>> git specific?
>>>>>>>>> 
>>>>>>>>> We (committers) should move to a model where authors get proper
>>>> credit
>>>>>>> in
>>>>>>>>> git. Our old workflow in svn resulted in only the committer being
>>>>>>> listed
>>>>>>>>> (except that we listed the patch author in the commit message). We
>>>>>>> should
>>>>>>>>> move to a model where the author of the patch gets proper credit in
>>>>>>> git.
>>>>>>>> I
>>>>>>>>> believe we will get that if we use git for patch
>>>> creation/application?
>>>>>>>>> 
>>>>>>>>> Chris brought up getting rid of CHANGES.txt recently on the dev
>> list
>>>>>>> in a
>>>>>>>>> separate thread - Chris do you want to implement that change now
>>>> that
>>>>>>>> we've
>>>>>>>>> moved to git?
>>>>>>>>> 
>>>>>>>>> Patrick
>>>>>>>>> 
>>>>>>>>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin Reed <br...@apache.org>
>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>>> 1) actually in the previous step that was just adding new files.
>>>> you
>>>>>>>>>>> still
>>>>>>>>>>>> need the commit -a for the rest of the changes. that's my normal
>>>>>>>>>>> workflow.
>>>>>>>>>>> 
>>>>>>>>>>> I think that will be confusing for most folks. They typically
>>>> stage
>>>>>>>>>>> all the changes and then commit or don't stage and use -a.
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> do you mind fixing it with your workflow. commit -a doesn't get
>> new
>>>>>>>>>> files, which is why you need to do the add, but i'm not the most
>>>>>>>>>> sophisticated git user, so
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> 2) i figured since we are using git now that we should use git's
>>>>>>>>>>> default.
>>>>>>>>>>>> the patch should work (by default it seems to strip the first
>>>> path
>>>>>>>>>>> element).
>>>>>>>>>>>> does it not work for you?
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> It will fail precommit in it's current state.
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> fixed
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>> 
>>> 
>>> 
>>> --
>>> Cheers
>>> Michael.
>> 
>> 
> 
> 
> -- 
> Cheers
> Michael.

Re: [VOTE] move Apache Zookeeper to git

Posted by Flavio Junqueira <fp...@apache.org>.

Thanks, Eddie. This is great.

> On 26 Oct 2016, at 17:45, Edward Ribeiro <ed...@gmail.com> wrote:
> (still very crude, but feel free to improve it). I would like to move this
> text to https://cwiki.apache.org/confluence/display/ZOOKEEPER/Index but
> looks like I don't have permission to create a page there yet. Any help?
> 

Done.

-Flavio

> 
> On Sat, Oct 22, 2016 at 7:08 PM, Michael Han <ha...@cloudera.com> wrote:
> 
>> FYI infra did some work in INFRA-12752 and the git PR comments can be
>> pushed to Apache JIRA.
>> 
>> On Sat, Oct 8, 2016 at 8:01 AM, Flavio Junqueira <fp...@apache.org> wrote:
>> 
>>> This is not supported at the moment if nothing has changed:
>>> 
>>> https://issues.apache.org/jira/browse/INFRA-11000 <
>>> https://issues.apache.org/jira/browse/INFRA-11000>
>>> 
>>> -Flavio
>>> 
>>>> On 08 Oct 2016, at 00:54, Benjamin Reed <br...@apache.org> wrote:
>>>> 
>>>> it doesn't look like we need to setup keys. this seems to work for me:
>>>> 
>>>> https://git-wip-us.apache.org/#committers-getting-started
>>>> 
>>>> it does seem strange that we aren't using public keys and that i'm
>>> sticking
>>>> a password in .netrc :P i'm wondering if other projects were able to
>> get
>>>> this going over ssh.
>>>> 
>>>> i'll take a whack at cleaning up the svn and subversion references.
>>>> 
>>>> ben
>>>> 
>>>> On Fri, Oct 7, 2016 at 12:59 PM, Camille Fournier <ca...@apache.org>
>>>> wrote:
>>>> 
>>>>> Hey folks,
>>>>> 
>>>>> So I'm trying to get in a patch but this has not been updated to tell
>>>>> committers how to actually get the git keys set up:
>>>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
>>> Committing+changes
>>>>> 
>>>>> Can someone float me a link that says how to do this?
>>>>> 
>>>>> Also a bunch of our documentation still discusses SVN and not git,
>> which
>>>>> means we are not done with this migration. If you were pushing for
>> this
>>>>> change can you please do some due diligence on the wikis and correct
>> the
>>>>> stuff that refers to SVN?
>>>>> 
>>>>> Thanks,
>>>>> C
>>>>> 
>>>>> On Wed, Oct 5, 2016 at 1:02 PM, Edward Ribeiro <
>>> edward.ribeiro@gmail.com>
>>>>> wrote:
>>>>> 
>>>>>> Excuse me guys!
>>>>>> 
>>>>>> I've written on Macbook Pro. No idea why GMail messed it up. I was
>> only
>>>>>> able to see the strange characters when I pasted on a gist text area.
>>> The
>>>>>> previous message is below, but if anyone is still having trouble (I
>>> tried
>>>>>> to remove the weird character), I left a copy at:
>>>>>> https://gist.github.com/eribeiro/da2a6a6c9a508610d52d0755fae8352d
>>>>>> 
>>>>>> "Hi,
>>>>>> 
>>>>>> The patch attached on ZOOKEEPER-2597 is a straightforward adaptation
>> of
>>>>>> Kafka's one. It takes care of merging Github PR into Apache git repo
>>> and
>>>>> a
>>>>>> subsequent closing of the PR on the GH side, among other things
>>>>> (rewriting
>>>>>> of commit messages, etc). The current status is: the script needs to
>> be
>>>>>> reviewed/validated by a committer. It has been some time since I
>>> uploaded
>>>>>> the patch, so I gonna do another pass through it in the meantime.
>>>>>> 
>>>>>> There are some workflow issues beyond the scope of ZOOKEEPER-2597
>> that
>>>>> need
>>>>>> to be sorted out (IMO):
>>>>>> 
>>>>>> 1. The normal workflow is to open a JIRA ticket before doing any GH
>> PR,
>>>>>> that is, no JIRA-less PRs. The PR should have a title of the form
>>>>>> "ZOOKEEPER-xxxx: Title". This will trigger the Apache JIRA-Github
>>>>>> integration and it's opening show up in the JIRA ticket.
>>>>>> 
>>>>>> 2. OTOH, not every Kafka PR needs a corresponding JIRA ticket. There
>>> are
>>>>> a
>>>>>> class of PRs with "MINOR" title that represent trivial code changes
>> and
>>>>>> "HOT-FIX" title that fix urgent, but simple bugs. Both bypass the
>> JIRA
>>>>>> creation step, even tough they are still subject to review. It's
>> worth
>>>>>> adopting a similar approach for ZK project?
>>>>>> 
>>>>>> 3. IIRC (didn't find any page to confirm), Cassandra project
>>> encourages,
>>>>>> but not demands, that contributors also upload a patch file to JIRA
>>> even
>>>>> in
>>>>>> the case of a GH PR (as to leave a audit trail, I guess). Or, at
>>> least,
>>>>> C*
>>>>>> project leaves up to the contributors to either open a GH PR or
>> upload
>>>>> the
>>>>>> patch file to JIRA.
>>>>>> 
>>>>>> 
>>>>>> +1 about having a 'paper trail' of review comments on JIRA and/or
>>> mailing
>>>>>> list (I would prefer the mailing list tbh). But as Michael and Flavio
>>>>>> pointed out, I never seen GH PR review **comments** being written
>> back
>>> to
>>>>>> JIRA, at least not in Kafka, Cassandra or Solr projects, that I have
>>>>>> followed more closely.
>>>>>> 
>>>>>> Eddie"
>>>>>> 
>>>>>> 
>>>>>> On Wed, Oct 5, 2016 at 1:35 PM, Michael Han <ha...@cloudera.com>
>> wrote:
>>>>>> 
>>>>>>> Eddie's mail contains lots of '=E2=80=8B'' which is unicode
>> character
>>>>>>> zero-width space, which might cause parsing trouble for some mail
>>>>>> clients.
>>>>>>> 
>>>>>>> On Wed, Oct 5, 2016 at 6:42 AM, Flavio Junqueira <fp...@apache.org>
>>>>> wrote:
>>>>>>> 
>>>>>>>> Dude, I'm just not able to parse your e-mail, did you write that
>> on a
>>>>>>>> phone or something?
>>>>>>>> 
>>>>>>>> -Flavio
>>>>>>>> 
>>>>>>>>> On 05 Oct 2016, at 03:54, Edward Ribeiro <
>> edward.ribeiro@gmail.com
>>>>>> 
>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> The patch attached on ZOOKEEPER-2597 is a
>>>>>>>>> straightforward adaptation of
>>>>>>>>> Kafka's one. It takes care of merging Github PR into Apache git
>>>>> repo
>>>>>>> and
>>>>>>>>>  a
>>>>>>>>> subsequent closing of the PR on the GH side
>>>>>>>>>  among other things (rewriting of commit messages, etc)
>>>>>>>>> . The current status is: the script needs to be reviewed/validated
>>>>>> by a
>>>>>>>>> committer.
>>>>>>>>> It has been some time since I uploaded the patch, so I gonna do
>>>>>>> another
>>>>>>>>> pass through it in the meantime.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> T
>>>>>>>>> here are some workflow issues beyond the scope of ZOOKEEPER-2597
>>>>>>>>>  that need to be sorted out (IMO)
>>>>>>>>> :
>>>>>>>>> 
>>>>>>>>> 1. The normal workflow is to open a JIRA ticket before doing any
>> GH
>>>>>> PR
>>>>>>>>> , that is, no JIRA-less PRs.
>>>>>>>>> The PR should have a title of the form "ZOOKEEPER-xxxx: Title".
>>>>> This
>>>>>>> will
>>>>>>>>> trigger the Apache JIRA-Github integration and it's opening show
>> up
>>>>>> in
>>>>>>>> the
>>>>>>>>> JIRA ticket.
>>>>>>>>> 
>>>>>>>>> 2.
>>>>>>>>> OTOH, n
>>>>>>>>> ot every Kafka PR needs a corresponding JIRA ticket
>>>>>>>>> . 
>>>>>>>>> There are a class of PR
>>>>>>>>> s
>>>>>>>>> with "MINOR"
>>>>>>>>>  title
>>>>>>>>> that represent trivial code changes
>>>>>>>>>  and "HOT-FIX" title that fix urgent, but simple bugs. Both
>>>>>>>>> bypass the JIRA creation step
>>>>>>>>> , even tough they are still 
>>>>>>>>> subject to review
>>>>>>>>> .
>>>>>>>>> It's worth adopting a similar approach for ZK project?
>>>>>>>>> 
>>>>>>>>> 3. IIRC
>>>>>>>>>  (didn't find any page to confirm)
>>>>>>>>> , Cassandra project encourages, but not demands, that contributors
>>>>>> also
>>>>>>>>> upload a patch file to JIRA even in the case of a GH PR
>>>>>>>>>  (as to leave a audit trail, I guess)
>>>>>>>>> .
>>>>>>>>> Or
>>>>>>>>> ,
>>>>>>>>> at
>>>>>>>>>  
>>>>>>>>> least
>>>>>>>>> ,
>>>>>>>>> C* project 
>>>>>>>>> leave
>>>>>>>>> s
>>>>>>>>> up to the contributor
>>>>>>>>> s
>>>>>>>>> to either open a GH PR or upload the patch file
>>>>>>>>>  to JIRA. In fact, Github allows the access to a raw patch or
>>>>> diff,
>>>>>>> it's
>>>>>>>>> just a matter of adding the ".patch" or ".diff" suffix to the end
>>>>> of
>>>>>>> the
>>>>>>>>> Pull Request URL.
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> +1 about having a 'paper trail'
>>>>>>>>>  of review comments
>>>>>>>>> 
>>>>>>>>> o
>>>>>>>>> n JIRA and
>>>>>>>>> /or
>>>>>>>>> mailing list (I
>>>>>>>>>  would
>>>>>>>>> prefer the mailing list tbh). But as Michael and Flavio pointed
>>>>> out,
>>>>>> I
>>>>>>>>> never seen
>>>>>>>>> GH 
>>>>>>>>> PR review
>>>>>>>>> **
>>>>>>>>> comments
>>>>>>>>> **
>>>>>>>>> being written back to JIRA, at least not in Kafka, Cassandra
>>>>>>>>> or
>>>>>>>>> Solr projects
>>>>>>>>> , that I have followed more closely.
>>>>>>>>> 
>>>>>>>>> Eddie
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Tue, Oct 4, 2016 at 6:40 PM, Michael Han <ha...@cloudera.com>
>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>>>> as long as the opening/closing/commenting all get sent to the
>>>>>>> mailing
>>>>>>>>>> list or recorded in jira
>>>>>>>>>> Yeah, this is my impression as well, that we need to keep certain
>>>>>>> paper
>>>>>>>>>> trail regarding activities and comments on ASF side (JIRA or mail
>>>>>>> list).
>>>>>>>>>> Infra page said:
>>>>>>>>>> 
>>>>>>>>>> - Any Pull Request that gets opened, closed, reopened or
>>>>>>> **commented**
>>>>>>>>>> on now gets recorded on the project's mailing list
>>>>>>>>>> - If a project has a JIRA instance, any PRs or *comments* on PRs
>>>>>>> that
>>>>>>>>>> include a JIRA ticket ID will trigger an update on that specific
>>>>>>>> ticket
>>>>>>>>>> 
>>>>>>>>>> I checked a couple Kafka and Spark JIRAs but I don't see any of
>>>>> the
>>>>>>>>>> comments made in github PR were posted on JIRA, except the
>>>>>> activities
>>>>>>>> (open
>>>>>>>>>> a PR, close a PR). Since both projects have been using github for
>>>>> a
>>>>>>>> while I
>>>>>>>>>> assume such practice of NOT integrating comments between github
>>>>> and
>>>>>>> ASF
>>>>>>>>>> JIRA is acceptable? Though I feel it would be really useful if
>>>>>>> comments
>>>>>>>>>> could converge in a single place as well, that will provide a
>>>>> clear
>>>>>>>> history
>>>>>>>>>> for a given technical issue.
>>>>>>>>>> 
>>>>>>>>>> On Tue, Oct 4, 2016 at 12:06 PM, Flavio Junqueira <
>> fpj@apache.org
>>>>>> 
>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Until ZOOKEEPER-2597 <https://issues.apache.org/
>>>>>>>>>> jira/browse/ZOOKEEPER-2597>
>>>>>>>>>>> is fixed, we can't merge via github.
>>>>>>>>>>> 
>>>>>>>>>>> For code reviews, we can use GH as long as the
>>>>>>>> opening/closing/commenting
>>>>>>>>>>> all get sent to the mailing list or recorded in jira. I don't
>>>>> think
>>>>>>> we
>>>>>>>>>> have
>>>>>>>>>>> that yet, but it is possible according to this:
>>>>>>>>>>> 
>>>>>>>>>>> https://blogs.apache.org/infra/entry/improved_
>>>>>>>>>>> integration_between_apache_and <https://blogs.apache.org/
>>>>>>>>>>> infra/entry/improved_integration_between_apache_and>
>>>>>>>>>>> 
>>>>>>>>>>> For now, we do need to upload patches and converge using jira.
>>>>>>>>>>> 
>>>>>>>>>>> I think Eddie has been looking at this process trying to
>>>>> replicate
>>>>>>> the
>>>>>>>>>>> Kafka setup, so perhaps he can give an update if I'm right.
>> Kafka
>>>>>>>> doesn't
>>>>>>>>>>> send every comment to the mailing list, though, but I'm not sure
>>>>> if
>>>>>>>>>> that's
>>>>>>>>>>> acceptable according to the ASF, I need to double-check.
>>>>>>>>>>> 
>>>>>>>>>>> -Flavio
>>>>>>>>>>> 
>>>>>>>>>>>> On 04 Oct 2016, at 19:42, Michael Han <ha...@cloudera.com>
>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Hi,
>>>>>>>>>>>> 
>>>>>>>>>>>> Now we've moved to git, what is the policy for uploading
>> patches
>>>>>> and
>>>>>>>>>>> doing
>>>>>>>>>>>> code reviews? I am asking because I've seen recently there are
>>>>> git
>>>>>>>> pull
>>>>>>>>>>>> requests coming in without associated patch file uploaded to
>>>>> JIRA.
>>>>>>>> I've
>>>>>>>>>>>> checked
>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
>>>>>>> HowToContribute
>>>>>>>> ,
>>>>>>>>>>>> looks like there is not much change regarding patch process -
>> so
>>>>>>>>>>> presumably
>>>>>>>>>>>> we still need to generate and upload patch file to JIRA for the
>>>>>>>> record,
>>>>>>>>>>>> while using github (maybe in addition of review board, or in
>> the
>>>>>>>> future
>>>>>>>>>>>> with gerrit) to do code reviews?
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> On Wed, Sep 21, 2016 at 6:05 AM, Edward Ribeiro <
>>>>>>>>>>> edward.ribeiro@gmail.com>
>>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Cool, just open https://issues.apache.org/
>>>>>>> jira/browse/ZOOKEEPER-2597
>>>>>>>>>>>>> 
>>>>>>>>>>>>> PS: I removed the REPO_HOME global variable.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> On Wed, Sep 21, 2016 at 6:53 AM, Flavio Junqueira <
>>>>>> fpj@apache.org>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Better to have that in the form of a pull request or diff.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> REPO_HOME does seem to be unused.
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> -Flavio
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On 20 Sep 2016, at 18:57, Edward Ribeiro <
>>>>>>> edward.ribeiro@gmail.com
>>>>>>>>> 
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Hey, I have started porting the kafka-merge.py to work on ZK
>>>>>>> repos.
>>>>>>>>>> I
>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>> need someone to review it and help me test it now.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> The files were uploaded below, but I will create a github
>>>>> repo
>>>>>>> yet
>>>>>>>>>>>>> today.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> https://www.dropbox.com/sh/od8bet2574jttm3/
>>>>>>>>>>>>>> AADv1DXTb8vfyVCmelFbYCEha?dl=0
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> I uploaded the kafka version script so that you can use diff
>>>>> or
>>>>>>>> Meld
>>>>>>>>>>> to
>>>>>>>>>>>>>>> spot my changes, but feel free to grasp the original file
>>>>> here:
>>>>>>>>>>>>>>> https://github.com/apache/kafka/blob/trunk/kafka-merge-
>> pr.py
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> PS: It's just me or REPO_HOME env variable is not used
>>>>> anywhere
>>>>>>> in
>>>>>>>>>> the
>>>>>>>>>>>>>>> merge script???
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>> Eddie
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick Hunt <
>>>>>> phunt@apache.org
>>>>>>>> 
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin Reed <
>>>>>>> breed@apache.org>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> what you are suggesting sounds good, but i don't know how
>>>>> to
>>>>>> do
>>>>>>>>>> it?
>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>>> in the end we are still just accepting diffs on patches,
>>>>> the
>>>>>>> only
>>>>>>>>>>>>> thing
>>>>>>>>>>>>>>>>> that changes is that we use svn rather than git right?
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Notice the workflow Kafka uses - which includes "git apply"
>>>>>> and
>>>>>>>>>>>>>> specifying
>>>>>>>>>>>>>>>> the author tag when committers commit (so that the OP gets
>>>>>>> proper
>>>>>>>>>>>>>>>> attribution in the commit itself)
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/
>>>>>>>>>>>>>> Manual+Commit+Workflow
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Patrick
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> i LOVE chris's idea! lets do it!
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> ben
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Sun, Sep 18, 2016 at 3:22 PM, Patrick Hunt <
>>>>>>> phunt@apache.org>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Ben, do you also want to update the "Applying a patch"
>>>>>> section
>>>>>>>> to
>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>> git specific?
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> We (committers) should move to a model where authors get
>>>>>>> proper
>>>>>>>>>>>>> credit
>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> git. Our old workflow in svn resulted in only the
>>>>> committer
>>>>>>>> being
>>>>>>>>>>>>>>>> listed
>>>>>>>>>>>>>>>>>> (except that we listed the patch author in the commit
>>>>>>> message).
>>>>>>>>>> We
>>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>>> move to a model where the author of the patch gets proper
>>>>>>> credit
>>>>>>>>>> in
>>>>>>>>>>>>>>>> git.
>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>> believe we will get that if we use git for patch
>>>>>>>>>>>>> creation/application?
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Chris brought up getting rid of CHANGES.txt recently on
>>>>> the
>>>>>>> dev
>>>>>>>>>>> list
>>>>>>>>>>>>>>>> in a
>>>>>>>>>>>>>>>>>> separate thread - Chris do you want to implement that
>>>>> change
>>>>>>> now
>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>> we've
>>>>>>>>>>>>>>>>>> moved to git?
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Patrick
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin Reed <
>>>>>>>> breed@apache.org
>>>>>>>>>>> 
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 1) actually in the previous step that was just adding
>>>>> new
>>>>>>>>>> files.
>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>>>>>>>> need the commit -a for the rest of the changes. that's
>>>>> my
>>>>>>>>>> normal
>>>>>>>>>>>>>>>>>>>> workflow.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> I think that will be confusing for most folks. They
>>>>>>> typically
>>>>>>>>>>>>> stage
>>>>>>>>>>>>>>>>>>>> all the changes and then commit or don't stage and use
>>>>> -a.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> do you mind fixing it with your workflow. commit -a
>>>>> doesn't
>>>>>>> get
>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>>> files, which is why you need to do the add, but i'm not
>>>>> the
>>>>>>>> most
>>>>>>>>>>>>>>>>>>> sophisticated git user, so
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 2) i figured since we are using git now that we should
>>>>>> use
>>>>>>>>>> git's
>>>>>>>>>>>>>>>>>>>> default.
>>>>>>>>>>>>>>>>>>>>> the patch should work (by default it seems to strip
>> the
>>>>>>> first
>>>>>>>>>>>>> path
>>>>>>>>>>>>>>>>>>>> element).
>>>>>>>>>>>>>>>>>>>>> does it not work for you?
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> It will fail precommit in it's current state.
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> fixed
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> --
>>>>>>>>>>>> Cheers
>>>>>>>>>>>> Michael.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> --
>>>>>>>>>> Cheers
>>>>>>>>>> Michael.
>>>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Cheers
>>>>>>> Michael.
>>>>>>> 
>>>>>> 
>>>>> 
>>> 
>>> 
>> 
>> 
>> --
>> Cheers
>> Michael.
>>

Re: [VOTE] move Apache Zookeeper to git

Posted by Edward Ribeiro <ed...@gmail.com>.

Patrick,

The 'dummy commit' is a Github trick. In any commit message you can write
"closes #<PR-number>", like "closes #84" (by my own experience you can also
write "fixes #<PR-NUMBER>". You can put as many of those messages as you
like in the commit message even if the commit doesn't have relation with
the PRs. Then GH will close those PRs.

Edward

On Wed, Dec 7, 2016 at 3:21 PM, Edward Ribeiro <ed...@gmail.com>
wrote:

>
> On Wed, Dec 7, 2016 at 2:09 PM, Patrick Hunt <ph...@apache.org> wrote:
>
>> Interesting, thanks for the update Edward.
>>
>> "close via a dummy commit" - I don't think that's possible, doesn't GH
>> match up a PR to a commit based on the hash?
>>
>
> Afaik, yes. I didn't understand what he meant by 'dummy commit', tbqh.
> Gonna ask him now. :)
>
> Edward
>
>

Re: [VOTE] move Apache Zookeeper to git

Posted by Edward Ribeiro <ed...@gmail.com>.

On Wed, Dec 7, 2016 at 2:09 PM, Patrick Hunt <ph...@apache.org> wrote:

> Interesting, thanks for the update Edward.
>
> "close via a dummy commit" - I don't think that's possible, doesn't GH
> match up a PR to a commit based on the hash?
>

Afaik, yes. I didn't understand what he meant by 'dummy commit', tbqh.
Gonna ask him now. :)

Edward

Re: [VOTE] move Apache Zookeeper to git

Posted by Patrick Hunt <ph...@apache.org>.

Interesting, thanks for the update Edward.

"close via a dummy commit" - I don't think that's possible, doesn't GH
match up a PR to a commit based on the hash?

Patrick


On Tue, Dec 6, 2016 at 6:17 AM, Edward Ribeiro <ed...@gmail.com>
wrote:

> Oh, Patrick (and Flavio, and Ben Reed),
>
> I asked some questions to one ASF committer that has been using the
> Github-JIRA-Apache combo for a while now. According to him, committers
> *cannot* manually close 3rd party PRs. :( He said this is a combination of
> Github limitations and INFRA policies, his explanations below:
>
> Question:  1) Do committers have to contact ASF INFRA to be able to close
> PR on Github mirror? Some people created bogus PR that we would like to
> close, but they don't have this option now. Can INFRA give committers the
> auth to close those 3rd party PRs?
>
> Answer: "You either have to ask INFRA, ask the author or close via a dummy
> commit. In our project, we first ask the author and occasionally we ask
> INFRA to close a bunch of them or a particularly bad one (someone had
> created a PR for merging trunk to a stable branch, for example. That would
> cause a PR build every time something was merged to trunk).
>
> Basically, if you have write access to the PRs, you also have write access
> to the GitHub repository. And INFRA believes it's essential for the GitHub
> repo to be read only. The writes flow from the Apache git repo. The Apache
> git repo has more safeguards (although protected branches in GitHub could
> help here, not sure if the Apache INFRA team has considered them)."
>
> Question: At Kafka, all the PR goes through GH? Or do you committers
> usually apply patches directly to Apache git repo?
>
> Answer: "We now always use GitHub, we don't use patches any more"
> Edward
>
> On Mon, Dec 5, 2016 at 9:07 PM, Patrick Hunt <ph...@apache.org> wrote:
>
> > No problem Edward. Did you get any insight on what to do with the PR?
> >
> > Patrick
> >
> > On Thu, Nov 24, 2016 at 10:52 AM, Edward Ribeiro <
> edward.ribeiro@gmail.com
> > >
> > wrote:
> >
> > > Hi, Patrick,
> > >
> > > Thanks for merging this change. :)
> > >
> > > Sincerely, I don't know why it didn't close the PR automatically. Nor
> why
> > > you can close it in the GH mirror. In any case, I manually closed it.
> > >
> > > I will ping folks from other Apache projects using similar tool to
> > inquire
> > > why it didn't close the PR and why it gave this 'write access' error
> > > message.
> > >
> > > Edward
> > >
> > >
> > >
> > > On Fri, Nov 18, 2016 at 8:13 PM, Patrick Hunt <ph...@apache.org>
> wrote:
> > >
> > >> Thanks Edward, this should be very helpful for folks. I committed,
> > >> however I notice the PR is still open. I followed the steps here:
> > >> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> > Committing+changes
> > >> however I don't see a way to close the PR? https://github.com/apache/
> > >> zookeeper/pull/103 says I don't have "write access".
> > >>
> > >> Patrick
> > >>
> > >> On Thu, Nov 10, 2016 at 10:23 AM, Edward Ribeiro <
> > >> edward.ribeiro@gmail.com> wrote:
> > >>
> > >>> Hi Patrick,
> > >>>
> > >>> I've just opened a PR  https://github.com/apache/zookeeper/pull/103/
> > PR
> > >>>
> > >>> It asks for JIRA_PASSWORD at CLI prompt *IF* it's absent but
> > >>> JIRA_USERNAME
> > >>> is already set. Please, when you have time, see if it fits what you
> > need
> > >>> and then I can open a JIRA, rename the feature branch, etc.
> > >>>
> > >>> Let me know if you have other ideas. I am open to other ways of
> > >>> incorporating the passing of JIRA_PASSWORD too.
> > >>>
> > >>> Edward
> > >>>
> > >>> On Wed, Nov 9, 2016 at 5:03 PM, Edward Ribeiro <
> > edward.ribeiro@gmail.com
> > >>> >
> > >>> wrote:
> > >>>
> > >>> > Hi Patrick,
> > >>> >
> > >>> > We can change the script so that it asks for jira password input on
> > CLI
> > >>> > prompt if the JIRA username is set, for example. The change should
> be
> > >>> > straigthforward.
> > >>> >
> > >>> > Alternatively, the python systems I have dealt with put credentials
> > for
> > >>> > database access, etc, in configuration -- sometimes hidden -- files
> > >>> (say,
> > >>> > .env), but yet it is clear text stored.
> > >>> >
> > >>> > Anyone has other suggestions?
> > >>> >
> > >>> > Eddie
> > >>> >
> > >>> > Em 9 de nov de 2016 4:18 PM, "Patrick Hunt" <ph...@apache.org>
> > >>> escreveu:
> > >>> >
> > >>> >> Is there any alternative to step 4 as documented here?
> > >>> >> https://cwiki.apache.org/confluence/display/ZOOKEEPER/Mergin
> > >>> >> g+Github+Pull+Requests
> > >>> >>
> > >>> >> specifically it's asking to "export JIRA_PASSWORD=mypassword"
> which
> > I
> > >>> feel
> > >>> >> very uncomfortable doing.
> > >>> >>
> > >>> >> Patrick
> > >>> >>
> > >>> >> On Wed, Oct 26, 2016 at 11:12 AM, Edward Ribeiro <
> > >>> >> edward.ribeiro@gmail.com>
> > >>> >> wrote:
> > >>> >>
> > >>> >> > AFAIK, yes. I say, if you mean to run unit tests and other CI
> > tasks
> > >>> on
> > >>> >> PR.
> > >>> >> >
> > >>> >> > PS: I have just created a simple script HowTo at
> > >>> >> > https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> > >>> >> > Merging+Github+Pull+Requests
> > >>> >> > and linked from https://cwiki.apache.org/confl
> > >>> uence/display/ZOOKEEPER/
> > >>> >> > Index
> > >>> >> >
> > >>> >> > On Wed, Oct 26, 2016 at 3:59 PM, Flavio Junqueira <
> fpj@apache.org
> > >
> > >>> >> wrote:
> > >>> >> >
> > >>> >> > > What about QA, are we still missing a github pre-commit queue?
> > >>> >> > >
> > >>> >> > > -Flavio
> > >>> >> > >
> > >>> >> > > > On 26 Oct 2016, at 18:53, Michael Han <ha...@cloudera.com>
> > >>> wrote:
> > >>> >> > > >
> > >>> >> > > > The comment bridging should be fixed now - see INFRA-12752
> for
> > >>> more
> > >>> >> > > > details.
> > >>> >> > > >
> > >>> >> > > > On Wed, Oct 26, 2016 at 10:03 AM, Michael Han <
> > >>> hanm@cloudera.com>
> > >>> >> > wrote:
> > >>> >> > > >
> > >>> >> > > >>>> The git PR *review* comments for ZOOKEEPER-2597 didn't
> show
> > >>> up on
> > >>> >> > > JIRA.
> > >>> >> > > >>
> > >>> >> > > >> The bridge was working the day Infra made the change - see
> > the
> > >>> >> > previous
> > >>> >> > > >> comments made by git bot on ZOOKEEPER-761. Now it seems
> stop
> > >>> >> working.
> > >>> >> > I
> > >>> >> > > am
> > >>> >> > > >> reopening INFRA-12752 and building a case.
> > >>> >> > > >>
> > >>> >> > > >> On Wed, Oct 26, 2016 at 9:45 AM, Edward Ribeiro <
> > >>> >> > > edward.ribeiro@gmail.com>
> > >>> >> > > >> wrote:
> > >>> >> > > >>
> > >>> >> > > >>> Dear community,
> > >>> >> > > >>>
> > >>> >> > > >>> The zk-merger-pr.py script has been merged into master
> > >>> (thanks a
> > >>> >> LOT
> > >>> >> > > Ben
> > >>> >> > > >>> Reed for reviewing/discussing/testing and commiting):
> > >>> >> > > >>> https://issues.apache.org/jira/browse/ZOOKEEPER-2597
> > >>> >> > > >>>
> > >>> >> > > >>> As stated in the issue and on GH, this tool is a modified
> > >>> version
> > >>> >> of
> > >>> >> > > >>> similar tools from Kafka, that is a copy of a Spark's one.
> > It
> > >>> has
> > >>> >> > some
> > >>> >> > > >>> rough edges so we will certainly benefit from further
> > >>> enhancements
> > >>> >> > and
> > >>> >> > > >>> fixes. I changed the smallest possible pieces of code,
> just
> > to
> > >>> >> make
> > >>> >> > it
> > >>> >> > > >>> work
> > >>> >> > > >>> on a ZK repo so the credits go to the original authors.
> > >>> >> > > >>>
> > >>> >> > > >>> Some notes:
> > >>> >> > > >>>
> > >>> >> > > >>> 1. The git PR *review* comments for ZOOKEEPER-2597 didn't
> > >>> show up
> > >>> >> on
> > >>> >> > > JIRA.
> > >>> >> > > >>> Only the opening and closing of the issue. Can we double
> > check
> > >>> >> this
> > >>> >> > as
> > >>> >> > > >>> INFRA-12752 is closed, Michael Han?
> > >>> >> > > >>>
> > >>> >> > > >>> 2. I scribbled a draft on how use the tool at
> > >>> >> > > >>> https://docs.google.com/document/d/1i00ZXjrW2fu17vr_
> > h7F1bUrq
> > >>> >> > > >>> Xg3urw4Hm7KirQDpPIU/edit
> > >>> >> > > >>> (still very crude, but feel free to improve it). I would
> > like
> > >>> to
> > >>> >> move
> > >>> >> > > >>> this
> > >>> >> > > >>> text to https://cwiki.apache.org/confl
> > >>> >> uence/display/ZOOKEEPER/Index
> > >>> >> > > but
> > >>> >> > > >>> looks like I don't have permission to create a page there
> > >>> yet. Any
> > >>> >> > > help?
> > >>> >> > > >>>
> > >>> >> > > >>> Best regards,
> > >>> >> > > >>> Eddie
> > >>> >> > > >>>
> > >>> >> > > >>> On Sat, Oct 22, 2016 at 7:08 PM, Michael Han <
> > >>> hanm@cloudera.com>
> > >>> >> > > wrote:
> > >>> >> > > >>>
> > >>> >> > > >>>> FYI infra did some work in INFRA-12752 and the git PR
> > >>> comments
> > >>> >> can
> > >>> >> > be
> > >>> >> > > >>>> pushed to Apache JIRA.
> > >>> >> > > >>>>
> > >>> >> > > >>>> On Sat, Oct 8, 2016 at 8:01 AM, Flavio Junqueira <
> > >>> fpj@apache.org
> > >>> >> >
> > >>> >> > > >>> wrote:
> > >>> >> > > >>>>
> > >>> >> > > >>>>> This is not supported at the moment if nothing has
> > changed:
> > >>> >> > > >>>>>
> > >>> >> > > >>>>> https://issues.apache.org/jira/browse/INFRA-11000 <
> > >>> >> > > >>>>> https://issues.apache.org/jira/browse/INFRA-11000>
> > >>> >> > > >>>>>
> > >>> >> > > >>>>> -Flavio
> > >>> >> > > >>>>>
> > >>> >> > > >>>>>> On 08 Oct 2016, at 00:54, Benjamin Reed <
> > breed@apache.org>
> > >>> >> wrote:
> > >>> >> > > >>>>>>
> > >>> >> > > >>>>>> it doesn't look like we need to setup keys. this seems
> to
> > >>> work
> > >>> >> for
> > >>> >> > > >>> me:
> > >>> >> > > >>>>>>
> > >>> >> > > >>>>>> https://git-wip-us.apache.org/
> > #committers-getting-started
> > >>> >> > > >>>>>>
> > >>> >> > > >>>>>> it does seem strange that we aren't using public keys
> and
> > >>> that
> > >>> >> i'm
> > >>> >> > > >>>>> sticking
> > >>> >> > > >>>>>> a password in .netrc :P i'm wondering if other projects
> > >>> were
> > >>> >> able
> > >>> >> > to
> > >>> >> > > >>>> get
> > >>> >> > > >>>>>> this going over ssh.
> > >>> >> > > >>>>>>
> > >>> >> > > >>>>>> i'll take a whack at cleaning up the svn and subversion
> > >>> >> > references.
> > >>> >> > > >>>>>>
> > >>> >> > > >>>>>> ben
> > >>> >> > > >>>>>>
> > >>> >> > > >>>>>> On Fri, Oct 7, 2016 at 12:59 PM, Camille Fournier <
> > >>> >> > > >>> camille@apache.org>
> > >>> >> > > >>>>>> wrote:
> > >>> >> > > >>>>>>
> > >>> >> > > >>>>>>> Hey folks,
> > >>> >> > > >>>>>>>
> > >>> >> > > >>>>>>> So I'm trying to get in a patch but this has not been
> > >>> updated
> > >>> >> to
> > >>> >> > > >>> tell
> > >>> >> > > >>>>>>> committers how to actually get the git keys set up:
> > >>> >> > > >>>>>>> https://cwiki.apache.org/
> confluence/display/ZOOKEEPER/
> > >>> >> > > >>>>> Committing+changes
> > >>> >> > > >>>>>>>
> > >>> >> > > >>>>>>> Can someone float me a link that says how to do this?
> > >>> >> > > >>>>>>>
> > >>> >> > > >>>>>>> Also a bunch of our documentation still discusses SVN
> > and
> > >>> not
> > >>> >> > git,
> > >>> >> > > >>>> which
> > >>> >> > > >>>>>>> means we are not done with this migration. If you were
> > >>> pushing
> > >>> >> > for
> > >>> >> > > >>>> this
> > >>> >> > > >>>>>>> change can you please do some due diligence on the
> wikis
> > >>> and
> > >>> >> > > >>> correct
> > >>> >> > > >>>> the
> > >>> >> > > >>>>>>> stuff that refers to SVN?
> > >>> >> > > >>>>>>>
> > >>> >> > > >>>>>>> Thanks,
> > >>> >> > > >>>>>>> C
> > >>> >> > > >>>>>>>
> > >>> >> > > >>>>>>> On Wed, Oct 5, 2016 at 1:02 PM, Edward Ribeiro <
> > >>> >> > > >>>>> edward.ribeiro@gmail.com>
> > >>> >> > > >>>>>>> wrote:
> > >>> >> > > >>>>>>>
> > >>> >> > > >>>>>>>> Excuse me guys!
> > >>> >> > > >>>>>>>>
> > >>> >> > > >>>>>>>> I've written on Macbook Pro. No idea why GMail messed
> > it
> > >>> up.
> > >>> >> I
> > >>> >> > was
> > >>> >> > > >>>> only
> > >>> >> > > >>>>>>>> able to see the strange characters when I pasted on a
> > >>> gist
> > >>> >> text
> > >>> >> > > >>> area.
> > >>> >> > > >>>>> The
> > >>> >> > > >>>>>>>> previous message is below, but if anyone is still
> > having
> > >>> >> trouble
> > >>> >> > > >>> (I
> > >>> >> > > >>>>> tried
> > >>> >> > > >>>>>>>> to remove the weird character), I left a copy at:
> > >>> >> > > >>>>>>>> https://gist.github.com/eribei
> > >>> ro/da2a6a6c9a508610d52d0755fae
> > >>> >> 835
> > >>> >> > 2d
> > >>> >> > > >>>>>>>>
> > >>> >> > > >>>>>>>> "Hi,
> > >>> >> > > >>>>>>>>
> > >>> >> > > >>>>>>>> The patch attached on ZOOKEEPER-2597 is a
> > straightforward
> > >>> >> > > >>> adaptation
> > >>> >> > > >>>> of
> > >>> >> > > >>>>>>>> Kafka's one. It takes care of merging Github PR into
> > >>> Apache
> > >>> >> git
> > >>> >> > > >>> repo
> > >>> >> > > >>>>> and
> > >>> >> > > >>>>>>> a
> > >>> >> > > >>>>>>>> subsequent closing of the PR on the GH side, among
> > other
> > >>> >> things
> > >>> >> > > >>>>>>> (rewriting
> > >>> >> > > >>>>>>>> of commit messages, etc). The current status is: the
> > >>> script
> > >>> >> > needs
> > >>> >> > > >>> to
> > >>> >> > > >>>> be
> > >>> >> > > >>>>>>>> reviewed/validated by a committer. It has been some
> > time
> > >>> >> since I
> > >>> >> > > >>>>> uploaded
> > >>> >> > > >>>>>>>> the patch, so I gonna do another pass through it in
> the
> > >>> >> > meantime.
> > >>> >> > > >>>>>>>>
> > >>> >> > > >>>>>>>> There are some workflow issues beyond the scope of
> > >>> >> > ZOOKEEPER-2597
> > >>> >> > > >>>> that
> > >>> >> > > >>>>>>> need
> > >>> >> > > >>>>>>>> to be sorted out (IMO):
> > >>> >> > > >>>>>>>>
> > >>> >> > > >>>>>>>> 1. The normal workflow is to open a JIRA ticket
> before
> > >>> doing
> > >>> >> any
> > >>> >> > > >>> GH
> > >>> >> > > >>>> PR,
> > >>> >> > > >>>>>>>> that is, no JIRA-less PRs. The PR should have a title
> > of
> > >>> the
> > >>> >> > form
> > >>> >> > > >>>>>>>> "ZOOKEEPER-xxxx: Title". This will trigger the Apache
> > >>> >> > JIRA-Github
> > >>> >> > > >>>>>>>> integration and it's opening show up in the JIRA
> > ticket.
> > >>> >> > > >>>>>>>>
> > >>> >> > > >>>>>>>> 2. OTOH, not every Kafka PR needs a corresponding
> JIRA
> > >>> >> ticket.
> > >>> >> > > >>> There
> > >>> >> > > >>>>> are
> > >>> >> > > >>>>>>> a
> > >>> >> > > >>>>>>>> class of PRs with "MINOR" title that represent
> trivial
> > >>> code
> > >>> >> > > >>> changes
> > >>> >> > > >>>> and
> > >>> >> > > >>>>>>>> "HOT-FIX" title that fix urgent, but simple bugs.
> Both
> > >>> bypass
> > >>> >> > the
> > >>> >> > > >>>> JIRA
> > >>> >> > > >>>>>>>> creation step, even tough they are still subject to
> > >>> review.
> > >>> >> It's
> > >>> >> > > >>>> worth
> > >>> >> > > >>>>>>>> adopting a similar approach for ZK project?
> > >>> >> > > >>>>>>>>
> > >>> >> > > >>>>>>>> 3. IIRC (didn't find any page to confirm), Cassandra
> > >>> project
> > >>> >> > > >>>>> encourages,
> > >>> >> > > >>>>>>>> but not demands, that contributors also upload a
> patch
> > >>> file
> > >>> >> to
> > >>> >> > > >>> JIRA
> > >>> >> > > >>>>> even
> > >>> >> > > >>>>>>> in
> > >>> >> > > >>>>>>>> the case of a GH PR (as to leave a audit trail, I
> > guess).
> > >>> >> Or, at
> > >>> >> > > >>>>> least,
> > >>> >> > > >>>>>>> C*
> > >>> >> > > >>>>>>>> project leaves up to the contributors to either open
> a
> > >>> GH PR
> > >>> >> or
> > >>> >> > > >>>> upload
> > >>> >> > > >>>>>>> the
> > >>> >> > > >>>>>>>> patch file to JIRA.
> > >>> >> > > >>>>>>>>
> > >>> >> > > >>>>>>>>
> > >>> >> > > >>>>>>>> +1 about having a 'paper trail' of review comments on
> > >>> JIRA
> > >>> >> > and/or
> > >>> >> > > >>>>> mailing
> > >>> >> > > >>>>>>>> list (I would prefer the mailing list tbh). But as
> > >>> Michael
> > >>> >> and
> > >>> >> > > >>> Flavio
> > >>> >> > > >>>>>>>> pointed out, I never seen GH PR review **comments**
> > being
> > >>> >> > written
> > >>> >> > > >>>> back
> > >>> >> > > >>>>> to
> > >>> >> > > >>>>>>>> JIRA, at least not in Kafka, Cassandra or Solr
> > projects,
> > >>> >> that I
> > >>> >> > > >>> have
> > >>> >> > > >>>>>>>> followed more closely.
> > >>> >> > > >>>>>>>>
> > >>> >> > > >>>>>>>> Eddie"
> > >>> >> > > >>>>>>>>
> > >>> >> > > >>>>>>>>
> > >>> >> > > >>>>>>>> On Wed, Oct 5, 2016 at 1:35 PM, Michael Han <
> > >>> >> hanm@cloudera.com>
> > >>> >> > > >>>> wrote:
> > >>> >> > > >>>>>>>>
> > >>> >> > > >>>>>>>>> Eddie's mail contains lots of '=E2=80=8B'' which is
> > >>> unicode
> > >>> >> > > >>>> character
> > >>> >> > > >>>>>>>>> zero-width space, which might cause parsing trouble
> > for
> > >>> some
> > >>> >> > mail
> > >>> >> > > >>>>>>>> clients.
> > >>> >> > > >>>>>>>>>
> > >>> >> > > >>>>>>>>> On Wed, Oct 5, 2016 at 6:42 AM, Flavio Junqueira <
> > >>> >> > fpj@apache.org
> > >>> >> > > >>>>
> > >>> >> > > >>>>>>> wrote:
> > >>> >> > > >>>>>>>>>
> > >>> >> > > >>>>>>>>>> Dude, I'm just not able to parse your e-mail, did
> you
> > >>> write
> > >>> >> > that
> > >>> >> > > >>>> on a
> > >>> >> > > >>>>>>>>>> phone or something?
> > >>> >> > > >>>>>>>>>>
> > >>> >> > > >>>>>>>>>> -Flavio
> > >>> >> > > >>>>>>>>>>
> > >>> >> > > >>>>>>>>>>> On 05 Oct 2016, at 03:54, Edward Ribeiro <
> > >>> >> > > >>>> edward.ribeiro@gmail.com
> > >>> >> > > >>>>>>>>
> > >>> >> > > >>>>>>>>>> wrote:
> > >>> >> > > >>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>> Hi,
> > >>> >> > > >>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>> The patch attached on ZOOKEEPER-2597 is a
> > >>> >> > > >>>>>>>>>>> straightforward adaptation of
> > >>> >> > > >>>>>>>>>>> Kafka's one. It takes care of merging Github PR
> into
> > >>> >> Apache
> > >>> >> > git
> > >>> >> > > >>>>>>> repo
> > >>> >> > > >>>>>>>>> and
> > >>> >> > > >>>>>>>>>>>  a
> > >>> >> > > >>>>>>>>>>> subsequent closing of the PR on the GH side
> > >>> >> > > >>>>>>>>>>>  among other things (rewriting of commit
> messages,
> > >>> etc)
> > >>> >> > > >>>>>>>>>>> . The current status is: the script needs to be
> > >>> >> > > >>> reviewed/validated
> > >>> >> > > >>>>>>>> by a
> > >>> >> > > >>>>>>>>>>> committer.
> > >>> >> > > >>>>>>>>>>> It has been some time since I uploaded the patch,
> > so
> > >>> I
> > >>> >> gonna
> > >>> >> > > >>> do
> > >>> >> > > >>>>>>>>> another
> > >>> >> > > >>>>>>>>>>> pass through it in the meantime.
> > >>> >> > > >>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>> T
> > >>> >> > > >>>>>>>>>>> here are some workflow issues beyond the scope of
> > >>> >> > > >>> ZOOKEEPER-2597
> > >>> >> > > >>>>>>>>>>>  that need to be sorted out (IMO)
> > >>> >> > > >>>>>>>>>>> :
> > >>> >> > > >>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>> 1. The normal workflow is to open a JIRA ticket
> > before
> > >>> >> doing
> > >>> >> > > >>> any
> > >>> >> > > >>>> GH
> > >>> >> > > >>>>>>>> PR
> > >>> >> > > >>>>>>>>>>> , that is, no JIRA-less PRs.
> > >>> >> > > >>>>>>>>>>> The PR should have a title of the form
> > >>> "ZOOKEEPER-xxxx:
> > >>> >> > Title".
> > >>> >> > > >>>>>>> This
> > >>> >> > > >>>>>>>>> will
> > >>> >> > > >>>>>>>>>>> trigger the Apache JIRA-Github integration and
> it's
> > >>> >> opening
> > >>> >> > > >>> show
> > >>> >> > > >>>> up
> > >>> >> > > >>>>>>>> in
> > >>> >> > > >>>>>>>>>> the
> > >>> >> > > >>>>>>>>>>> JIRA ticket.
> > >>> >> > > >>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>> 2.
> > >>> >> > > >>>>>>>>>>> OTOH, n
> > >>> >> > > >>>>>>>>>>> ot every Kafka PR needs a corresponding JIRA
> ticket
> > >>> >> > > >>>>>>>>>>> . 
> > >>> >> > > >>>>>>>>>>> There are a class of PR
> > >>> >> > > >>>>>>>>>>> s
> > >>> >> > > >>>>>>>>>>> with "MINOR"
> > >>> >> > > >>>>>>>>>>>  title
> > >>> >> > > >>>>>>>>>>> that represent trivial code changes
> > >>> >> > > >>>>>>>>>>>  and "HOT-FIX" title that fix urgent, but simple
> > >>> bugs.
> > >>> >> Both
> > >>> >> > > >>>>>>>>>>> bypass the JIRA creation step
> > >>> >> > > >>>>>>>>>>> , even tough they are still 
> > >>> >> > > >>>>>>>>>>> subject to review
> > >>> >> > > >>>>>>>>>>> .
> > >>> >> > > >>>>>>>>>>> It's worth adopting a similar approach for ZK
> > project?
> > >>> >> > > >>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>> 3. IIRC
> > >>> >> > > >>>>>>>>>>>  (didn't find any page to confirm)
> > >>> >> > > >>>>>>>>>>> , Cassandra project encourages, but not demands,
> > that
> > >>> >> > > >>> contributors
> > >>> >> > > >>>>>>>> also
> > >>> >> > > >>>>>>>>>>> upload a patch file to JIRA even in the case of a
> GH
> > >>> PR
> > >>> >> > > >>>>>>>>>>>  (as to leave a audit trail, I guess)
> > >>> >> > > >>>>>>>>>>> .
> > >>> >> > > >>>>>>>>>>> Or
> > >>> >> > > >>>>>>>>>>> ,
> > >>> >> > > >>>>>>>>>>> at
> > >>> >> > > >>>>>>>>>>>  
> > >>> >> > > >>>>>>>>>>> least
> > >>> >> > > >>>>>>>>>>> ,
> > >>> >> > > >>>>>>>>>>> C* project 
> > >>> >> > > >>>>>>>>>>> leave
> > >>> >> > > >>>>>>>>>>> s
> > >>> >> > > >>>>>>>>>>> up to the contributor
> > >>> >> > > >>>>>>>>>>> s
> > >>> >> > > >>>>>>>>>>> to either open a GH PR or upload the patch file
> > >>> >> > > >>>>>>>>>>>  to JIRA. In fact, Github allows the access to a
> > raw
> > >>> >> patch
> > >>> >> > or
> > >>> >> > > >>>>>>> diff,
> > >>> >> > > >>>>>>>>> it's
> > >>> >> > > >>>>>>>>>>> just a matter of adding the ".patch" or ".diff"
> > >>> suffix to
> > >>> >> the
> > >>> >> > > >>> end
> > >>> >> > > >>>>>>> of
> > >>> >> > > >>>>>>>>> the
> > >>> >> > > >>>>>>>>>>> Pull Request URL.
> > >>> >> > > >>>>>>>>>>> 
> > >>> >> > > >>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>> +1 about having a 'paper trail'
> > >>> >> > > >>>>>>>>>>>  of review comments
> > >>> >> > > >>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>> o
> > >>> >> > > >>>>>>>>>>> n JIRA and
> > >>> >> > > >>>>>>>>>>> /or
> > >>> >> > > >>>>>>>>>>> mailing list (I
> > >>> >> > > >>>>>>>>>>>  would
> > >>> >> > > >>>>>>>>>>> prefer the mailing list tbh). But as Michael and
> > >>> Flavio
> > >>> >> > pointed
> > >>> >> > > >>>>>>> out,
> > >>> >> > > >>>>>>>> I
> > >>> >> > > >>>>>>>>>>> never seen
> > >>> >> > > >>>>>>>>>>> GH 
> > >>> >> > > >>>>>>>>>>> PR review
> > >>> >> > > >>>>>>>>>>> **
> > >>> >> > > >>>>>>>>>>> comments
> > >>> >> > > >>>>>>>>>>> **
> > >>> >> > > >>>>>>>>>>> being written back to JIRA, at least not in Kafka,
> > >>> >> Cassandra
> > >>> >> > > >>>>>>>>>>> or
> > >>> >> > > >>>>>>>>>>> Solr projects
> > >>> >> > > >>>>>>>>>>> , that I have followed more closely.
> > >>> >> > > >>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>> Eddie
> > >>> >> > > >>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>> On Tue, Oct 4, 2016 at 6:40 PM, Michael Han <
> > >>> >> > hanm@cloudera.com
> > >>> >> > > >>>>
> > >>> >> > > >>>>>>>> wrote:
> > >>> >> > > >>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>> as long as the opening/closing/commenting all
> get
> > >>> sent
> > >>> >> to
> > >>> >> > > >>> the
> > >>> >> > > >>>>>>>>> mailing
> > >>> >> > > >>>>>>>>>>>> list or recorded in jira
> > >>> >> > > >>>>>>>>>>>> Yeah, this is my impression as well, that we need
> > to
> > >>> keep
> > >>> >> > > >>> certain
> > >>> >> > > >>>>>>>>> paper
> > >>> >> > > >>>>>>>>>>>> trail regarding activities and comments on ASF
> side
> > >>> >> (JIRA or
> > >>> >> > > >>> mail
> > >>> >> > > >>>>>>>>> list).
> > >>> >> > > >>>>>>>>>>>> Infra page said:
> > >>> >> > > >>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>> - Any Pull Request that gets opened, closed,
> > >>> reopened or
> > >>> >> > > >>>>>>>>> **commented**
> > >>> >> > > >>>>>>>>>>>> on now gets recorded on the project's mailing
> list
> > >>> >> > > >>>>>>>>>>>> - If a project has a JIRA instance, any PRs or
> > >>> >> *comments* on
> > >>> >> > > >>> PRs
> > >>> >> > > >>>>>>>>> that
> > >>> >> > > >>>>>>>>>>>> include a JIRA ticket ID will trigger an update
> on
> > >>> that
> > >>> >> > > >>> specific
> > >>> >> > > >>>>>>>>>> ticket
> > >>> >> > > >>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>> I checked a couple Kafka and Spark JIRAs but I
> > don't
> > >>> see
> > >>> >> any
> > >>> >> > > >>> of
> > >>> >> > > >>>>>>> the
> > >>> >> > > >>>>>>>>>>>> comments made in github PR were posted on JIRA,
> > >>> except
> > >>> >> the
> > >>> >> > > >>>>>>>> activities
> > >>> >> > > >>>>>>>>>> (open
> > >>> >> > > >>>>>>>>>>>> a PR, close a PR). Since both projects have been
> > >>> using
> > >>> >> > github
> > >>> >> > > >>> for
> > >>> >> > > >>>>>>> a
> > >>> >> > > >>>>>>>>>> while I
> > >>> >> > > >>>>>>>>>>>> assume such practice of NOT integrating comments
> > >>> between
> > >>> >> > > >>> github
> > >>> >> > > >>>>>>> and
> > >>> >> > > >>>>>>>>> ASF
> > >>> >> > > >>>>>>>>>>>> JIRA is acceptable? Though I feel it would be
> > really
> > >>> >> useful
> > >>> >> > if
> > >>> >> > > >>>>>>>>> comments
> > >>> >> > > >>>>>>>>>>>> could converge in a single place as well, that
> will
> > >>> >> provide
> > >>> >> > a
> > >>> >> > > >>>>>>> clear
> > >>> >> > > >>>>>>>>>> history
> > >>> >> > > >>>>>>>>>>>> for a given technical issue.
> > >>> >> > > >>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>> On Tue, Oct 4, 2016 at 12:06 PM, Flavio
> Junqueira <
> > >>> >> > > >>>> fpj@apache.org
> > >>> >> > > >>>>>>>>
> > >>> >> > > >>>>>>>>>> wrote:
> > >>> >> > > >>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>> Until ZOOKEEPER-2597 <
> https://issues.apache.org/
> > >>> >> > > >>>>>>>>>>>> jira/browse/ZOOKEEPER-2597>
> > >>> >> > > >>>>>>>>>>>>> is fixed, we can't merge via github.
> > >>> >> > > >>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>> For code reviews, we can use GH as long as the
> > >>> >> > > >>>>>>>>>> opening/closing/commenting
> > >>> >> > > >>>>>>>>>>>>> all get sent to the mailing list or recorded in
> > >>> jira. I
> > >>> >> > don't
> > >>> >> > > >>>>>>> think
> > >>> >> > > >>>>>>>>> we
> > >>> >> > > >>>>>>>>>>>> have
> > >>> >> > > >>>>>>>>>>>>> that yet, but it is possible according to this:
> > >>> >> > > >>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>> https://blogs.apache.org/infra/entry/improved_
> > >>> >> > > >>>>>>>>>>>>> integration_between_apache_and <
> > >>> >> https://blogs.apache.org/
> > >>> >> > > >>>>>>>>>>>>> infra/entry/improved_integrati
> > >>> on_between_apache_and>
> > >>> >> > > >>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>> For now, we do need to upload patches and
> converge
> > >>> using
> > >>> >> > > >>> jira.
> > >>> >> > > >>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>> I think Eddie has been looking at this process
> > >>> trying to
> > >>> >> > > >>>>>>> replicate
> > >>> >> > > >>>>>>>>> the
> > >>> >> > > >>>>>>>>>>>>> Kafka setup, so perhaps he can give an update if
> > I'm
> > >>> >> right.
> > >>> >> > > >>>> Kafka
> > >>> >> > > >>>>>>>>>> doesn't
> > >>> >> > > >>>>>>>>>>>>> send every comment to the mailing list, though,
> > but
> > >>> I'm
> > >>> >> not
> > >>> >> > > >>> sure
> > >>> >> > > >>>>>>> if
> > >>> >> > > >>>>>>>>>>>> that's
> > >>> >> > > >>>>>>>>>>>>> acceptable according to the ASF, I need to
> > >>> double-check.
> > >>> >> > > >>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>> -Flavio
> > >>> >> > > >>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>> On 04 Oct 2016, at 19:42, Michael Han <
> > >>> >> hanm@cloudera.com>
> > >>> >> > > >>>>>>> wrote:
> > >>> >> > > >>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>> Hi,
> > >>> >> > > >>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>> Now we've moved to git, what is the policy for
> > >>> >> uploading
> > >>> >> > > >>>> patches
> > >>> >> > > >>>>>>>> and
> > >>> >> > > >>>>>>>>>>>>> doing
> > >>> >> > > >>>>>>>>>>>>>> code reviews? I am asking because I've seen
> > >>> recently
> > >>> >> there
> > >>> >> > > >>> are
> > >>> >> > > >>>>>>> git
> > >>> >> > > >>>>>>>>>> pull
> > >>> >> > > >>>>>>>>>>>>>> requests coming in without associated patch
> file
> > >>> >> uploaded
> > >>> >> > to
> > >>> >> > > >>>>>>> JIRA.
> > >>> >> > > >>>>>>>>>> I've
> > >>> >> > > >>>>>>>>>>>>>> checked
> > >>> >> > > >>>>>>>>>>>>>> https://cwiki.apache.org/confl
> > >>> uence/display/ZOOKEEPER/
> > >>> >> > > >>>>>>>>> HowToContribute
> > >>> >> > > >>>>>>>>>> ,
> > >>> >> > > >>>>>>>>>>>>>> looks like there is not much change regarding
> > patch
> > >>> >> > process
> > >>> >> > > >>> -
> > >>> >> > > >>>> so
> > >>> >> > > >>>>>>>>>>>>> presumably
> > >>> >> > > >>>>>>>>>>>>>> we still need to generate and upload patch file
> > to
> > >>> JIRA
> > >>> >> > for
> > >>> >> > > >>> the
> > >>> >> > > >>>>>>>>>> record,
> > >>> >> > > >>>>>>>>>>>>>> while using github (maybe in addition of review
> > >>> board,
> > >>> >> or
> > >>> >> > in
> > >>> >> > > >>>> the
> > >>> >> > > >>>>>>>>>> future
> > >>> >> > > >>>>>>>>>>>>>> with gerrit) to do code reviews?
> > >>> >> > > >>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>> On Wed, Sep 21, 2016 at 6:05 AM, Edward
> Ribeiro <
> > >>> >> > > >>>>>>>>>>>>> edward.ribeiro@gmail.com>
> > >>> >> > > >>>>>>>>>>>>>> wrote:
> > >>> >> > > >>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>> Cool, just open https://issues.apache.org/
> > >>> >> > > >>>>>>>>> jira/browse/ZOOKEEPER-2597
> > >>> >> > > >>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>> PS: I removed the REPO_HOME global variable.
> > >>> >> > > >>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>> On Wed, Sep 21, 2016 at 6:53 AM, Flavio
> > Junqueira
> > >>> <
> > >>> >> > > >>>>>>>> fpj@apache.org>
> > >>> >> > > >>>>>>>>>>>>> wrote:
> > >>> >> > > >>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>> Better to have that in the form of a pull
> > >>> request or
> > >>> >> > diff.
> > >>> >> > > >>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>> REPO_HOME does seem to be unused.
> > >>> >> > > >>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>> -Flavio
> > >>> >> > > >>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>> On 20 Sep 2016, at 18:57, Edward Ribeiro <
> > >>> >> > > >>>>>>>>> edward.ribeiro@gmail.com
> > >>> >> > > >>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>> wrote:
> > >>> >> > > >>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>> Hey, I have started porting the
> kafka-merge.py
> > >>> to
> > >>> >> work
> > >>> >> > > >>> on ZK
> > >>> >> > > >>>>>>>>> repos.
> > >>> >> > > >>>>>>>>>>>> I
> > >>> >> > > >>>>>>>>>>>>>>>> would
> > >>> >> > > >>>>>>>>>>>>>>>>> need someone to review it and help me test
> it
> > >>> now.
> > >>> >> > > >>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>> The files were uploaded below, but I will
> > >>> create a
> > >>> >> > github
> > >>> >> > > >>>>>>> repo
> > >>> >> > > >>>>>>>>> yet
> > >>> >> > > >>>>>>>>>>>>>>> today.
> > >>> >> > > >>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>> https://www.dropbox.com/sh/od8bet2574jttm3/
> > >>> >> > > >>>>>>>>>>>>>>>> AADv1DXTb8vfyVCmelFbYCEha?dl=0
> > >>> >> > > >>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>> I uploaded the kafka version script so that
> > you
> > >>> can
> > >>> >> use
> > >>> >> > > >>> diff
> > >>> >> > > >>>>>>> or
> > >>> >> > > >>>>>>>>>> Meld
> > >>> >> > > >>>>>>>>>>>>> to
> > >>> >> > > >>>>>>>>>>>>>>>>> spot my changes, but feel free to grasp the
> > >>> original
> > >>> >> > file
> > >>> >> > > >>>>>>> here:
> > >>> >> > > >>>>>>>>>>>>>>>>> https://github.com/apache/
> > >>> >> > kafka/blob/trunk/kafka-merge-
> > >>> >> > > >>>> pr.py
> > >>> >> > > >>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>> PS: It's just me or REPO_HOME env variable
> is
> > >>> not
> > >>> >> used
> > >>> >> > > >>>>>>> anywhere
> > >>> >> > > >>>>>>>>> in
> > >>> >> > > >>>>>>>>>>>> the
> > >>> >> > > >>>>>>>>>>>>>>>>> merge script???
> > >>> >> > > >>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>> Cheers,
> > >>> >> > > >>>>>>>>>>>>>>>>> Eddie
> > >>> >> > > >>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick
> > Hunt <
> > >>> >> > > >>>>>>>> phunt@apache.org
> > >>> >> > > >>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>> wrote:
> > >>> >> > > >>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin
> > Reed
> > >>> <
> > >>> >> > > >>>>>>>>> breed@apache.org>
> > >>> >> > > >>>>>>>>>>>>>>>> wrote:
> > >>> >> > > >>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>>> what you are suggesting sounds good, but i
> > >>> don't
> > >>> >> know
> > >>> >> > > >>> how
> > >>> >> > > >>>>>>> to
> > >>> >> > > >>>>>>>> do
> > >>> >> > > >>>>>>>>>>>> it?
> > >>> >> > > >>>>>>>>>>>>>>>> since
> > >>> >> > > >>>>>>>>>>>>>>>>>>> in the end we are still just accepting
> diffs
> > >>> on
> > >>> >> > > >>> patches,
> > >>> >> > > >>>>>>> the
> > >>> >> > > >>>>>>>>> only
> > >>> >> > > >>>>>>>>>>>>>>> thing
> > >>> >> > > >>>>>>>>>>>>>>>>>>> that changes is that we use svn rather
> than
> > >>> git
> > >>> >> > right?
> > >>> >> > > >>>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>> Notice the workflow Kafka uses - which
> > includes
> > >>> >> "git
> > >>> >> > > >>> apply"
> > >>> >> > > >>>>>>>> and
> > >>> >> > > >>>>>>>>>>>>>>>> specifying
> > >>> >> > > >>>>>>>>>>>>>>>>>> the author tag when committers commit (so
> > that
> > >>> the
> > >>> >> OP
> > >>> >> > > >>> gets
> > >>> >> > > >>>>>>>>> proper
> > >>> >> > > >>>>>>>>>>>>>>>>>> attribution in the commit itself)
> > >>> >> > > >>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>> https://cwiki.apache.org/confl
> > >>> uence/display/KAFKA/
> > >>> >> > > >>>>>>>>>>>>>>>> Manual+Commit+Workflow
> > >>> >> > > >>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>> Patrick
> > >>> >> > > >>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>>> i LOVE chris's idea! lets do it!
> > >>> >> > > >>>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>>> ben
> > >>> >> > > >>>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>>> On Sun, Sep 18, 2016 at 3:22 PM, Patrick
> > Hunt
> > >>> <
> > >>> >> > > >>>>>>>>> phunt@apache.org>
> > >>> >> > > >>>>>>>>>>>>>>>> wrote:
> > >>> >> > > >>>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>>>> Ben, do you also want to update the
> > >>> "Applying a
> > >>> >> > patch"
> > >>> >> > > >>>>>>>> section
> > >>> >> > > >>>>>>>>>> to
> > >>> >> > > >>>>>>>>>>>>>>> make
> > >>> >> > > >>>>>>>>>>>>>>>>>> it
> > >>> >> > > >>>>>>>>>>>>>>>>>>>> git specific?
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>>>> We (committers) should move to a model
> > where
> > >>> >> authors
> > >>> >> > > >>> get
> > >>> >> > > >>>>>>>>> proper
> > >>> >> > > >>>>>>>>>>>>>>> credit
> > >>> >> > > >>>>>>>>>>>>>>>>>> in
> > >>> >> > > >>>>>>>>>>>>>>>>>>>> git. Our old workflow in svn resulted in
> > >>> only the
> > >>> >> > > >>>>>>> committer
> > >>> >> > > >>>>>>>>>> being
> > >>> >> > > >>>>>>>>>>>>>>>>>> listed
> > >>> >> > > >>>>>>>>>>>>>>>>>>>> (except that we listed the patch author
> in
> > >>> the
> > >>> >> > commit
> > >>> >> > > >>>>>>>>> message).
> > >>> >> > > >>>>>>>>>>>> We
> > >>> >> > > >>>>>>>>>>>>>>>>>> should
> > >>> >> > > >>>>>>>>>>>>>>>>>>>> move to a model where the author of the
> > patch
> > >>> >> gets
> > >>> >> > > >>> proper
> > >>> >> > > >>>>>>>>> credit
> > >>> >> > > >>>>>>>>>>>> in
> > >>> >> > > >>>>>>>>>>>>>>>>>> git.
> > >>> >> > > >>>>>>>>>>>>>>>>>>> I
> > >>> >> > > >>>>>>>>>>>>>>>>>>>> believe we will get that if we use git
> for
> > >>> patch
> > >>> >> > > >>>>>>>>>>>>>>> creation/application?
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>>>> Chris brought up getting rid of
> CHANGES.txt
> > >>> >> recently
> > >>> >> > > >>> on
> > >>> >> > > >>>>>>> the
> > >>> >> > > >>>>>>>>> dev
> > >>> >> > > >>>>>>>>>>>>> list
> > >>> >> > > >>>>>>>>>>>>>>>>>> in a
> > >>> >> > > >>>>>>>>>>>>>>>>>>>> separate thread - Chris do you want to
> > >>> implement
> > >>> >> > that
> > >>> >> > > >>>>>>> change
> > >>> >> > > >>>>>>>>> now
> > >>> >> > > >>>>>>>>>>>>>>> that
> > >>> >> > > >>>>>>>>>>>>>>>>>>> we've
> > >>> >> > > >>>>>>>>>>>>>>>>>>>> moved to git?
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>>>> Patrick
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>>>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin
> > >>> Reed <
> > >>> >> > > >>>>>>>>>> breed@apache.org
> > >>> >> > > >>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>> wrote:
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>>> 1) actually in the previous step that
> was
> > >>> just
> > >>> >> > > >>> adding
> > >>> >> > > >>>>>>> new
> > >>> >> > > >>>>>>>>>>>> files.
> > >>> >> > > >>>>>>>>>>>>>>> you
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>>> still
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>>>> need the commit -a for the rest of the
> > >>> >> changes.
> > >>> >> > > >>> that's
> > >>> >> > > >>>>>>> my
> > >>> >> > > >>>>>>>>>>>> normal
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>>> workflow.
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>>> I think that will be confusing for most
> > >>> folks.
> > >>> >> > They
> > >>> >> > > >>>>>>>>> typically
> > >>> >> > > >>>>>>>>>>>>>>> stage
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>>> all the changes and then commit or
> don't
> > >>> stage
> > >>> >> and
> > >>> >> > > >>> use
> > >>> >> > > >>>>>>> -a.
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>> do you mind fixing it with your
> workflow.
> > >>> >> commit -a
> > >>> >> > > >>>>>>> doesn't
> > >>> >> > > >>>>>>>>> get
> > >>> >> > > >>>>>>>>>>>>> new
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>> files, which is why you need to do the
> > add,
> > >>> but
> > >>> >> i'm
> > >>> >> > > >>> not
> > >>> >> > > >>>>>>> the
> > >>> >> > > >>>>>>>>>> most
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>> sophisticated git user, so
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>>>> 2) i figured since we are using git
> now
> > >>> that
> > >>> >> we
> > >>> >> > > >>> should
> > >>> >> > > >>>>>>>> use
> > >>> >> > > >>>>>>>>>>>> git's
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>>> default.
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>>>> the patch should work (by default it
> > >>> seems to
> > >>> >> > strip
> > >>> >> > > >>>> the
> > >>> >> > > >>>>>>>>> first
> > >>> >> > > >>>>>>>>>>>>>>> path
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>>> element).
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>>>> does it not work for you?
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>>> It will fail precommit in it's current
> > >>> state.
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>> fixed
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>> --
> > >>> >> > > >>>>>>>>>>>>>> Cheers
> > >>> >> > > >>>>>>>>>>>>>> Michael.
> > >>> >> > > >>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>>> --
> > >>> >> > > >>>>>>>>>>>> Cheers
> > >>> >> > > >>>>>>>>>>>> Michael.
> > >>> >> > > >>>>>>>>>>>>
> > >>> >> > > >>>>>>>>>>
> > >>> >> > > >>>>>>>>>>
> > >>> >> > > >>>>>>>>>
> > >>> >> > > >>>>>>>>>
> > >>> >> > > >>>>>>>>> --
> > >>> >> > > >>>>>>>>> Cheers
> > >>> >> > > >>>>>>>>> Michael.
> > >>> >> > > >>>>>>>>>
> > >>> >> > > >>>>>>>>
> > >>> >> > > >>>>>>>
> > >>> >> > > >>>>>
> > >>> >> > > >>>>>
> > >>> >> > > >>>>
> > >>> >> > > >>>>
> > >>> >> > > >>>> --
> > >>> >> > > >>>> Cheers
> > >>> >> > > >>>> Michael.
> > >>> >> > > >>>>
> > >>> >> > > >>>
> > >>> >> > > >>
> > >>> >> > > >>
> > >>> >> > > >>
> > >>> >> > > >> --
> > >>> >> > > >> Cheers
> > >>> >> > > >> Michael.
> > >>> >> > > >>
> > >>> >> > > >
> > >>> >> > > >
> > >>> >> > > >
> > >>> >> > > > --
> > >>> >> > > > Cheers
> > >>> >> > > > Michael.
> > >>> >> > >
> > >>> >> > >
> > >>> >> >
> > >>> >>
> > >>> >
> > >>>
> > >>
> > >>
> > >
> >
>

Re: [VOTE] move Apache Zookeeper to git

Posted by Edward Ribeiro <ed...@gmail.com>.

Oh, Patrick (and Flavio, and Ben Reed),

I asked some questions to one ASF committer that has been using the
Github-JIRA-Apache combo for a while now. According to him, committers
*cannot* manually close 3rd party PRs. :( He said this is a combination of
Github limitations and INFRA policies, his explanations below:

Question:  1) Do committers have to contact ASF INFRA to be able to close
PR on Github mirror? Some people created bogus PR that we would like to
close, but they don't have this option now. Can INFRA give committers the
auth to close those 3rd party PRs?

Answer: "You either have to ask INFRA, ask the author or close via a dummy
commit. In our project, we first ask the author and occasionally we ask
INFRA to close a bunch of them or a particularly bad one (someone had
created a PR for merging trunk to a stable branch, for example. That would
cause a PR build every time something was merged to trunk).

Basically, if you have write access to the PRs, you also have write access
to the GitHub repository. And INFRA believes it's essential for the GitHub
repo to be read only. The writes flow from the Apache git repo. The Apache
git repo has more safeguards (although protected branches in GitHub could
help here, not sure if the Apache INFRA team has considered them)."

Question: At Kafka, all the PR goes through GH? Or do you committers
usually apply patches directly to Apache git repo?

Answer: "We now always use GitHub, we don't use patches any more"
Edward

On Mon, Dec 5, 2016 at 9:07 PM, Patrick Hunt <ph...@apache.org> wrote:

> No problem Edward. Did you get any insight on what to do with the PR?
>
> Patrick
>
> On Thu, Nov 24, 2016 at 10:52 AM, Edward Ribeiro <edward.ribeiro@gmail.com
> >
> wrote:
>
> > Hi, Patrick,
> >
> > Thanks for merging this change. :)
> >
> > Sincerely, I don't know why it didn't close the PR automatically. Nor why
> > you can close it in the GH mirror. In any case, I manually closed it.
> >
> > I will ping folks from other Apache projects using similar tool to
> inquire
> > why it didn't close the PR and why it gave this 'write access' error
> > message.
> >
> > Edward
> >
> >
> >
> > On Fri, Nov 18, 2016 at 8:13 PM, Patrick Hunt <ph...@apache.org> wrote:
> >
> >> Thanks Edward, this should be very helpful for folks. I committed,
> >> however I notice the PR is still open. I followed the steps here:
> >> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> Committing+changes
> >> however I don't see a way to close the PR? https://github.com/apache/
> >> zookeeper/pull/103 says I don't have "write access".
> >>
> >> Patrick
> >>
> >> On Thu, Nov 10, 2016 at 10:23 AM, Edward Ribeiro <
> >> edward.ribeiro@gmail.com> wrote:
> >>
> >>> Hi Patrick,
> >>>
> >>> I've just opened a PR  https://github.com/apache/zookeeper/pull/103/
> PR
> >>>
> >>> It asks for JIRA_PASSWORD at CLI prompt *IF* it's absent but
> >>> JIRA_USERNAME
> >>> is already set. Please, when you have time, see if it fits what you
> need
> >>> and then I can open a JIRA, rename the feature branch, etc.
> >>>
> >>> Let me know if you have other ideas. I am open to other ways of
> >>> incorporating the passing of JIRA_PASSWORD too.
> >>>
> >>> Edward
> >>>
> >>> On Wed, Nov 9, 2016 at 5:03 PM, Edward Ribeiro <
> edward.ribeiro@gmail.com
> >>> >
> >>> wrote:
> >>>
> >>> > Hi Patrick,
> >>> >
> >>> > We can change the script so that it asks for jira password input on
> CLI
> >>> > prompt if the JIRA username is set, for example. The change should be
> >>> > straigthforward.
> >>> >
> >>> > Alternatively, the python systems I have dealt with put credentials
> for
> >>> > database access, etc, in configuration -- sometimes hidden -- files
> >>> (say,
> >>> > .env), but yet it is clear text stored.
> >>> >
> >>> > Anyone has other suggestions?
> >>> >
> >>> > Eddie
> >>> >
> >>> > Em 9 de nov de 2016 4:18 PM, "Patrick Hunt" <ph...@apache.org>
> >>> escreveu:
> >>> >
> >>> >> Is there any alternative to step 4 as documented here?
> >>> >> https://cwiki.apache.org/confluence/display/ZOOKEEPER/Mergin
> >>> >> g+Github+Pull+Requests
> >>> >>
> >>> >> specifically it's asking to "export JIRA_PASSWORD=mypassword" which
> I
> >>> feel
> >>> >> very uncomfortable doing.
> >>> >>
> >>> >> Patrick
> >>> >>
> >>> >> On Wed, Oct 26, 2016 at 11:12 AM, Edward Ribeiro <
> >>> >> edward.ribeiro@gmail.com>
> >>> >> wrote:
> >>> >>
> >>> >> > AFAIK, yes. I say, if you mean to run unit tests and other CI
> tasks
> >>> on
> >>> >> PR.
> >>> >> >
> >>> >> > PS: I have just created a simple script HowTo at
> >>> >> > https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> >>> >> > Merging+Github+Pull+Requests
> >>> >> > and linked from https://cwiki.apache.org/confl
> >>> uence/display/ZOOKEEPER/
> >>> >> > Index
> >>> >> >
> >>> >> > On Wed, Oct 26, 2016 at 3:59 PM, Flavio Junqueira <fpj@apache.org
> >
> >>> >> wrote:
> >>> >> >
> >>> >> > > What about QA, are we still missing a github pre-commit queue?
> >>> >> > >
> >>> >> > > -Flavio
> >>> >> > >
> >>> >> > > > On 26 Oct 2016, at 18:53, Michael Han <ha...@cloudera.com>
> >>> wrote:
> >>> >> > > >
> >>> >> > > > The comment bridging should be fixed now - see INFRA-12752 for
> >>> more
> >>> >> > > > details.
> >>> >> > > >
> >>> >> > > > On Wed, Oct 26, 2016 at 10:03 AM, Michael Han <
> >>> hanm@cloudera.com>
> >>> >> > wrote:
> >>> >> > > >
> >>> >> > > >>>> The git PR *review* comments for ZOOKEEPER-2597 didn't show
> >>> up on
> >>> >> > > JIRA.
> >>> >> > > >>
> >>> >> > > >> The bridge was working the day Infra made the change - see
> the
> >>> >> > previous
> >>> >> > > >> comments made by git bot on ZOOKEEPER-761. Now it seems stop
> >>> >> working.
> >>> >> > I
> >>> >> > > am
> >>> >> > > >> reopening INFRA-12752 and building a case.
> >>> >> > > >>
> >>> >> > > >> On Wed, Oct 26, 2016 at 9:45 AM, Edward Ribeiro <
> >>> >> > > edward.ribeiro@gmail.com>
> >>> >> > > >> wrote:
> >>> >> > > >>
> >>> >> > > >>> Dear community,
> >>> >> > > >>>
> >>> >> > > >>> The zk-merger-pr.py script has been merged into master
> >>> (thanks a
> >>> >> LOT
> >>> >> > > Ben
> >>> >> > > >>> Reed for reviewing/discussing/testing and commiting):
> >>> >> > > >>> https://issues.apache.org/jira/browse/ZOOKEEPER-2597
> >>> >> > > >>>
> >>> >> > > >>> As stated in the issue and on GH, this tool is a modified
> >>> version
> >>> >> of
> >>> >> > > >>> similar tools from Kafka, that is a copy of a Spark's one.
> It
> >>> has
> >>> >> > some
> >>> >> > > >>> rough edges so we will certainly benefit from further
> >>> enhancements
> >>> >> > and
> >>> >> > > >>> fixes. I changed the smallest possible pieces of code, just
> to
> >>> >> make
> >>> >> > it
> >>> >> > > >>> work
> >>> >> > > >>> on a ZK repo so the credits go to the original authors.
> >>> >> > > >>>
> >>> >> > > >>> Some notes:
> >>> >> > > >>>
> >>> >> > > >>> 1. The git PR *review* comments for ZOOKEEPER-2597 didn't
> >>> show up
> >>> >> on
> >>> >> > > JIRA.
> >>> >> > > >>> Only the opening and closing of the issue. Can we double
> check
> >>> >> this
> >>> >> > as
> >>> >> > > >>> INFRA-12752 is closed, Michael Han?
> >>> >> > > >>>
> >>> >> > > >>> 2. I scribbled a draft on how use the tool at
> >>> >> > > >>> https://docs.google.com/document/d/1i00ZXjrW2fu17vr_
> h7F1bUrq
> >>> >> > > >>> Xg3urw4Hm7KirQDpPIU/edit
> >>> >> > > >>> (still very crude, but feel free to improve it). I would
> like
> >>> to
> >>> >> move
> >>> >> > > >>> this
> >>> >> > > >>> text to https://cwiki.apache.org/confl
> >>> >> uence/display/ZOOKEEPER/Index
> >>> >> > > but
> >>> >> > > >>> looks like I don't have permission to create a page there
> >>> yet. Any
> >>> >> > > help?
> >>> >> > > >>>
> >>> >> > > >>> Best regards,
> >>> >> > > >>> Eddie
> >>> >> > > >>>
> >>> >> > > >>> On Sat, Oct 22, 2016 at 7:08 PM, Michael Han <
> >>> hanm@cloudera.com>
> >>> >> > > wrote:
> >>> >> > > >>>
> >>> >> > > >>>> FYI infra did some work in INFRA-12752 and the git PR
> >>> comments
> >>> >> can
> >>> >> > be
> >>> >> > > >>>> pushed to Apache JIRA.
> >>> >> > > >>>>
> >>> >> > > >>>> On Sat, Oct 8, 2016 at 8:01 AM, Flavio Junqueira <
> >>> fpj@apache.org
> >>> >> >
> >>> >> > > >>> wrote:
> >>> >> > > >>>>
> >>> >> > > >>>>> This is not supported at the moment if nothing has
> changed:
> >>> >> > > >>>>>
> >>> >> > > >>>>> https://issues.apache.org/jira/browse/INFRA-11000 <
> >>> >> > > >>>>> https://issues.apache.org/jira/browse/INFRA-11000>
> >>> >> > > >>>>>
> >>> >> > > >>>>> -Flavio
> >>> >> > > >>>>>
> >>> >> > > >>>>>> On 08 Oct 2016, at 00:54, Benjamin Reed <
> breed@apache.org>
> >>> >> wrote:
> >>> >> > > >>>>>>
> >>> >> > > >>>>>> it doesn't look like we need to setup keys. this seems to
> >>> work
> >>> >> for
> >>> >> > > >>> me:
> >>> >> > > >>>>>>
> >>> >> > > >>>>>> https://git-wip-us.apache.org/
> #committers-getting-started
> >>> >> > > >>>>>>
> >>> >> > > >>>>>> it does seem strange that we aren't using public keys and
> >>> that
> >>> >> i'm
> >>> >> > > >>>>> sticking
> >>> >> > > >>>>>> a password in .netrc :P i'm wondering if other projects
> >>> were
> >>> >> able
> >>> >> > to
> >>> >> > > >>>> get
> >>> >> > > >>>>>> this going over ssh.
> >>> >> > > >>>>>>
> >>> >> > > >>>>>> i'll take a whack at cleaning up the svn and subversion
> >>> >> > references.
> >>> >> > > >>>>>>
> >>> >> > > >>>>>> ben
> >>> >> > > >>>>>>
> >>> >> > > >>>>>> On Fri, Oct 7, 2016 at 12:59 PM, Camille Fournier <
> >>> >> > > >>> camille@apache.org>
> >>> >> > > >>>>>> wrote:
> >>> >> > > >>>>>>
> >>> >> > > >>>>>>> Hey folks,
> >>> >> > > >>>>>>>
> >>> >> > > >>>>>>> So I'm trying to get in a patch but this has not been
> >>> updated
> >>> >> to
> >>> >> > > >>> tell
> >>> >> > > >>>>>>> committers how to actually get the git keys set up:
> >>> >> > > >>>>>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> >>> >> > > >>>>> Committing+changes
> >>> >> > > >>>>>>>
> >>> >> > > >>>>>>> Can someone float me a link that says how to do this?
> >>> >> > > >>>>>>>
> >>> >> > > >>>>>>> Also a bunch of our documentation still discusses SVN
> and
> >>> not
> >>> >> > git,
> >>> >> > > >>>> which
> >>> >> > > >>>>>>> means we are not done with this migration. If you were
> >>> pushing
> >>> >> > for
> >>> >> > > >>>> this
> >>> >> > > >>>>>>> change can you please do some due diligence on the wikis
> >>> and
> >>> >> > > >>> correct
> >>> >> > > >>>> the
> >>> >> > > >>>>>>> stuff that refers to SVN?
> >>> >> > > >>>>>>>
> >>> >> > > >>>>>>> Thanks,
> >>> >> > > >>>>>>> C
> >>> >> > > >>>>>>>
> >>> >> > > >>>>>>> On Wed, Oct 5, 2016 at 1:02 PM, Edward Ribeiro <
> >>> >> > > >>>>> edward.ribeiro@gmail.com>
> >>> >> > > >>>>>>> wrote:
> >>> >> > > >>>>>>>
> >>> >> > > >>>>>>>> Excuse me guys!
> >>> >> > > >>>>>>>>
> >>> >> > > >>>>>>>> I've written on Macbook Pro. No idea why GMail messed
> it
> >>> up.
> >>> >> I
> >>> >> > was
> >>> >> > > >>>> only
> >>> >> > > >>>>>>>> able to see the strange characters when I pasted on a
> >>> gist
> >>> >> text
> >>> >> > > >>> area.
> >>> >> > > >>>>> The
> >>> >> > > >>>>>>>> previous message is below, but if anyone is still
> having
> >>> >> trouble
> >>> >> > > >>> (I
> >>> >> > > >>>>> tried
> >>> >> > > >>>>>>>> to remove the weird character), I left a copy at:
> >>> >> > > >>>>>>>> https://gist.github.com/eribei
> >>> ro/da2a6a6c9a508610d52d0755fae
> >>> >> 835
> >>> >> > 2d
> >>> >> > > >>>>>>>>
> >>> >> > > >>>>>>>> "Hi,
> >>> >> > > >>>>>>>>
> >>> >> > > >>>>>>>> The patch attached on ZOOKEEPER-2597 is a
> straightforward
> >>> >> > > >>> adaptation
> >>> >> > > >>>> of
> >>> >> > > >>>>>>>> Kafka's one. It takes care of merging Github PR into
> >>> Apache
> >>> >> git
> >>> >> > > >>> repo
> >>> >> > > >>>>> and
> >>> >> > > >>>>>>> a
> >>> >> > > >>>>>>>> subsequent closing of the PR on the GH side, among
> other
> >>> >> things
> >>> >> > > >>>>>>> (rewriting
> >>> >> > > >>>>>>>> of commit messages, etc). The current status is: the
> >>> script
> >>> >> > needs
> >>> >> > > >>> to
> >>> >> > > >>>> be
> >>> >> > > >>>>>>>> reviewed/validated by a committer. It has been some
> time
> >>> >> since I
> >>> >> > > >>>>> uploaded
> >>> >> > > >>>>>>>> the patch, so I gonna do another pass through it in the
> >>> >> > meantime.
> >>> >> > > >>>>>>>>
> >>> >> > > >>>>>>>> There are some workflow issues beyond the scope of
> >>> >> > ZOOKEEPER-2597
> >>> >> > > >>>> that
> >>> >> > > >>>>>>> need
> >>> >> > > >>>>>>>> to be sorted out (IMO):
> >>> >> > > >>>>>>>>
> >>> >> > > >>>>>>>> 1. The normal workflow is to open a JIRA ticket before
> >>> doing
> >>> >> any
> >>> >> > > >>> GH
> >>> >> > > >>>> PR,
> >>> >> > > >>>>>>>> that is, no JIRA-less PRs. The PR should have a title
> of
> >>> the
> >>> >> > form
> >>> >> > > >>>>>>>> "ZOOKEEPER-xxxx: Title". This will trigger the Apache
> >>> >> > JIRA-Github
> >>> >> > > >>>>>>>> integration and it's opening show up in the JIRA
> ticket.
> >>> >> > > >>>>>>>>
> >>> >> > > >>>>>>>> 2. OTOH, not every Kafka PR needs a corresponding JIRA
> >>> >> ticket.
> >>> >> > > >>> There
> >>> >> > > >>>>> are
> >>> >> > > >>>>>>> a
> >>> >> > > >>>>>>>> class of PRs with "MINOR" title that represent trivial
> >>> code
> >>> >> > > >>> changes
> >>> >> > > >>>> and
> >>> >> > > >>>>>>>> "HOT-FIX" title that fix urgent, but simple bugs. Both
> >>> bypass
> >>> >> > the
> >>> >> > > >>>> JIRA
> >>> >> > > >>>>>>>> creation step, even tough they are still subject to
> >>> review.
> >>> >> It's
> >>> >> > > >>>> worth
> >>> >> > > >>>>>>>> adopting a similar approach for ZK project?
> >>> >> > > >>>>>>>>
> >>> >> > > >>>>>>>> 3. IIRC (didn't find any page to confirm), Cassandra
> >>> project
> >>> >> > > >>>>> encourages,
> >>> >> > > >>>>>>>> but not demands, that contributors also upload a patch
> >>> file
> >>> >> to
> >>> >> > > >>> JIRA
> >>> >> > > >>>>> even
> >>> >> > > >>>>>>> in
> >>> >> > > >>>>>>>> the case of a GH PR (as to leave a audit trail, I
> guess).
> >>> >> Or, at
> >>> >> > > >>>>> least,
> >>> >> > > >>>>>>> C*
> >>> >> > > >>>>>>>> project leaves up to the contributors to either open a
> >>> GH PR
> >>> >> or
> >>> >> > > >>>> upload
> >>> >> > > >>>>>>> the
> >>> >> > > >>>>>>>> patch file to JIRA.
> >>> >> > > >>>>>>>>
> >>> >> > > >>>>>>>>
> >>> >> > > >>>>>>>> +1 about having a 'paper trail' of review comments on
> >>> JIRA
> >>> >> > and/or
> >>> >> > > >>>>> mailing
> >>> >> > > >>>>>>>> list (I would prefer the mailing list tbh). But as
> >>> Michael
> >>> >> and
> >>> >> > > >>> Flavio
> >>> >> > > >>>>>>>> pointed out, I never seen GH PR review **comments**
> being
> >>> >> > written
> >>> >> > > >>>> back
> >>> >> > > >>>>> to
> >>> >> > > >>>>>>>> JIRA, at least not in Kafka, Cassandra or Solr
> projects,
> >>> >> that I
> >>> >> > > >>> have
> >>> >> > > >>>>>>>> followed more closely.
> >>> >> > > >>>>>>>>
> >>> >> > > >>>>>>>> Eddie"
> >>> >> > > >>>>>>>>
> >>> >> > > >>>>>>>>
> >>> >> > > >>>>>>>> On Wed, Oct 5, 2016 at 1:35 PM, Michael Han <
> >>> >> hanm@cloudera.com>
> >>> >> > > >>>> wrote:
> >>> >> > > >>>>>>>>
> >>> >> > > >>>>>>>>> Eddie's mail contains lots of '=E2=80=8B'' which is
> >>> unicode
> >>> >> > > >>>> character
> >>> >> > > >>>>>>>>> zero-width space, which might cause parsing trouble
> for
> >>> some
> >>> >> > mail
> >>> >> > > >>>>>>>> clients.
> >>> >> > > >>>>>>>>>
> >>> >> > > >>>>>>>>> On Wed, Oct 5, 2016 at 6:42 AM, Flavio Junqueira <
> >>> >> > fpj@apache.org
> >>> >> > > >>>>
> >>> >> > > >>>>>>> wrote:
> >>> >> > > >>>>>>>>>
> >>> >> > > >>>>>>>>>> Dude, I'm just not able to parse your e-mail, did you
> >>> write
> >>> >> > that
> >>> >> > > >>>> on a
> >>> >> > > >>>>>>>>>> phone or something?
> >>> >> > > >>>>>>>>>>
> >>> >> > > >>>>>>>>>> -Flavio
> >>> >> > > >>>>>>>>>>
> >>> >> > > >>>>>>>>>>> On 05 Oct 2016, at 03:54, Edward Ribeiro <
> >>> >> > > >>>> edward.ribeiro@gmail.com
> >>> >> > > >>>>>>>>
> >>> >> > > >>>>>>>>>> wrote:
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>> Hi,
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>> The patch attached on ZOOKEEPER-2597 is a
> >>> >> > > >>>>>>>>>>> straightforward adaptation of
> >>> >> > > >>>>>>>>>>> Kafka's one. It takes care of merging Github PR into
> >>> >> Apache
> >>> >> > git
> >>> >> > > >>>>>>> repo
> >>> >> > > >>>>>>>>> and
> >>> >> > > >>>>>>>>>>>  a
> >>> >> > > >>>>>>>>>>> subsequent closing of the PR on the GH side
> >>> >> > > >>>>>>>>>>>  among other things (rewriting of commit messages,
> >>> etc)
> >>> >> > > >>>>>>>>>>> . The current status is: the script needs to be
> >>> >> > > >>> reviewed/validated
> >>> >> > > >>>>>>>> by a
> >>> >> > > >>>>>>>>>>> committer.
> >>> >> > > >>>>>>>>>>> It has been some time since I uploaded the patch,
> so
> >>> I
> >>> >> gonna
> >>> >> > > >>> do
> >>> >> > > >>>>>>>>> another
> >>> >> > > >>>>>>>>>>> pass through it in the meantime.
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>> T
> >>> >> > > >>>>>>>>>>> here are some workflow issues beyond the scope of
> >>> >> > > >>> ZOOKEEPER-2597
> >>> >> > > >>>>>>>>>>>  that need to be sorted out (IMO)
> >>> >> > > >>>>>>>>>>> :
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>> 1. The normal workflow is to open a JIRA ticket
> before
> >>> >> doing
> >>> >> > > >>> any
> >>> >> > > >>>> GH
> >>> >> > > >>>>>>>> PR
> >>> >> > > >>>>>>>>>>> , that is, no JIRA-less PRs.
> >>> >> > > >>>>>>>>>>> The PR should have a title of the form
> >>> "ZOOKEEPER-xxxx:
> >>> >> > Title".
> >>> >> > > >>>>>>> This
> >>> >> > > >>>>>>>>> will
> >>> >> > > >>>>>>>>>>> trigger the Apache JIRA-Github integration and it's
> >>> >> opening
> >>> >> > > >>> show
> >>> >> > > >>>> up
> >>> >> > > >>>>>>>> in
> >>> >> > > >>>>>>>>>> the
> >>> >> > > >>>>>>>>>>> JIRA ticket.
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>> 2.
> >>> >> > > >>>>>>>>>>> OTOH, n
> >>> >> > > >>>>>>>>>>> ot every Kafka PR needs a corresponding JIRA ticket
> >>> >> > > >>>>>>>>>>> . 
> >>> >> > > >>>>>>>>>>> There are a class of PR
> >>> >> > > >>>>>>>>>>> s
> >>> >> > > >>>>>>>>>>> with "MINOR"
> >>> >> > > >>>>>>>>>>>  title
> >>> >> > > >>>>>>>>>>> that represent trivial code changes
> >>> >> > > >>>>>>>>>>>  and "HOT-FIX" title that fix urgent, but simple
> >>> bugs.
> >>> >> Both
> >>> >> > > >>>>>>>>>>> bypass the JIRA creation step
> >>> >> > > >>>>>>>>>>> , even tough they are still 
> >>> >> > > >>>>>>>>>>> subject to review
> >>> >> > > >>>>>>>>>>> .
> >>> >> > > >>>>>>>>>>> It's worth adopting a similar approach for ZK
> project?
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>> 3. IIRC
> >>> >> > > >>>>>>>>>>>  (didn't find any page to confirm)
> >>> >> > > >>>>>>>>>>> , Cassandra project encourages, but not demands,
> that
> >>> >> > > >>> contributors
> >>> >> > > >>>>>>>> also
> >>> >> > > >>>>>>>>>>> upload a patch file to JIRA even in the case of a GH
> >>> PR
> >>> >> > > >>>>>>>>>>>  (as to leave a audit trail, I guess)
> >>> >> > > >>>>>>>>>>> .
> >>> >> > > >>>>>>>>>>> Or
> >>> >> > > >>>>>>>>>>> ,
> >>> >> > > >>>>>>>>>>> at
> >>> >> > > >>>>>>>>>>>  
> >>> >> > > >>>>>>>>>>> least
> >>> >> > > >>>>>>>>>>> ,
> >>> >> > > >>>>>>>>>>> C* project 
> >>> >> > > >>>>>>>>>>> leave
> >>> >> > > >>>>>>>>>>> s
> >>> >> > > >>>>>>>>>>> up to the contributor
> >>> >> > > >>>>>>>>>>> s
> >>> >> > > >>>>>>>>>>> to either open a GH PR or upload the patch file
> >>> >> > > >>>>>>>>>>>  to JIRA. In fact, Github allows the access to a
> raw
> >>> >> patch
> >>> >> > or
> >>> >> > > >>>>>>> diff,
> >>> >> > > >>>>>>>>> it's
> >>> >> > > >>>>>>>>>>> just a matter of adding the ".patch" or ".diff"
> >>> suffix to
> >>> >> the
> >>> >> > > >>> end
> >>> >> > > >>>>>>> of
> >>> >> > > >>>>>>>>> the
> >>> >> > > >>>>>>>>>>> Pull Request URL.
> >>> >> > > >>>>>>>>>>> 
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>> +1 about having a 'paper trail'
> >>> >> > > >>>>>>>>>>>  of review comments
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>> o
> >>> >> > > >>>>>>>>>>> n JIRA and
> >>> >> > > >>>>>>>>>>> /or
> >>> >> > > >>>>>>>>>>> mailing list (I
> >>> >> > > >>>>>>>>>>>  would
> >>> >> > > >>>>>>>>>>> prefer the mailing list tbh). But as Michael and
> >>> Flavio
> >>> >> > pointed
> >>> >> > > >>>>>>> out,
> >>> >> > > >>>>>>>> I
> >>> >> > > >>>>>>>>>>> never seen
> >>> >> > > >>>>>>>>>>> GH 
> >>> >> > > >>>>>>>>>>> PR review
> >>> >> > > >>>>>>>>>>> **
> >>> >> > > >>>>>>>>>>> comments
> >>> >> > > >>>>>>>>>>> **
> >>> >> > > >>>>>>>>>>> being written back to JIRA, at least not in Kafka,
> >>> >> Cassandra
> >>> >> > > >>>>>>>>>>> or
> >>> >> > > >>>>>>>>>>> Solr projects
> >>> >> > > >>>>>>>>>>> , that I have followed more closely.
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>> Eddie
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>> On Tue, Oct 4, 2016 at 6:40 PM, Michael Han <
> >>> >> > hanm@cloudera.com
> >>> >> > > >>>>
> >>> >> > > >>>>>>>> wrote:
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>> as long as the opening/closing/commenting all get
> >>> sent
> >>> >> to
> >>> >> > > >>> the
> >>> >> > > >>>>>>>>> mailing
> >>> >> > > >>>>>>>>>>>> list or recorded in jira
> >>> >> > > >>>>>>>>>>>> Yeah, this is my impression as well, that we need
> to
> >>> keep
> >>> >> > > >>> certain
> >>> >> > > >>>>>>>>> paper
> >>> >> > > >>>>>>>>>>>> trail regarding activities and comments on ASF side
> >>> >> (JIRA or
> >>> >> > > >>> mail
> >>> >> > > >>>>>>>>> list).
> >>> >> > > >>>>>>>>>>>> Infra page said:
> >>> >> > > >>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>> - Any Pull Request that gets opened, closed,
> >>> reopened or
> >>> >> > > >>>>>>>>> **commented**
> >>> >> > > >>>>>>>>>>>> on now gets recorded on the project's mailing list
> >>> >> > > >>>>>>>>>>>> - If a project has a JIRA instance, any PRs or
> >>> >> *comments* on
> >>> >> > > >>> PRs
> >>> >> > > >>>>>>>>> that
> >>> >> > > >>>>>>>>>>>> include a JIRA ticket ID will trigger an update on
> >>> that
> >>> >> > > >>> specific
> >>> >> > > >>>>>>>>>> ticket
> >>> >> > > >>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>> I checked a couple Kafka and Spark JIRAs but I
> don't
> >>> see
> >>> >> any
> >>> >> > > >>> of
> >>> >> > > >>>>>>> the
> >>> >> > > >>>>>>>>>>>> comments made in github PR were posted on JIRA,
> >>> except
> >>> >> the
> >>> >> > > >>>>>>>> activities
> >>> >> > > >>>>>>>>>> (open
> >>> >> > > >>>>>>>>>>>> a PR, close a PR). Since both projects have been
> >>> using
> >>> >> > github
> >>> >> > > >>> for
> >>> >> > > >>>>>>> a
> >>> >> > > >>>>>>>>>> while I
> >>> >> > > >>>>>>>>>>>> assume such practice of NOT integrating comments
> >>> between
> >>> >> > > >>> github
> >>> >> > > >>>>>>> and
> >>> >> > > >>>>>>>>> ASF
> >>> >> > > >>>>>>>>>>>> JIRA is acceptable? Though I feel it would be
> really
> >>> >> useful
> >>> >> > if
> >>> >> > > >>>>>>>>> comments
> >>> >> > > >>>>>>>>>>>> could converge in a single place as well, that will
> >>> >> provide
> >>> >> > a
> >>> >> > > >>>>>>> clear
> >>> >> > > >>>>>>>>>> history
> >>> >> > > >>>>>>>>>>>> for a given technical issue.
> >>> >> > > >>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>> On Tue, Oct 4, 2016 at 12:06 PM, Flavio Junqueira <
> >>> >> > > >>>> fpj@apache.org
> >>> >> > > >>>>>>>>
> >>> >> > > >>>>>>>>>> wrote:
> >>> >> > > >>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>> Until ZOOKEEPER-2597 <https://issues.apache.org/
> >>> >> > > >>>>>>>>>>>> jira/browse/ZOOKEEPER-2597>
> >>> >> > > >>>>>>>>>>>>> is fixed, we can't merge via github.
> >>> >> > > >>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>> For code reviews, we can use GH as long as the
> >>> >> > > >>>>>>>>>> opening/closing/commenting
> >>> >> > > >>>>>>>>>>>>> all get sent to the mailing list or recorded in
> >>> jira. I
> >>> >> > don't
> >>> >> > > >>>>>>> think
> >>> >> > > >>>>>>>>> we
> >>> >> > > >>>>>>>>>>>> have
> >>> >> > > >>>>>>>>>>>>> that yet, but it is possible according to this:
> >>> >> > > >>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>> https://blogs.apache.org/infra/entry/improved_
> >>> >> > > >>>>>>>>>>>>> integration_between_apache_and <
> >>> >> https://blogs.apache.org/
> >>> >> > > >>>>>>>>>>>>> infra/entry/improved_integrati
> >>> on_between_apache_and>
> >>> >> > > >>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>> For now, we do need to upload patches and converge
> >>> using
> >>> >> > > >>> jira.
> >>> >> > > >>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>> I think Eddie has been looking at this process
> >>> trying to
> >>> >> > > >>>>>>> replicate
> >>> >> > > >>>>>>>>> the
> >>> >> > > >>>>>>>>>>>>> Kafka setup, so perhaps he can give an update if
> I'm
> >>> >> right.
> >>> >> > > >>>> Kafka
> >>> >> > > >>>>>>>>>> doesn't
> >>> >> > > >>>>>>>>>>>>> send every comment to the mailing list, though,
> but
> >>> I'm
> >>> >> not
> >>> >> > > >>> sure
> >>> >> > > >>>>>>> if
> >>> >> > > >>>>>>>>>>>> that's
> >>> >> > > >>>>>>>>>>>>> acceptable according to the ASF, I need to
> >>> double-check.
> >>> >> > > >>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>> -Flavio
> >>> >> > > >>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>> On 04 Oct 2016, at 19:42, Michael Han <
> >>> >> hanm@cloudera.com>
> >>> >> > > >>>>>>> wrote:
> >>> >> > > >>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>> Hi,
> >>> >> > > >>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>> Now we've moved to git, what is the policy for
> >>> >> uploading
> >>> >> > > >>>> patches
> >>> >> > > >>>>>>>> and
> >>> >> > > >>>>>>>>>>>>> doing
> >>> >> > > >>>>>>>>>>>>>> code reviews? I am asking because I've seen
> >>> recently
> >>> >> there
> >>> >> > > >>> are
> >>> >> > > >>>>>>> git
> >>> >> > > >>>>>>>>>> pull
> >>> >> > > >>>>>>>>>>>>>> requests coming in without associated patch file
> >>> >> uploaded
> >>> >> > to
> >>> >> > > >>>>>>> JIRA.
> >>> >> > > >>>>>>>>>> I've
> >>> >> > > >>>>>>>>>>>>>> checked
> >>> >> > > >>>>>>>>>>>>>> https://cwiki.apache.org/confl
> >>> uence/display/ZOOKEEPER/
> >>> >> > > >>>>>>>>> HowToContribute
> >>> >> > > >>>>>>>>>> ,
> >>> >> > > >>>>>>>>>>>>>> looks like there is not much change regarding
> patch
> >>> >> > process
> >>> >> > > >>> -
> >>> >> > > >>>> so
> >>> >> > > >>>>>>>>>>>>> presumably
> >>> >> > > >>>>>>>>>>>>>> we still need to generate and upload patch file
> to
> >>> JIRA
> >>> >> > for
> >>> >> > > >>> the
> >>> >> > > >>>>>>>>>> record,
> >>> >> > > >>>>>>>>>>>>>> while using github (maybe in addition of review
> >>> board,
> >>> >> or
> >>> >> > in
> >>> >> > > >>>> the
> >>> >> > > >>>>>>>>>> future
> >>> >> > > >>>>>>>>>>>>>> with gerrit) to do code reviews?
> >>> >> > > >>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>> On Wed, Sep 21, 2016 at 6:05 AM, Edward Ribeiro <
> >>> >> > > >>>>>>>>>>>>> edward.ribeiro@gmail.com>
> >>> >> > > >>>>>>>>>>>>>> wrote:
> >>> >> > > >>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>> Cool, just open https://issues.apache.org/
> >>> >> > > >>>>>>>>> jira/browse/ZOOKEEPER-2597
> >>> >> > > >>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>> PS: I removed the REPO_HOME global variable.
> >>> >> > > >>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>> On Wed, Sep 21, 2016 at 6:53 AM, Flavio
> Junqueira
> >>> <
> >>> >> > > >>>>>>>> fpj@apache.org>
> >>> >> > > >>>>>>>>>>>>> wrote:
> >>> >> > > >>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>> Better to have that in the form of a pull
> >>> request or
> >>> >> > diff.
> >>> >> > > >>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>> REPO_HOME does seem to be unused.
> >>> >> > > >>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>> -Flavio
> >>> >> > > >>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>> On 20 Sep 2016, at 18:57, Edward Ribeiro <
> >>> >> > > >>>>>>>>> edward.ribeiro@gmail.com
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>> wrote:
> >>> >> > > >>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>> Hey, I have started porting the kafka-merge.py
> >>> to
> >>> >> work
> >>> >> > > >>> on ZK
> >>> >> > > >>>>>>>>> repos.
> >>> >> > > >>>>>>>>>>>> I
> >>> >> > > >>>>>>>>>>>>>>>> would
> >>> >> > > >>>>>>>>>>>>>>>>> need someone to review it and help me test it
> >>> now.
> >>> >> > > >>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>> The files were uploaded below, but I will
> >>> create a
> >>> >> > github
> >>> >> > > >>>>>>> repo
> >>> >> > > >>>>>>>>> yet
> >>> >> > > >>>>>>>>>>>>>>> today.
> >>> >> > > >>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>> https://www.dropbox.com/sh/od8bet2574jttm3/
> >>> >> > > >>>>>>>>>>>>>>>> AADv1DXTb8vfyVCmelFbYCEha?dl=0
> >>> >> > > >>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>> I uploaded the kafka version script so that
> you
> >>> can
> >>> >> use
> >>> >> > > >>> diff
> >>> >> > > >>>>>>> or
> >>> >> > > >>>>>>>>>> Meld
> >>> >> > > >>>>>>>>>>>>> to
> >>> >> > > >>>>>>>>>>>>>>>>> spot my changes, but feel free to grasp the
> >>> original
> >>> >> > file
> >>> >> > > >>>>>>> here:
> >>> >> > > >>>>>>>>>>>>>>>>> https://github.com/apache/
> >>> >> > kafka/blob/trunk/kafka-merge-
> >>> >> > > >>>> pr.py
> >>> >> > > >>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>> PS: It's just me or REPO_HOME env variable is
> >>> not
> >>> >> used
> >>> >> > > >>>>>>> anywhere
> >>> >> > > >>>>>>>>> in
> >>> >> > > >>>>>>>>>>>> the
> >>> >> > > >>>>>>>>>>>>>>>>> merge script???
> >>> >> > > >>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>> Cheers,
> >>> >> > > >>>>>>>>>>>>>>>>> Eddie
> >>> >> > > >>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick
> Hunt <
> >>> >> > > >>>>>>>> phunt@apache.org
> >>> >> > > >>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>> wrote:
> >>> >> > > >>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin
> Reed
> >>> <
> >>> >> > > >>>>>>>>> breed@apache.org>
> >>> >> > > >>>>>>>>>>>>>>>> wrote:
> >>> >> > > >>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>> what you are suggesting sounds good, but i
> >>> don't
> >>> >> know
> >>> >> > > >>> how
> >>> >> > > >>>>>>> to
> >>> >> > > >>>>>>>> do
> >>> >> > > >>>>>>>>>>>> it?
> >>> >> > > >>>>>>>>>>>>>>>> since
> >>> >> > > >>>>>>>>>>>>>>>>>>> in the end we are still just accepting diffs
> >>> on
> >>> >> > > >>> patches,
> >>> >> > > >>>>>>> the
> >>> >> > > >>>>>>>>> only
> >>> >> > > >>>>>>>>>>>>>>> thing
> >>> >> > > >>>>>>>>>>>>>>>>>>> that changes is that we use svn rather than
> >>> git
> >>> >> > right?
> >>> >> > > >>>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>> Notice the workflow Kafka uses - which
> includes
> >>> >> "git
> >>> >> > > >>> apply"
> >>> >> > > >>>>>>>> and
> >>> >> > > >>>>>>>>>>>>>>>> specifying
> >>> >> > > >>>>>>>>>>>>>>>>>> the author tag when committers commit (so
> that
> >>> the
> >>> >> OP
> >>> >> > > >>> gets
> >>> >> > > >>>>>>>>> proper
> >>> >> > > >>>>>>>>>>>>>>>>>> attribution in the commit itself)
> >>> >> > > >>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>> https://cwiki.apache.org/confl
> >>> uence/display/KAFKA/
> >>> >> > > >>>>>>>>>>>>>>>> Manual+Commit+Workflow
> >>> >> > > >>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>> Patrick
> >>> >> > > >>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>> i LOVE chris's idea! lets do it!
> >>> >> > > >>>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>> ben
> >>> >> > > >>>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>> On Sun, Sep 18, 2016 at 3:22 PM, Patrick
> Hunt
> >>> <
> >>> >> > > >>>>>>>>> phunt@apache.org>
> >>> >> > > >>>>>>>>>>>>>>>> wrote:
> >>> >> > > >>>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>>> Ben, do you also want to update the
> >>> "Applying a
> >>> >> > patch"
> >>> >> > > >>>>>>>> section
> >>> >> > > >>>>>>>>>> to
> >>> >> > > >>>>>>>>>>>>>>> make
> >>> >> > > >>>>>>>>>>>>>>>>>> it
> >>> >> > > >>>>>>>>>>>>>>>>>>>> git specific?
> >>> >> > > >>>>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>>> We (committers) should move to a model
> where
> >>> >> authors
> >>> >> > > >>> get
> >>> >> > > >>>>>>>>> proper
> >>> >> > > >>>>>>>>>>>>>>> credit
> >>> >> > > >>>>>>>>>>>>>>>>>> in
> >>> >> > > >>>>>>>>>>>>>>>>>>>> git. Our old workflow in svn resulted in
> >>> only the
> >>> >> > > >>>>>>> committer
> >>> >> > > >>>>>>>>>> being
> >>> >> > > >>>>>>>>>>>>>>>>>> listed
> >>> >> > > >>>>>>>>>>>>>>>>>>>> (except that we listed the patch author in
> >>> the
> >>> >> > commit
> >>> >> > > >>>>>>>>> message).
> >>> >> > > >>>>>>>>>>>> We
> >>> >> > > >>>>>>>>>>>>>>>>>> should
> >>> >> > > >>>>>>>>>>>>>>>>>>>> move to a model where the author of the
> patch
> >>> >> gets
> >>> >> > > >>> proper
> >>> >> > > >>>>>>>>> credit
> >>> >> > > >>>>>>>>>>>> in
> >>> >> > > >>>>>>>>>>>>>>>>>> git.
> >>> >> > > >>>>>>>>>>>>>>>>>>> I
> >>> >> > > >>>>>>>>>>>>>>>>>>>> believe we will get that if we use git for
> >>> patch
> >>> >> > > >>>>>>>>>>>>>>> creation/application?
> >>> >> > > >>>>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>>> Chris brought up getting rid of CHANGES.txt
> >>> >> recently
> >>> >> > > >>> on
> >>> >> > > >>>>>>> the
> >>> >> > > >>>>>>>>> dev
> >>> >> > > >>>>>>>>>>>>> list
> >>> >> > > >>>>>>>>>>>>>>>>>> in a
> >>> >> > > >>>>>>>>>>>>>>>>>>>> separate thread - Chris do you want to
> >>> implement
> >>> >> > that
> >>> >> > > >>>>>>> change
> >>> >> > > >>>>>>>>> now
> >>> >> > > >>>>>>>>>>>>>>> that
> >>> >> > > >>>>>>>>>>>>>>>>>>> we've
> >>> >> > > >>>>>>>>>>>>>>>>>>>> moved to git?
> >>> >> > > >>>>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>>> Patrick
> >>> >> > > >>>>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin
> >>> Reed <
> >>> >> > > >>>>>>>>>> breed@apache.org
> >>> >> > > >>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>> wrote:
> >>> >> > > >>>>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>>>>> 1) actually in the previous step that was
> >>> just
> >>> >> > > >>> adding
> >>> >> > > >>>>>>> new
> >>> >> > > >>>>>>>>>>>> files.
> >>> >> > > >>>>>>>>>>>>>>> you
> >>> >> > > >>>>>>>>>>>>>>>>>>>>>> still
> >>> >> > > >>>>>>>>>>>>>>>>>>>>>>> need the commit -a for the rest of the
> >>> >> changes.
> >>> >> > > >>> that's
> >>> >> > > >>>>>>> my
> >>> >> > > >>>>>>>>>>>> normal
> >>> >> > > >>>>>>>>>>>>>>>>>>>>>> workflow.
> >>> >> > > >>>>>>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>>>>> I think that will be confusing for most
> >>> folks.
> >>> >> > They
> >>> >> > > >>>>>>>>> typically
> >>> >> > > >>>>>>>>>>>>>>> stage
> >>> >> > > >>>>>>>>>>>>>>>>>>>>>> all the changes and then commit or don't
> >>> stage
> >>> >> and
> >>> >> > > >>> use
> >>> >> > > >>>>>>> -a.
> >>> >> > > >>>>>>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>>>> do you mind fixing it with your workflow.
> >>> >> commit -a
> >>> >> > > >>>>>>> doesn't
> >>> >> > > >>>>>>>>> get
> >>> >> > > >>>>>>>>>>>>> new
> >>> >> > > >>>>>>>>>>>>>>>>>>>>> files, which is why you need to do the
> add,
> >>> but
> >>> >> i'm
> >>> >> > > >>> not
> >>> >> > > >>>>>>> the
> >>> >> > > >>>>>>>>>> most
> >>> >> > > >>>>>>>>>>>>>>>>>>>>> sophisticated git user, so
> >>> >> > > >>>>>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>>>>>> 2) i figured since we are using git now
> >>> that
> >>> >> we
> >>> >> > > >>> should
> >>> >> > > >>>>>>>> use
> >>> >> > > >>>>>>>>>>>> git's
> >>> >> > > >>>>>>>>>>>>>>>>>>>>>> default.
> >>> >> > > >>>>>>>>>>>>>>>>>>>>>>> the patch should work (by default it
> >>> seems to
> >>> >> > strip
> >>> >> > > >>>> the
> >>> >> > > >>>>>>>>> first
> >>> >> > > >>>>>>>>>>>>>>> path
> >>> >> > > >>>>>>>>>>>>>>>>>>>>>> element).
> >>> >> > > >>>>>>>>>>>>>>>>>>>>>>> does it not work for you?
> >>> >> > > >>>>>>>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>>>>> It will fail precommit in it's current
> >>> state.
> >>> >> > > >>>>>>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>>>> fixed
> >>> >> > > >>>>>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>> --
> >>> >> > > >>>>>>>>>>>>>> Cheers
> >>> >> > > >>>>>>>>>>>>>> Michael.
> >>> >> > > >>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>> --
> >>> >> > > >>>>>>>>>>>> Cheers
> >>> >> > > >>>>>>>>>>>> Michael.
> >>> >> > > >>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>
> >>> >> > > >>>>>>>>>>
> >>> >> > > >>>>>>>>>
> >>> >> > > >>>>>>>>>
> >>> >> > > >>>>>>>>> --
> >>> >> > > >>>>>>>>> Cheers
> >>> >> > > >>>>>>>>> Michael.
> >>> >> > > >>>>>>>>>
> >>> >> > > >>>>>>>>
> >>> >> > > >>>>>>>
> >>> >> > > >>>>>
> >>> >> > > >>>>>
> >>> >> > > >>>>
> >>> >> > > >>>>
> >>> >> > > >>>> --
> >>> >> > > >>>> Cheers
> >>> >> > > >>>> Michael.
> >>> >> > > >>>>
> >>> >> > > >>>
> >>> >> > > >>
> >>> >> > > >>
> >>> >> > > >>
> >>> >> > > >> --
> >>> >> > > >> Cheers
> >>> >> > > >> Michael.
> >>> >> > > >>
> >>> >> > > >
> >>> >> > > >
> >>> >> > > >
> >>> >> > > > --
> >>> >> > > > Cheers
> >>> >> > > > Michael.
> >>> >> > >
> >>> >> > >
> >>> >> >
> >>> >>
> >>> >
> >>>
> >>
> >>
> >
>

Re: [VOTE] move Apache Zookeeper to git

Posted by Patrick Hunt <ph...@apache.org>.

No problem Edward. Did you get any insight on what to do with the PR?

Patrick

On Thu, Nov 24, 2016 at 10:52 AM, Edward Ribeiro <ed...@gmail.com>
wrote:

> Hi, Patrick,
>
> Thanks for merging this change. :)
>
> Sincerely, I don't know why it didn't close the PR automatically. Nor why
> you can close it in the GH mirror. In any case, I manually closed it.
>
> I will ping folks from other Apache projects using similar tool to inquire
> why it didn't close the PR and why it gave this 'write access' error
> message.
>
> Edward
>
>
>
> On Fri, Nov 18, 2016 at 8:13 PM, Patrick Hunt <ph...@apache.org> wrote:
>
>> Thanks Edward, this should be very helpful for folks. I committed,
>> however I notice the PR is still open. I followed the steps here:
>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/Committing+changes
>> however I don't see a way to close the PR? https://github.com/apache/
>> zookeeper/pull/103 says I don't have "write access".
>>
>> Patrick
>>
>> On Thu, Nov 10, 2016 at 10:23 AM, Edward Ribeiro <
>> edward.ribeiro@gmail.com> wrote:
>>
>>> Hi Patrick,
>>>
>>> I've just opened a PR  https://github.com/apache/zookeeper/pull/103/ PR
>>>
>>> It asks for JIRA_PASSWORD at CLI prompt *IF* it's absent but
>>> JIRA_USERNAME
>>> is already set. Please, when you have time, see if it fits what you need
>>> and then I can open a JIRA, rename the feature branch, etc.
>>>
>>> Let me know if you have other ideas. I am open to other ways of
>>> incorporating the passing of JIRA_PASSWORD too.
>>>
>>> Edward
>>>
>>> On Wed, Nov 9, 2016 at 5:03 PM, Edward Ribeiro <edward.ribeiro@gmail.com
>>> >
>>> wrote:
>>>
>>> > Hi Patrick,
>>> >
>>> > We can change the script so that it asks for jira password input on CLI
>>> > prompt if the JIRA username is set, for example. The change should be
>>> > straigthforward.
>>> >
>>> > Alternatively, the python systems I have dealt with put credentials for
>>> > database access, etc, in configuration -- sometimes hidden -- files
>>> (say,
>>> > .env), but yet it is clear text stored.
>>> >
>>> > Anyone has other suggestions?
>>> >
>>> > Eddie
>>> >
>>> > Em 9 de nov de 2016 4:18 PM, "Patrick Hunt" <ph...@apache.org>
>>> escreveu:
>>> >
>>> >> Is there any alternative to step 4 as documented here?
>>> >> https://cwiki.apache.org/confluence/display/ZOOKEEPER/Mergin
>>> >> g+Github+Pull+Requests
>>> >>
>>> >> specifically it's asking to "export JIRA_PASSWORD=mypassword" which I
>>> feel
>>> >> very uncomfortable doing.
>>> >>
>>> >> Patrick
>>> >>
>>> >> On Wed, Oct 26, 2016 at 11:12 AM, Edward Ribeiro <
>>> >> edward.ribeiro@gmail.com>
>>> >> wrote:
>>> >>
>>> >> > AFAIK, yes. I say, if you mean to run unit tests and other CI tasks
>>> on
>>> >> PR.
>>> >> >
>>> >> > PS: I have just created a simple script HowTo at
>>> >> > https://cwiki.apache.org/confluence/display/ZOOKEEPER/
>>> >> > Merging+Github+Pull+Requests
>>> >> > and linked from https://cwiki.apache.org/confl
>>> uence/display/ZOOKEEPER/
>>> >> > Index
>>> >> >
>>> >> > On Wed, Oct 26, 2016 at 3:59 PM, Flavio Junqueira <fp...@apache.org>
>>> >> wrote:
>>> >> >
>>> >> > > What about QA, are we still missing a github pre-commit queue?
>>> >> > >
>>> >> > > -Flavio
>>> >> > >
>>> >> > > > On 26 Oct 2016, at 18:53, Michael Han <ha...@cloudera.com>
>>> wrote:
>>> >> > > >
>>> >> > > > The comment bridging should be fixed now - see INFRA-12752 for
>>> more
>>> >> > > > details.
>>> >> > > >
>>> >> > > > On Wed, Oct 26, 2016 at 10:03 AM, Michael Han <
>>> hanm@cloudera.com>
>>> >> > wrote:
>>> >> > > >
>>> >> > > >>>> The git PR *review* comments for ZOOKEEPER-2597 didn't show
>>> up on
>>> >> > > JIRA.
>>> >> > > >>
>>> >> > > >> The bridge was working the day Infra made the change - see the
>>> >> > previous
>>> >> > > >> comments made by git bot on ZOOKEEPER-761. Now it seems stop
>>> >> working.
>>> >> > I
>>> >> > > am
>>> >> > > >> reopening INFRA-12752 and building a case.
>>> >> > > >>
>>> >> > > >> On Wed, Oct 26, 2016 at 9:45 AM, Edward Ribeiro <
>>> >> > > edward.ribeiro@gmail.com>
>>> >> > > >> wrote:
>>> >> > > >>
>>> >> > > >>> Dear community,
>>> >> > > >>>
>>> >> > > >>> The zk-merger-pr.py script has been merged into master
>>> (thanks a
>>> >> LOT
>>> >> > > Ben
>>> >> > > >>> Reed for reviewing/discussing/testing and commiting):
>>> >> > > >>> https://issues.apache.org/jira/browse/ZOOKEEPER-2597
>>> >> > > >>>
>>> >> > > >>> As stated in the issue and on GH, this tool is a modified
>>> version
>>> >> of
>>> >> > > >>> similar tools from Kafka, that is a copy of a Spark's one. It
>>> has
>>> >> > some
>>> >> > > >>> rough edges so we will certainly benefit from further
>>> enhancements
>>> >> > and
>>> >> > > >>> fixes. I changed the smallest possible pieces of code, just to
>>> >> make
>>> >> > it
>>> >> > > >>> work
>>> >> > > >>> on a ZK repo so the credits go to the original authors.
>>> >> > > >>>
>>> >> > > >>> Some notes:
>>> >> > > >>>
>>> >> > > >>> 1. The git PR *review* comments for ZOOKEEPER-2597 didn't
>>> show up
>>> >> on
>>> >> > > JIRA.
>>> >> > > >>> Only the opening and closing of the issue. Can we double check
>>> >> this
>>> >> > as
>>> >> > > >>> INFRA-12752 is closed, Michael Han?
>>> >> > > >>>
>>> >> > > >>> 2. I scribbled a draft on how use the tool at
>>> >> > > >>> https://docs.google.com/document/d/1i00ZXjrW2fu17vr_h7F1bUrq
>>> >> > > >>> Xg3urw4Hm7KirQDpPIU/edit
>>> >> > > >>> (still very crude, but feel free to improve it). I would like
>>> to
>>> >> move
>>> >> > > >>> this
>>> >> > > >>> text to https://cwiki.apache.org/confl
>>> >> uence/display/ZOOKEEPER/Index
>>> >> > > but
>>> >> > > >>> looks like I don't have permission to create a page there
>>> yet. Any
>>> >> > > help?
>>> >> > > >>>
>>> >> > > >>> Best regards,
>>> >> > > >>> Eddie
>>> >> > > >>>
>>> >> > > >>> On Sat, Oct 22, 2016 at 7:08 PM, Michael Han <
>>> hanm@cloudera.com>
>>> >> > > wrote:
>>> >> > > >>>
>>> >> > > >>>> FYI infra did some work in INFRA-12752 and the git PR
>>> comments
>>> >> can
>>> >> > be
>>> >> > > >>>> pushed to Apache JIRA.
>>> >> > > >>>>
>>> >> > > >>>> On Sat, Oct 8, 2016 at 8:01 AM, Flavio Junqueira <
>>> fpj@apache.org
>>> >> >
>>> >> > > >>> wrote:
>>> >> > > >>>>
>>> >> > > >>>>> This is not supported at the moment if nothing has changed:
>>> >> > > >>>>>
>>> >> > > >>>>> https://issues.apache.org/jira/browse/INFRA-11000 <
>>> >> > > >>>>> https://issues.apache.org/jira/browse/INFRA-11000>
>>> >> > > >>>>>
>>> >> > > >>>>> -Flavio
>>> >> > > >>>>>
>>> >> > > >>>>>> On 08 Oct 2016, at 00:54, Benjamin Reed <br...@apache.org>
>>> >> wrote:
>>> >> > > >>>>>>
>>> >> > > >>>>>> it doesn't look like we need to setup keys. this seems to
>>> work
>>> >> for
>>> >> > > >>> me:
>>> >> > > >>>>>>
>>> >> > > >>>>>> https://git-wip-us.apache.org/#committers-getting-started
>>> >> > > >>>>>>
>>> >> > > >>>>>> it does seem strange that we aren't using public keys and
>>> that
>>> >> i'm
>>> >> > > >>>>> sticking
>>> >> > > >>>>>> a password in .netrc :P i'm wondering if other projects
>>> were
>>> >> able
>>> >> > to
>>> >> > > >>>> get
>>> >> > > >>>>>> this going over ssh.
>>> >> > > >>>>>>
>>> >> > > >>>>>> i'll take a whack at cleaning up the svn and subversion
>>> >> > references.
>>> >> > > >>>>>>
>>> >> > > >>>>>> ben
>>> >> > > >>>>>>
>>> >> > > >>>>>> On Fri, Oct 7, 2016 at 12:59 PM, Camille Fournier <
>>> >> > > >>> camille@apache.org>
>>> >> > > >>>>>> wrote:
>>> >> > > >>>>>>
>>> >> > > >>>>>>> Hey folks,
>>> >> > > >>>>>>>
>>> >> > > >>>>>>> So I'm trying to get in a patch but this has not been
>>> updated
>>> >> to
>>> >> > > >>> tell
>>> >> > > >>>>>>> committers how to actually get the git keys set up:
>>> >> > > >>>>>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
>>> >> > > >>>>> Committing+changes
>>> >> > > >>>>>>>
>>> >> > > >>>>>>> Can someone float me a link that says how to do this?
>>> >> > > >>>>>>>
>>> >> > > >>>>>>> Also a bunch of our documentation still discusses SVN and
>>> not
>>> >> > git,
>>> >> > > >>>> which
>>> >> > > >>>>>>> means we are not done with this migration. If you were
>>> pushing
>>> >> > for
>>> >> > > >>>> this
>>> >> > > >>>>>>> change can you please do some due diligence on the wikis
>>> and
>>> >> > > >>> correct
>>> >> > > >>>> the
>>> >> > > >>>>>>> stuff that refers to SVN?
>>> >> > > >>>>>>>
>>> >> > > >>>>>>> Thanks,
>>> >> > > >>>>>>> C
>>> >> > > >>>>>>>
>>> >> > > >>>>>>> On Wed, Oct 5, 2016 at 1:02 PM, Edward Ribeiro <
>>> >> > > >>>>> edward.ribeiro@gmail.com>
>>> >> > > >>>>>>> wrote:
>>> >> > > >>>>>>>
>>> >> > > >>>>>>>> Excuse me guys!
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>> I've written on Macbook Pro. No idea why GMail messed it
>>> up.
>>> >> I
>>> >> > was
>>> >> > > >>>> only
>>> >> > > >>>>>>>> able to see the strange characters when I pasted on a
>>> gist
>>> >> text
>>> >> > > >>> area.
>>> >> > > >>>>> The
>>> >> > > >>>>>>>> previous message is below, but if anyone is still having
>>> >> trouble
>>> >> > > >>> (I
>>> >> > > >>>>> tried
>>> >> > > >>>>>>>> to remove the weird character), I left a copy at:
>>> >> > > >>>>>>>> https://gist.github.com/eribei
>>> ro/da2a6a6c9a508610d52d0755fae
>>> >> 835
>>> >> > 2d
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>> "Hi,
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>> The patch attached on ZOOKEEPER-2597 is a straightforward
>>> >> > > >>> adaptation
>>> >> > > >>>> of
>>> >> > > >>>>>>>> Kafka's one. It takes care of merging Github PR into
>>> Apache
>>> >> git
>>> >> > > >>> repo
>>> >> > > >>>>> and
>>> >> > > >>>>>>> a
>>> >> > > >>>>>>>> subsequent closing of the PR on the GH side, among other
>>> >> things
>>> >> > > >>>>>>> (rewriting
>>> >> > > >>>>>>>> of commit messages, etc). The current status is: the
>>> script
>>> >> > needs
>>> >> > > >>> to
>>> >> > > >>>> be
>>> >> > > >>>>>>>> reviewed/validated by a committer. It has been some time
>>> >> since I
>>> >> > > >>>>> uploaded
>>> >> > > >>>>>>>> the patch, so I gonna do another pass through it in the
>>> >> > meantime.
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>> There are some workflow issues beyond the scope of
>>> >> > ZOOKEEPER-2597
>>> >> > > >>>> that
>>> >> > > >>>>>>> need
>>> >> > > >>>>>>>> to be sorted out (IMO):
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>> 1. The normal workflow is to open a JIRA ticket before
>>> doing
>>> >> any
>>> >> > > >>> GH
>>> >> > > >>>> PR,
>>> >> > > >>>>>>>> that is, no JIRA-less PRs. The PR should have a title of
>>> the
>>> >> > form
>>> >> > > >>>>>>>> "ZOOKEEPER-xxxx: Title". This will trigger the Apache
>>> >> > JIRA-Github
>>> >> > > >>>>>>>> integration and it's opening show up in the JIRA ticket.
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>> 2. OTOH, not every Kafka PR needs a corresponding JIRA
>>> >> ticket.
>>> >> > > >>> There
>>> >> > > >>>>> are
>>> >> > > >>>>>>> a
>>> >> > > >>>>>>>> class of PRs with "MINOR" title that represent trivial
>>> code
>>> >> > > >>> changes
>>> >> > > >>>> and
>>> >> > > >>>>>>>> "HOT-FIX" title that fix urgent, but simple bugs. Both
>>> bypass
>>> >> > the
>>> >> > > >>>> JIRA
>>> >> > > >>>>>>>> creation step, even tough they are still subject to
>>> review.
>>> >> It's
>>> >> > > >>>> worth
>>> >> > > >>>>>>>> adopting a similar approach for ZK project?
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>> 3. IIRC (didn't find any page to confirm), Cassandra
>>> project
>>> >> > > >>>>> encourages,
>>> >> > > >>>>>>>> but not demands, that contributors also upload a patch
>>> file
>>> >> to
>>> >> > > >>> JIRA
>>> >> > > >>>>> even
>>> >> > > >>>>>>> in
>>> >> > > >>>>>>>> the case of a GH PR (as to leave a audit trail, I guess).
>>> >> Or, at
>>> >> > > >>>>> least,
>>> >> > > >>>>>>> C*
>>> >> > > >>>>>>>> project leaves up to the contributors to either open a
>>> GH PR
>>> >> or
>>> >> > > >>>> upload
>>> >> > > >>>>>>> the
>>> >> > > >>>>>>>> patch file to JIRA.
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>> +1 about having a 'paper trail' of review comments on
>>> JIRA
>>> >> > and/or
>>> >> > > >>>>> mailing
>>> >> > > >>>>>>>> list (I would prefer the mailing list tbh). But as
>>> Michael
>>> >> and
>>> >> > > >>> Flavio
>>> >> > > >>>>>>>> pointed out, I never seen GH PR review **comments** being
>>> >> > written
>>> >> > > >>>> back
>>> >> > > >>>>> to
>>> >> > > >>>>>>>> JIRA, at least not in Kafka, Cassandra or Solr projects,
>>> >> that I
>>> >> > > >>> have
>>> >> > > >>>>>>>> followed more closely.
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>> Eddie"
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>> On Wed, Oct 5, 2016 at 1:35 PM, Michael Han <
>>> >> hanm@cloudera.com>
>>> >> > > >>>> wrote:
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>>> Eddie's mail contains lots of '=E2=80=8B'' which is
>>> unicode
>>> >> > > >>>> character
>>> >> > > >>>>>>>>> zero-width space, which might cause parsing trouble for
>>> some
>>> >> > mail
>>> >> > > >>>>>>>> clients.
>>> >> > > >>>>>>>>>
>>> >> > > >>>>>>>>> On Wed, Oct 5, 2016 at 6:42 AM, Flavio Junqueira <
>>> >> > fpj@apache.org
>>> >> > > >>>>
>>> >> > > >>>>>>> wrote:
>>> >> > > >>>>>>>>>
>>> >> > > >>>>>>>>>> Dude, I'm just not able to parse your e-mail, did you
>>> write
>>> >> > that
>>> >> > > >>>> on a
>>> >> > > >>>>>>>>>> phone or something?
>>> >> > > >>>>>>>>>>
>>> >> > > >>>>>>>>>> -Flavio
>>> >> > > >>>>>>>>>>
>>> >> > > >>>>>>>>>>> On 05 Oct 2016, at 03:54, Edward Ribeiro <
>>> >> > > >>>> edward.ribeiro@gmail.com
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>>>> wrote:
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>> Hi,
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>> The patch attached on ZOOKEEPER-2597 is a
>>> >> > > >>>>>>>>>>> straightforward adaptation of
>>> >> > > >>>>>>>>>>> Kafka's one. It takes care of merging Github PR into
>>> >> Apache
>>> >> > git
>>> >> > > >>>>>>> repo
>>> >> > > >>>>>>>>> and
>>> >> > > >>>>>>>>>>>  a
>>> >> > > >>>>>>>>>>> subsequent closing of the PR on the GH side
>>> >> > > >>>>>>>>>>>  among other things (rewriting of commit messages,
>>> etc)
>>> >> > > >>>>>>>>>>> . The current status is: the script needs to be
>>> >> > > >>> reviewed/validated
>>> >> > > >>>>>>>> by a
>>> >> > > >>>>>>>>>>> committer.
>>> >> > > >>>>>>>>>>> It has been some time since I uploaded the patch, so
>>> I
>>> >> gonna
>>> >> > > >>> do
>>> >> > > >>>>>>>>> another
>>> >> > > >>>>>>>>>>> pass through it in the meantime.
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>> T
>>> >> > > >>>>>>>>>>> here are some workflow issues beyond the scope of
>>> >> > > >>> ZOOKEEPER-2597
>>> >> > > >>>>>>>>>>>  that need to be sorted out (IMO)
>>> >> > > >>>>>>>>>>> :
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>> 1. The normal workflow is to open a JIRA ticket before
>>> >> doing
>>> >> > > >>> any
>>> >> > > >>>> GH
>>> >> > > >>>>>>>> PR
>>> >> > > >>>>>>>>>>> , that is, no JIRA-less PRs.
>>> >> > > >>>>>>>>>>> The PR should have a title of the form
>>> "ZOOKEEPER-xxxx:
>>> >> > Title".
>>> >> > > >>>>>>> This
>>> >> > > >>>>>>>>> will
>>> >> > > >>>>>>>>>>> trigger the Apache JIRA-Github integration and it's
>>> >> opening
>>> >> > > >>> show
>>> >> > > >>>> up
>>> >> > > >>>>>>>> in
>>> >> > > >>>>>>>>>> the
>>> >> > > >>>>>>>>>>> JIRA ticket.
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>> 2.
>>> >> > > >>>>>>>>>>> OTOH, n
>>> >> > > >>>>>>>>>>> ot every Kafka PR needs a corresponding JIRA ticket
>>> >> > > >>>>>>>>>>> . 
>>> >> > > >>>>>>>>>>> There are a class of PR
>>> >> > > >>>>>>>>>>> s
>>> >> > > >>>>>>>>>>> with "MINOR"
>>> >> > > >>>>>>>>>>>  title
>>> >> > > >>>>>>>>>>> that represent trivial code changes
>>> >> > > >>>>>>>>>>>  and "HOT-FIX" title that fix urgent, but simple
>>> bugs.
>>> >> Both
>>> >> > > >>>>>>>>>>> bypass the JIRA creation step
>>> >> > > >>>>>>>>>>> , even tough they are still 
>>> >> > > >>>>>>>>>>> subject to review
>>> >> > > >>>>>>>>>>> .
>>> >> > > >>>>>>>>>>> It's worth adopting a similar approach for ZK project?
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>> 3. IIRC
>>> >> > > >>>>>>>>>>>  (didn't find any page to confirm)
>>> >> > > >>>>>>>>>>> , Cassandra project encourages, but not demands, that
>>> >> > > >>> contributors
>>> >> > > >>>>>>>> also
>>> >> > > >>>>>>>>>>> upload a patch file to JIRA even in the case of a GH
>>> PR
>>> >> > > >>>>>>>>>>>  (as to leave a audit trail, I guess)
>>> >> > > >>>>>>>>>>> .
>>> >> > > >>>>>>>>>>> Or
>>> >> > > >>>>>>>>>>> ,
>>> >> > > >>>>>>>>>>> at
>>> >> > > >>>>>>>>>>>  
>>> >> > > >>>>>>>>>>> least
>>> >> > > >>>>>>>>>>> ,
>>> >> > > >>>>>>>>>>> C* project 
>>> >> > > >>>>>>>>>>> leave
>>> >> > > >>>>>>>>>>> s
>>> >> > > >>>>>>>>>>> up to the contributor
>>> >> > > >>>>>>>>>>> s
>>> >> > > >>>>>>>>>>> to either open a GH PR or upload the patch file
>>> >> > > >>>>>>>>>>>  to JIRA. In fact, Github allows the access to a raw
>>> >> patch
>>> >> > or
>>> >> > > >>>>>>> diff,
>>> >> > > >>>>>>>>> it's
>>> >> > > >>>>>>>>>>> just a matter of adding the ".patch" or ".diff"
>>> suffix to
>>> >> the
>>> >> > > >>> end
>>> >> > > >>>>>>> of
>>> >> > > >>>>>>>>> the
>>> >> > > >>>>>>>>>>> Pull Request URL.
>>> >> > > >>>>>>>>>>> 
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>> +1 about having a 'paper trail'
>>> >> > > >>>>>>>>>>>  of review comments
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>> o
>>> >> > > >>>>>>>>>>> n JIRA and
>>> >> > > >>>>>>>>>>> /or
>>> >> > > >>>>>>>>>>> mailing list (I
>>> >> > > >>>>>>>>>>>  would
>>> >> > > >>>>>>>>>>> prefer the mailing list tbh). But as Michael and
>>> Flavio
>>> >> > pointed
>>> >> > > >>>>>>> out,
>>> >> > > >>>>>>>> I
>>> >> > > >>>>>>>>>>> never seen
>>> >> > > >>>>>>>>>>> GH 
>>> >> > > >>>>>>>>>>> PR review
>>> >> > > >>>>>>>>>>> **
>>> >> > > >>>>>>>>>>> comments
>>> >> > > >>>>>>>>>>> **
>>> >> > > >>>>>>>>>>> being written back to JIRA, at least not in Kafka,
>>> >> Cassandra
>>> >> > > >>>>>>>>>>> or
>>> >> > > >>>>>>>>>>> Solr projects
>>> >> > > >>>>>>>>>>> , that I have followed more closely.
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>> Eddie
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>> On Tue, Oct 4, 2016 at 6:40 PM, Michael Han <
>>> >> > hanm@cloudera.com
>>> >> > > >>>>
>>> >> > > >>>>>>>> wrote:
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>> as long as the opening/closing/commenting all get
>>> sent
>>> >> to
>>> >> > > >>> the
>>> >> > > >>>>>>>>> mailing
>>> >> > > >>>>>>>>>>>> list or recorded in jira
>>> >> > > >>>>>>>>>>>> Yeah, this is my impression as well, that we need to
>>> keep
>>> >> > > >>> certain
>>> >> > > >>>>>>>>> paper
>>> >> > > >>>>>>>>>>>> trail regarding activities and comments on ASF side
>>> >> (JIRA or
>>> >> > > >>> mail
>>> >> > > >>>>>>>>> list).
>>> >> > > >>>>>>>>>>>> Infra page said:
>>> >> > > >>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>> - Any Pull Request that gets opened, closed,
>>> reopened or
>>> >> > > >>>>>>>>> **commented**
>>> >> > > >>>>>>>>>>>> on now gets recorded on the project's mailing list
>>> >> > > >>>>>>>>>>>> - If a project has a JIRA instance, any PRs or
>>> >> *comments* on
>>> >> > > >>> PRs
>>> >> > > >>>>>>>>> that
>>> >> > > >>>>>>>>>>>> include a JIRA ticket ID will trigger an update on
>>> that
>>> >> > > >>> specific
>>> >> > > >>>>>>>>>> ticket
>>> >> > > >>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>> I checked a couple Kafka and Spark JIRAs but I don't
>>> see
>>> >> any
>>> >> > > >>> of
>>> >> > > >>>>>>> the
>>> >> > > >>>>>>>>>>>> comments made in github PR were posted on JIRA,
>>> except
>>> >> the
>>> >> > > >>>>>>>> activities
>>> >> > > >>>>>>>>>> (open
>>> >> > > >>>>>>>>>>>> a PR, close a PR). Since both projects have been
>>> using
>>> >> > github
>>> >> > > >>> for
>>> >> > > >>>>>>> a
>>> >> > > >>>>>>>>>> while I
>>> >> > > >>>>>>>>>>>> assume such practice of NOT integrating comments
>>> between
>>> >> > > >>> github
>>> >> > > >>>>>>> and
>>> >> > > >>>>>>>>> ASF
>>> >> > > >>>>>>>>>>>> JIRA is acceptable? Though I feel it would be really
>>> >> useful
>>> >> > if
>>> >> > > >>>>>>>>> comments
>>> >> > > >>>>>>>>>>>> could converge in a single place as well, that will
>>> >> provide
>>> >> > a
>>> >> > > >>>>>>> clear
>>> >> > > >>>>>>>>>> history
>>> >> > > >>>>>>>>>>>> for a given technical issue.
>>> >> > > >>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>> On Tue, Oct 4, 2016 at 12:06 PM, Flavio Junqueira <
>>> >> > > >>>> fpj@apache.org
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>>>> wrote:
>>> >> > > >>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>> Until ZOOKEEPER-2597 <https://issues.apache.org/
>>> >> > > >>>>>>>>>>>> jira/browse/ZOOKEEPER-2597>
>>> >> > > >>>>>>>>>>>>> is fixed, we can't merge via github.
>>> >> > > >>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>> For code reviews, we can use GH as long as the
>>> >> > > >>>>>>>>>> opening/closing/commenting
>>> >> > > >>>>>>>>>>>>> all get sent to the mailing list or recorded in
>>> jira. I
>>> >> > don't
>>> >> > > >>>>>>> think
>>> >> > > >>>>>>>>> we
>>> >> > > >>>>>>>>>>>> have
>>> >> > > >>>>>>>>>>>>> that yet, but it is possible according to this:
>>> >> > > >>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>> https://blogs.apache.org/infra/entry/improved_
>>> >> > > >>>>>>>>>>>>> integration_between_apache_and <
>>> >> https://blogs.apache.org/
>>> >> > > >>>>>>>>>>>>> infra/entry/improved_integrati
>>> on_between_apache_and>
>>> >> > > >>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>> For now, we do need to upload patches and converge
>>> using
>>> >> > > >>> jira.
>>> >> > > >>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>> I think Eddie has been looking at this process
>>> trying to
>>> >> > > >>>>>>> replicate
>>> >> > > >>>>>>>>> the
>>> >> > > >>>>>>>>>>>>> Kafka setup, so perhaps he can give an update if I'm
>>> >> right.
>>> >> > > >>>> Kafka
>>> >> > > >>>>>>>>>> doesn't
>>> >> > > >>>>>>>>>>>>> send every comment to the mailing list, though, but
>>> I'm
>>> >> not
>>> >> > > >>> sure
>>> >> > > >>>>>>> if
>>> >> > > >>>>>>>>>>>> that's
>>> >> > > >>>>>>>>>>>>> acceptable according to the ASF, I need to
>>> double-check.
>>> >> > > >>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>> -Flavio
>>> >> > > >>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>> On 04 Oct 2016, at 19:42, Michael Han <
>>> >> hanm@cloudera.com>
>>> >> > > >>>>>>> wrote:
>>> >> > > >>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>> Hi,
>>> >> > > >>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>> Now we've moved to git, what is the policy for
>>> >> uploading
>>> >> > > >>>> patches
>>> >> > > >>>>>>>> and
>>> >> > > >>>>>>>>>>>>> doing
>>> >> > > >>>>>>>>>>>>>> code reviews? I am asking because I've seen
>>> recently
>>> >> there
>>> >> > > >>> are
>>> >> > > >>>>>>> git
>>> >> > > >>>>>>>>>> pull
>>> >> > > >>>>>>>>>>>>>> requests coming in without associated patch file
>>> >> uploaded
>>> >> > to
>>> >> > > >>>>>>> JIRA.
>>> >> > > >>>>>>>>>> I've
>>> >> > > >>>>>>>>>>>>>> checked
>>> >> > > >>>>>>>>>>>>>> https://cwiki.apache.org/confl
>>> uence/display/ZOOKEEPER/
>>> >> > > >>>>>>>>> HowToContribute
>>> >> > > >>>>>>>>>> ,
>>> >> > > >>>>>>>>>>>>>> looks like there is not much change regarding patch
>>> >> > process
>>> >> > > >>> -
>>> >> > > >>>> so
>>> >> > > >>>>>>>>>>>>> presumably
>>> >> > > >>>>>>>>>>>>>> we still need to generate and upload patch file to
>>> JIRA
>>> >> > for
>>> >> > > >>> the
>>> >> > > >>>>>>>>>> record,
>>> >> > > >>>>>>>>>>>>>> while using github (maybe in addition of review
>>> board,
>>> >> or
>>> >> > in
>>> >> > > >>>> the
>>> >> > > >>>>>>>>>> future
>>> >> > > >>>>>>>>>>>>>> with gerrit) to do code reviews?
>>> >> > > >>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>> On Wed, Sep 21, 2016 at 6:05 AM, Edward Ribeiro <
>>> >> > > >>>>>>>>>>>>> edward.ribeiro@gmail.com>
>>> >> > > >>>>>>>>>>>>>> wrote:
>>> >> > > >>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>> Cool, just open https://issues.apache.org/
>>> >> > > >>>>>>>>> jira/browse/ZOOKEEPER-2597
>>> >> > > >>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>> PS: I removed the REPO_HOME global variable.
>>> >> > > >>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>> On Wed, Sep 21, 2016 at 6:53 AM, Flavio Junqueira
>>> <
>>> >> > > >>>>>>>> fpj@apache.org>
>>> >> > > >>>>>>>>>>>>> wrote:
>>> >> > > >>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>> Better to have that in the form of a pull
>>> request or
>>> >> > diff.
>>> >> > > >>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>> REPO_HOME does seem to be unused.
>>> >> > > >>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>> -Flavio
>>> >> > > >>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>> On 20 Sep 2016, at 18:57, Edward Ribeiro <
>>> >> > > >>>>>>>>> edward.ribeiro@gmail.com
>>> >> > > >>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>> wrote:
>>> >> > > >>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>> Hey, I have started porting the kafka-merge.py
>>> to
>>> >> work
>>> >> > > >>> on ZK
>>> >> > > >>>>>>>>> repos.
>>> >> > > >>>>>>>>>>>> I
>>> >> > > >>>>>>>>>>>>>>>> would
>>> >> > > >>>>>>>>>>>>>>>>> need someone to review it and help me test it
>>> now.
>>> >> > > >>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>> The files were uploaded below, but I will
>>> create a
>>> >> > github
>>> >> > > >>>>>>> repo
>>> >> > > >>>>>>>>> yet
>>> >> > > >>>>>>>>>>>>>>> today.
>>> >> > > >>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>> https://www.dropbox.com/sh/od8bet2574jttm3/
>>> >> > > >>>>>>>>>>>>>>>> AADv1DXTb8vfyVCmelFbYCEha?dl=0
>>> >> > > >>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>> I uploaded the kafka version script so that you
>>> can
>>> >> use
>>> >> > > >>> diff
>>> >> > > >>>>>>> or
>>> >> > > >>>>>>>>>> Meld
>>> >> > > >>>>>>>>>>>>> to
>>> >> > > >>>>>>>>>>>>>>>>> spot my changes, but feel free to grasp the
>>> original
>>> >> > file
>>> >> > > >>>>>>> here:
>>> >> > > >>>>>>>>>>>>>>>>> https://github.com/apache/
>>> >> > kafka/blob/trunk/kafka-merge-
>>> >> > > >>>> pr.py
>>> >> > > >>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>> PS: It's just me or REPO_HOME env variable is
>>> not
>>> >> used
>>> >> > > >>>>>>> anywhere
>>> >> > > >>>>>>>>> in
>>> >> > > >>>>>>>>>>>> the
>>> >> > > >>>>>>>>>>>>>>>>> merge script???
>>> >> > > >>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>> Cheers,
>>> >> > > >>>>>>>>>>>>>>>>> Eddie
>>> >> > > >>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick Hunt <
>>> >> > > >>>>>>>> phunt@apache.org
>>> >> > > >>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>> wrote:
>>> >> > > >>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin Reed
>>> <
>>> >> > > >>>>>>>>> breed@apache.org>
>>> >> > > >>>>>>>>>>>>>>>> wrote:
>>> >> > > >>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>> what you are suggesting sounds good, but i
>>> don't
>>> >> know
>>> >> > > >>> how
>>> >> > > >>>>>>> to
>>> >> > > >>>>>>>> do
>>> >> > > >>>>>>>>>>>> it?
>>> >> > > >>>>>>>>>>>>>>>> since
>>> >> > > >>>>>>>>>>>>>>>>>>> in the end we are still just accepting diffs
>>> on
>>> >> > > >>> patches,
>>> >> > > >>>>>>> the
>>> >> > > >>>>>>>>> only
>>> >> > > >>>>>>>>>>>>>>> thing
>>> >> > > >>>>>>>>>>>>>>>>>>> that changes is that we use svn rather than
>>> git
>>> >> > right?
>>> >> > > >>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>> Notice the workflow Kafka uses - which includes
>>> >> "git
>>> >> > > >>> apply"
>>> >> > > >>>>>>>> and
>>> >> > > >>>>>>>>>>>>>>>> specifying
>>> >> > > >>>>>>>>>>>>>>>>>> the author tag when committers commit (so that
>>> the
>>> >> OP
>>> >> > > >>> gets
>>> >> > > >>>>>>>>> proper
>>> >> > > >>>>>>>>>>>>>>>>>> attribution in the commit itself)
>>> >> > > >>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>> https://cwiki.apache.org/confl
>>> uence/display/KAFKA/
>>> >> > > >>>>>>>>>>>>>>>> Manual+Commit+Workflow
>>> >> > > >>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>> Patrick
>>> >> > > >>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>> i LOVE chris's idea! lets do it!
>>> >> > > >>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>> ben
>>> >> > > >>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>> On Sun, Sep 18, 2016 at 3:22 PM, Patrick Hunt
>>> <
>>> >> > > >>>>>>>>> phunt@apache.org>
>>> >> > > >>>>>>>>>>>>>>>> wrote:
>>> >> > > >>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>> Ben, do you also want to update the
>>> "Applying a
>>> >> > patch"
>>> >> > > >>>>>>>> section
>>> >> > > >>>>>>>>>> to
>>> >> > > >>>>>>>>>>>>>>> make
>>> >> > > >>>>>>>>>>>>>>>>>> it
>>> >> > > >>>>>>>>>>>>>>>>>>>> git specific?
>>> >> > > >>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>> We (committers) should move to a model where
>>> >> authors
>>> >> > > >>> get
>>> >> > > >>>>>>>>> proper
>>> >> > > >>>>>>>>>>>>>>> credit
>>> >> > > >>>>>>>>>>>>>>>>>> in
>>> >> > > >>>>>>>>>>>>>>>>>>>> git. Our old workflow in svn resulted in
>>> only the
>>> >> > > >>>>>>> committer
>>> >> > > >>>>>>>>>> being
>>> >> > > >>>>>>>>>>>>>>>>>> listed
>>> >> > > >>>>>>>>>>>>>>>>>>>> (except that we listed the patch author in
>>> the
>>> >> > commit
>>> >> > > >>>>>>>>> message).
>>> >> > > >>>>>>>>>>>> We
>>> >> > > >>>>>>>>>>>>>>>>>> should
>>> >> > > >>>>>>>>>>>>>>>>>>>> move to a model where the author of the patch
>>> >> gets
>>> >> > > >>> proper
>>> >> > > >>>>>>>>> credit
>>> >> > > >>>>>>>>>>>> in
>>> >> > > >>>>>>>>>>>>>>>>>> git.
>>> >> > > >>>>>>>>>>>>>>>>>>> I
>>> >> > > >>>>>>>>>>>>>>>>>>>> believe we will get that if we use git for
>>> patch
>>> >> > > >>>>>>>>>>>>>>> creation/application?
>>> >> > > >>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>> Chris brought up getting rid of CHANGES.txt
>>> >> recently
>>> >> > > >>> on
>>> >> > > >>>>>>> the
>>> >> > > >>>>>>>>> dev
>>> >> > > >>>>>>>>>>>>> list
>>> >> > > >>>>>>>>>>>>>>>>>> in a
>>> >> > > >>>>>>>>>>>>>>>>>>>> separate thread - Chris do you want to
>>> implement
>>> >> > that
>>> >> > > >>>>>>> change
>>> >> > > >>>>>>>>> now
>>> >> > > >>>>>>>>>>>>>>> that
>>> >> > > >>>>>>>>>>>>>>>>>>> we've
>>> >> > > >>>>>>>>>>>>>>>>>>>> moved to git?
>>> >> > > >>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>> Patrick
>>> >> > > >>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin
>>> Reed <
>>> >> > > >>>>>>>>>> breed@apache.org
>>> >> > > >>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>> wrote:
>>> >> > > >>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>>>> 1) actually in the previous step that was
>>> just
>>> >> > > >>> adding
>>> >> > > >>>>>>> new
>>> >> > > >>>>>>>>>>>> files.
>>> >> > > >>>>>>>>>>>>>>> you
>>> >> > > >>>>>>>>>>>>>>>>>>>>>> still
>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> need the commit -a for the rest of the
>>> >> changes.
>>> >> > > >>> that's
>>> >> > > >>>>>>> my
>>> >> > > >>>>>>>>>>>> normal
>>> >> > > >>>>>>>>>>>>>>>>>>>>>> workflow.
>>> >> > > >>>>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>>>> I think that will be confusing for most
>>> folks.
>>> >> > They
>>> >> > > >>>>>>>>> typically
>>> >> > > >>>>>>>>>>>>>>> stage
>>> >> > > >>>>>>>>>>>>>>>>>>>>>> all the changes and then commit or don't
>>> stage
>>> >> and
>>> >> > > >>> use
>>> >> > > >>>>>>> -a.
>>> >> > > >>>>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>>> do you mind fixing it with your workflow.
>>> >> commit -a
>>> >> > > >>>>>>> doesn't
>>> >> > > >>>>>>>>> get
>>> >> > > >>>>>>>>>>>>> new
>>> >> > > >>>>>>>>>>>>>>>>>>>>> files, which is why you need to do the add,
>>> but
>>> >> i'm
>>> >> > > >>> not
>>> >> > > >>>>>>> the
>>> >> > > >>>>>>>>>> most
>>> >> > > >>>>>>>>>>>>>>>>>>>>> sophisticated git user, so
>>> >> > > >>>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> 2) i figured since we are using git now
>>> that
>>> >> we
>>> >> > > >>> should
>>> >> > > >>>>>>>> use
>>> >> > > >>>>>>>>>>>> git's
>>> >> > > >>>>>>>>>>>>>>>>>>>>>> default.
>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> the patch should work (by default it
>>> seems to
>>> >> > strip
>>> >> > > >>>> the
>>> >> > > >>>>>>>>> first
>>> >> > > >>>>>>>>>>>>>>> path
>>> >> > > >>>>>>>>>>>>>>>>>>>>>> element).
>>> >> > > >>>>>>>>>>>>>>>>>>>>>>> does it not work for you?
>>> >> > > >>>>>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>>>> It will fail precommit in it's current
>>> state.
>>> >> > > >>>>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>>> fixed
>>> >> > > >>>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>> --
>>> >> > > >>>>>>>>>>>>>> Cheers
>>> >> > > >>>>>>>>>>>>>> Michael.
>>> >> > > >>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>>
>>> >> > > >>>>>>>>>>>> --
>>> >> > > >>>>>>>>>>>> Cheers
>>> >> > > >>>>>>>>>>>> Michael.
>>> >> > > >>>>>>>>>>>>
>>> >> > > >>>>>>>>>>
>>> >> > > >>>>>>>>>>
>>> >> > > >>>>>>>>>
>>> >> > > >>>>>>>>>
>>> >> > > >>>>>>>>> --
>>> >> > > >>>>>>>>> Cheers
>>> >> > > >>>>>>>>> Michael.
>>> >> > > >>>>>>>>>
>>> >> > > >>>>>>>>
>>> >> > > >>>>>>>
>>> >> > > >>>>>
>>> >> > > >>>>>
>>> >> > > >>>>
>>> >> > > >>>>
>>> >> > > >>>> --
>>> >> > > >>>> Cheers
>>> >> > > >>>> Michael.
>>> >> > > >>>>
>>> >> > > >>>
>>> >> > > >>
>>> >> > > >>
>>> >> > > >>
>>> >> > > >> --
>>> >> > > >> Cheers
>>> >> > > >> Michael.
>>> >> > > >>
>>> >> > > >
>>> >> > > >
>>> >> > > >
>>> >> > > > --
>>> >> > > > Cheers
>>> >> > > > Michael.
>>> >> > >
>>> >> > >
>>> >> >
>>> >>
>>> >
>>>
>>
>>
>

Re: [VOTE] move Apache Zookeeper to git

Posted by Edward Ribeiro <ed...@gmail.com>.

Hi, Patrick,

Thanks for merging this change. :)

Sincerely, I don't know why it didn't close the PR automatically. Nor why
you can close it in the GH mirror. In any case, I manually closed it.

I will ping folks from other Apache projects using similar tool to inquire
why it didn't close the PR and why it gave this 'write access' error
message.

Edward



On Fri, Nov 18, 2016 at 8:13 PM, Patrick Hunt <ph...@apache.org> wrote:

> Thanks Edward, this should be very helpful for folks. I committed, however
> I notice the PR is still open. I followed the steps here:
> https://cwiki.apache.org/confluence/display/ZOOKEEPER/Committing+changes
> however I don't see a way to close the PR? https://github.com/apache/
> zookeeper/pull/103 says I don't have "write access".
>
> Patrick
>
> On Thu, Nov 10, 2016 at 10:23 AM, Edward Ribeiro <edward.ribeiro@gmail.com
> > wrote:
>
>> Hi Patrick,
>>
>> I've just opened a PR  https://github.com/apache/zookeeper/pull/103/ PR
>>
>> It asks for JIRA_PASSWORD at CLI prompt *IF* it's absent but JIRA_USERNAME
>> is already set. Please, when you have time, see if it fits what you need
>> and then I can open a JIRA, rename the feature branch, etc.
>>
>> Let me know if you have other ideas. I am open to other ways of
>> incorporating the passing of JIRA_PASSWORD too.
>>
>> Edward
>>
>> On Wed, Nov 9, 2016 at 5:03 PM, Edward Ribeiro <ed...@gmail.com>
>> wrote:
>>
>> > Hi Patrick,
>> >
>> > We can change the script so that it asks for jira password input on CLI
>> > prompt if the JIRA username is set, for example. The change should be
>> > straigthforward.
>> >
>> > Alternatively, the python systems I have dealt with put credentials for
>> > database access, etc, in configuration -- sometimes hidden -- files
>> (say,
>> > .env), but yet it is clear text stored.
>> >
>> > Anyone has other suggestions?
>> >
>> > Eddie
>> >
>> > Em 9 de nov de 2016 4:18 PM, "Patrick Hunt" <ph...@apache.org>
>> escreveu:
>> >
>> >> Is there any alternative to step 4 as documented here?
>> >> https://cwiki.apache.org/confluence/display/ZOOKEEPER/Mergin
>> >> g+Github+Pull+Requests
>> >>
>> >> specifically it's asking to "export JIRA_PASSWORD=mypassword" which I
>> feel
>> >> very uncomfortable doing.
>> >>
>> >> Patrick
>> >>
>> >> On Wed, Oct 26, 2016 at 11:12 AM, Edward Ribeiro <
>> >> edward.ribeiro@gmail.com>
>> >> wrote:
>> >>
>> >> > AFAIK, yes. I say, if you mean to run unit tests and other CI tasks
>> on
>> >> PR.
>> >> >
>> >> > PS: I have just created a simple script HowTo at
>> >> > https://cwiki.apache.org/confluence/display/ZOOKEEPER/
>> >> > Merging+Github+Pull+Requests
>> >> > and linked from https://cwiki.apache.org/confl
>> uence/display/ZOOKEEPER/
>> >> > Index
>> >> >
>> >> > On Wed, Oct 26, 2016 at 3:59 PM, Flavio Junqueira <fp...@apache.org>
>> >> wrote:
>> >> >
>> >> > > What about QA, are we still missing a github pre-commit queue?
>> >> > >
>> >> > > -Flavio
>> >> > >
>> >> > > > On 26 Oct 2016, at 18:53, Michael Han <ha...@cloudera.com> wrote:
>> >> > > >
>> >> > > > The comment bridging should be fixed now - see INFRA-12752 for
>> more
>> >> > > > details.
>> >> > > >
>> >> > > > On Wed, Oct 26, 2016 at 10:03 AM, Michael Han <hanm@cloudera.com
>> >
>> >> > wrote:
>> >> > > >
>> >> > > >>>> The git PR *review* comments for ZOOKEEPER-2597 didn't show
>> up on
>> >> > > JIRA.
>> >> > > >>
>> >> > > >> The bridge was working the day Infra made the change - see the
>> >> > previous
>> >> > > >> comments made by git bot on ZOOKEEPER-761. Now it seems stop
>> >> working.
>> >> > I
>> >> > > am
>> >> > > >> reopening INFRA-12752 and building a case.
>> >> > > >>
>> >> > > >> On Wed, Oct 26, 2016 at 9:45 AM, Edward Ribeiro <
>> >> > > edward.ribeiro@gmail.com>
>> >> > > >> wrote:
>> >> > > >>
>> >> > > >>> Dear community,
>> >> > > >>>
>> >> > > >>> The zk-merger-pr.py script has been merged into master (thanks
>> a
>> >> LOT
>> >> > > Ben
>> >> > > >>> Reed for reviewing/discussing/testing and commiting):
>> >> > > >>> https://issues.apache.org/jira/browse/ZOOKEEPER-2597
>> >> > > >>>
>> >> > > >>> As stated in the issue and on GH, this tool is a modified
>> version
>> >> of
>> >> > > >>> similar tools from Kafka, that is a copy of a Spark's one. It
>> has
>> >> > some
>> >> > > >>> rough edges so we will certainly benefit from further
>> enhancements
>> >> > and
>> >> > > >>> fixes. I changed the smallest possible pieces of code, just to
>> >> make
>> >> > it
>> >> > > >>> work
>> >> > > >>> on a ZK repo so the credits go to the original authors.
>> >> > > >>>
>> >> > > >>> Some notes:
>> >> > > >>>
>> >> > > >>> 1. The git PR *review* comments for ZOOKEEPER-2597 didn't show
>> up
>> >> on
>> >> > > JIRA.
>> >> > > >>> Only the opening and closing of the issue. Can we double check
>> >> this
>> >> > as
>> >> > > >>> INFRA-12752 is closed, Michael Han?
>> >> > > >>>
>> >> > > >>> 2. I scribbled a draft on how use the tool at
>> >> > > >>> https://docs.google.com/document/d/1i00ZXjrW2fu17vr_h7F1bUrq
>> >> > > >>> Xg3urw4Hm7KirQDpPIU/edit
>> >> > > >>> (still very crude, but feel free to improve it). I would like
>> to
>> >> move
>> >> > > >>> this
>> >> > > >>> text to https://cwiki.apache.org/confl
>> >> uence/display/ZOOKEEPER/Index
>> >> > > but
>> >> > > >>> looks like I don't have permission to create a page there yet.
>> Any
>> >> > > help?
>> >> > > >>>
>> >> > > >>> Best regards,
>> >> > > >>> Eddie
>> >> > > >>>
>> >> > > >>> On Sat, Oct 22, 2016 at 7:08 PM, Michael Han <
>> hanm@cloudera.com>
>> >> > > wrote:
>> >> > > >>>
>> >> > > >>>> FYI infra did some work in INFRA-12752 and the git PR comments
>> >> can
>> >> > be
>> >> > > >>>> pushed to Apache JIRA.
>> >> > > >>>>
>> >> > > >>>> On Sat, Oct 8, 2016 at 8:01 AM, Flavio Junqueira <
>> fpj@apache.org
>> >> >
>> >> > > >>> wrote:
>> >> > > >>>>
>> >> > > >>>>> This is not supported at the moment if nothing has changed:
>> >> > > >>>>>
>> >> > > >>>>> https://issues.apache.org/jira/browse/INFRA-11000 <
>> >> > > >>>>> https://issues.apache.org/jira/browse/INFRA-11000>
>> >> > > >>>>>
>> >> > > >>>>> -Flavio
>> >> > > >>>>>
>> >> > > >>>>>> On 08 Oct 2016, at 00:54, Benjamin Reed <br...@apache.org>
>> >> wrote:
>> >> > > >>>>>>
>> >> > > >>>>>> it doesn't look like we need to setup keys. this seems to
>> work
>> >> for
>> >> > > >>> me:
>> >> > > >>>>>>
>> >> > > >>>>>> https://git-wip-us.apache.org/#committers-getting-started
>> >> > > >>>>>>
>> >> > > >>>>>> it does seem strange that we aren't using public keys and
>> that
>> >> i'm
>> >> > > >>>>> sticking
>> >> > > >>>>>> a password in .netrc :P i'm wondering if other projects were
>> >> able
>> >> > to
>> >> > > >>>> get
>> >> > > >>>>>> this going over ssh.
>> >> > > >>>>>>
>> >> > > >>>>>> i'll take a whack at cleaning up the svn and subversion
>> >> > references.
>> >> > > >>>>>>
>> >> > > >>>>>> ben
>> >> > > >>>>>>
>> >> > > >>>>>> On Fri, Oct 7, 2016 at 12:59 PM, Camille Fournier <
>> >> > > >>> camille@apache.org>
>> >> > > >>>>>> wrote:
>> >> > > >>>>>>
>> >> > > >>>>>>> Hey folks,
>> >> > > >>>>>>>
>> >> > > >>>>>>> So I'm trying to get in a patch but this has not been
>> updated
>> >> to
>> >> > > >>> tell
>> >> > > >>>>>>> committers how to actually get the git keys set up:
>> >> > > >>>>>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
>> >> > > >>>>> Committing+changes
>> >> > > >>>>>>>
>> >> > > >>>>>>> Can someone float me a link that says how to do this?
>> >> > > >>>>>>>
>> >> > > >>>>>>> Also a bunch of our documentation still discusses SVN and
>> not
>> >> > git,
>> >> > > >>>> which
>> >> > > >>>>>>> means we are not done with this migration. If you were
>> pushing
>> >> > for
>> >> > > >>>> this
>> >> > > >>>>>>> change can you please do some due diligence on the wikis
>> and
>> >> > > >>> correct
>> >> > > >>>> the
>> >> > > >>>>>>> stuff that refers to SVN?
>> >> > > >>>>>>>
>> >> > > >>>>>>> Thanks,
>> >> > > >>>>>>> C
>> >> > > >>>>>>>
>> >> > > >>>>>>> On Wed, Oct 5, 2016 at 1:02 PM, Edward Ribeiro <
>> >> > > >>>>> edward.ribeiro@gmail.com>
>> >> > > >>>>>>> wrote:
>> >> > > >>>>>>>
>> >> > > >>>>>>>> Excuse me guys!
>> >> > > >>>>>>>>
>> >> > > >>>>>>>> I've written on Macbook Pro. No idea why GMail messed it
>> up.
>> >> I
>> >> > was
>> >> > > >>>> only
>> >> > > >>>>>>>> able to see the strange characters when I pasted on a gist
>> >> text
>> >> > > >>> area.
>> >> > > >>>>> The
>> >> > > >>>>>>>> previous message is below, but if anyone is still having
>> >> trouble
>> >> > > >>> (I
>> >> > > >>>>> tried
>> >> > > >>>>>>>> to remove the weird character), I left a copy at:
>> >> > > >>>>>>>> https://gist.github.com/eribei
>> ro/da2a6a6c9a508610d52d0755fae
>> >> 835
>> >> > 2d
>> >> > > >>>>>>>>
>> >> > > >>>>>>>> "Hi,
>> >> > > >>>>>>>>
>> >> > > >>>>>>>> The patch attached on ZOOKEEPER-2597 is a straightforward
>> >> > > >>> adaptation
>> >> > > >>>> of
>> >> > > >>>>>>>> Kafka's one. It takes care of merging Github PR into
>> Apache
>> >> git
>> >> > > >>> repo
>> >> > > >>>>> and
>> >> > > >>>>>>> a
>> >> > > >>>>>>>> subsequent closing of the PR on the GH side, among other
>> >> things
>> >> > > >>>>>>> (rewriting
>> >> > > >>>>>>>> of commit messages, etc). The current status is: the
>> script
>> >> > needs
>> >> > > >>> to
>> >> > > >>>> be
>> >> > > >>>>>>>> reviewed/validated by a committer. It has been some time
>> >> since I
>> >> > > >>>>> uploaded
>> >> > > >>>>>>>> the patch, so I gonna do another pass through it in the
>> >> > meantime.
>> >> > > >>>>>>>>
>> >> > > >>>>>>>> There are some workflow issues beyond the scope of
>> >> > ZOOKEEPER-2597
>> >> > > >>>> that
>> >> > > >>>>>>> need
>> >> > > >>>>>>>> to be sorted out (IMO):
>> >> > > >>>>>>>>
>> >> > > >>>>>>>> 1. The normal workflow is to open a JIRA ticket before
>> doing
>> >> any
>> >> > > >>> GH
>> >> > > >>>> PR,
>> >> > > >>>>>>>> that is, no JIRA-less PRs. The PR should have a title of
>> the
>> >> > form
>> >> > > >>>>>>>> "ZOOKEEPER-xxxx: Title". This will trigger the Apache
>> >> > JIRA-Github
>> >> > > >>>>>>>> integration and it's opening show up in the JIRA ticket.
>> >> > > >>>>>>>>
>> >> > > >>>>>>>> 2. OTOH, not every Kafka PR needs a corresponding JIRA
>> >> ticket.
>> >> > > >>> There
>> >> > > >>>>> are
>> >> > > >>>>>>> a
>> >> > > >>>>>>>> class of PRs with "MINOR" title that represent trivial
>> code
>> >> > > >>> changes
>> >> > > >>>> and
>> >> > > >>>>>>>> "HOT-FIX" title that fix urgent, but simple bugs. Both
>> bypass
>> >> > the
>> >> > > >>>> JIRA
>> >> > > >>>>>>>> creation step, even tough they are still subject to
>> review.
>> >> It's
>> >> > > >>>> worth
>> >> > > >>>>>>>> adopting a similar approach for ZK project?
>> >> > > >>>>>>>>
>> >> > > >>>>>>>> 3. IIRC (didn't find any page to confirm), Cassandra
>> project
>> >> > > >>>>> encourages,
>> >> > > >>>>>>>> but not demands, that contributors also upload a patch
>> file
>> >> to
>> >> > > >>> JIRA
>> >> > > >>>>> even
>> >> > > >>>>>>> in
>> >> > > >>>>>>>> the case of a GH PR (as to leave a audit trail, I guess).
>> >> Or, at
>> >> > > >>>>> least,
>> >> > > >>>>>>> C*
>> >> > > >>>>>>>> project leaves up to the contributors to either open a GH
>> PR
>> >> or
>> >> > > >>>> upload
>> >> > > >>>>>>> the
>> >> > > >>>>>>>> patch file to JIRA.
>> >> > > >>>>>>>>
>> >> > > >>>>>>>>
>> >> > > >>>>>>>> +1 about having a 'paper trail' of review comments on JIRA
>> >> > and/or
>> >> > > >>>>> mailing
>> >> > > >>>>>>>> list (I would prefer the mailing list tbh). But as Michael
>> >> and
>> >> > > >>> Flavio
>> >> > > >>>>>>>> pointed out, I never seen GH PR review **comments** being
>> >> > written
>> >> > > >>>> back
>> >> > > >>>>> to
>> >> > > >>>>>>>> JIRA, at least not in Kafka, Cassandra or Solr projects,
>> >> that I
>> >> > > >>> have
>> >> > > >>>>>>>> followed more closely.
>> >> > > >>>>>>>>
>> >> > > >>>>>>>> Eddie"
>> >> > > >>>>>>>>
>> >> > > >>>>>>>>
>> >> > > >>>>>>>> On Wed, Oct 5, 2016 at 1:35 PM, Michael Han <
>> >> hanm@cloudera.com>
>> >> > > >>>> wrote:
>> >> > > >>>>>>>>
>> >> > > >>>>>>>>> Eddie's mail contains lots of '=E2=80=8B'' which is
>> unicode
>> >> > > >>>> character
>> >> > > >>>>>>>>> zero-width space, which might cause parsing trouble for
>> some
>> >> > mail
>> >> > > >>>>>>>> clients.
>> >> > > >>>>>>>>>
>> >> > > >>>>>>>>> On Wed, Oct 5, 2016 at 6:42 AM, Flavio Junqueira <
>> >> > fpj@apache.org
>> >> > > >>>>
>> >> > > >>>>>>> wrote:
>> >> > > >>>>>>>>>
>> >> > > >>>>>>>>>> Dude, I'm just not able to parse your e-mail, did you
>> write
>> >> > that
>> >> > > >>>> on a
>> >> > > >>>>>>>>>> phone or something?
>> >> > > >>>>>>>>>>
>> >> > > >>>>>>>>>> -Flavio
>> >> > > >>>>>>>>>>
>> >> > > >>>>>>>>>>> On 05 Oct 2016, at 03:54, Edward Ribeiro <
>> >> > > >>>> edward.ribeiro@gmail.com
>> >> > > >>>>>>>>
>> >> > > >>>>>>>>>> wrote:
>> >> > > >>>>>>>>>>>
>> >> > > >>>>>>>>>>> Hi,
>> >> > > >>>>>>>>>>>
>> >> > > >>>>>>>>>>> The patch attached on ZOOKEEPER-2597 is a
>> >> > > >>>>>>>>>>> straightforward adaptation of
>> >> > > >>>>>>>>>>> Kafka's one. It takes care of merging Github PR into
>> >> Apache
>> >> > git
>> >> > > >>>>>>> repo
>> >> > > >>>>>>>>> and
>> >> > > >>>>>>>>>>>  a
>> >> > > >>>>>>>>>>> subsequent closing of the PR on the GH side
>> >> > > >>>>>>>>>>>  among other things (rewriting of commit messages,
>> etc)
>> >> > > >>>>>>>>>>> . The current status is: the script needs to be
>> >> > > >>> reviewed/validated
>> >> > > >>>>>>>> by a
>> >> > > >>>>>>>>>>> committer.
>> >> > > >>>>>>>>>>> It has been some time since I uploaded the patch, so I
>> >> gonna
>> >> > > >>> do
>> >> > > >>>>>>>>> another
>> >> > > >>>>>>>>>>> pass through it in the meantime.
>> >> > > >>>>>>>>>>>
>> >> > > >>>>>>>>>>>
>> >> > > >>>>>>>>>>> T
>> >> > > >>>>>>>>>>> here are some workflow issues beyond the scope of
>> >> > > >>> ZOOKEEPER-2597
>> >> > > >>>>>>>>>>>  that need to be sorted out (IMO)
>> >> > > >>>>>>>>>>> :
>> >> > > >>>>>>>>>>>
>> >> > > >>>>>>>>>>> 1. The normal workflow is to open a JIRA ticket before
>> >> doing
>> >> > > >>> any
>> >> > > >>>> GH
>> >> > > >>>>>>>> PR
>> >> > > >>>>>>>>>>> , that is, no JIRA-less PRs.
>> >> > > >>>>>>>>>>> The PR should have a title of the form "ZOOKEEPER-xxxx:
>> >> > Title".
>> >> > > >>>>>>> This
>> >> > > >>>>>>>>> will
>> >> > > >>>>>>>>>>> trigger the Apache JIRA-Github integration and it's
>> >> opening
>> >> > > >>> show
>> >> > > >>>> up
>> >> > > >>>>>>>> in
>> >> > > >>>>>>>>>> the
>> >> > > >>>>>>>>>>> JIRA ticket.
>> >> > > >>>>>>>>>>>
>> >> > > >>>>>>>>>>> 2.
>> >> > > >>>>>>>>>>> OTOH, n
>> >> > > >>>>>>>>>>> ot every Kafka PR needs a corresponding JIRA ticket
>> >> > > >>>>>>>>>>> . 
>> >> > > >>>>>>>>>>> There are a class of PR
>> >> > > >>>>>>>>>>> s
>> >> > > >>>>>>>>>>> with "MINOR"
>> >> > > >>>>>>>>>>>  title
>> >> > > >>>>>>>>>>> that represent trivial code changes
>> >> > > >>>>>>>>>>>  and "HOT-FIX" title that fix urgent, but simple bugs.
>> >> Both
>> >> > > >>>>>>>>>>> bypass the JIRA creation step
>> >> > > >>>>>>>>>>> , even tough they are still 
>> >> > > >>>>>>>>>>> subject to review
>> >> > > >>>>>>>>>>> .
>> >> > > >>>>>>>>>>> It's worth adopting a similar approach for ZK project?
>> >> > > >>>>>>>>>>>
>> >> > > >>>>>>>>>>> 3. IIRC
>> >> > > >>>>>>>>>>>  (didn't find any page to confirm)
>> >> > > >>>>>>>>>>> , Cassandra project encourages, but not demands, that
>> >> > > >>> contributors
>> >> > > >>>>>>>> also
>> >> > > >>>>>>>>>>> upload a patch file to JIRA even in the case of a GH PR
>> >> > > >>>>>>>>>>>  (as to leave a audit trail, I guess)
>> >> > > >>>>>>>>>>> .
>> >> > > >>>>>>>>>>> Or
>> >> > > >>>>>>>>>>> ,
>> >> > > >>>>>>>>>>> at
>> >> > > >>>>>>>>>>>  
>> >> > > >>>>>>>>>>> least
>> >> > > >>>>>>>>>>> ,
>> >> > > >>>>>>>>>>> C* project 
>> >> > > >>>>>>>>>>> leave
>> >> > > >>>>>>>>>>> s
>> >> > > >>>>>>>>>>> up to the contributor
>> >> > > >>>>>>>>>>> s
>> >> > > >>>>>>>>>>> to either open a GH PR or upload the patch file
>> >> > > >>>>>>>>>>>  to JIRA. In fact, Github allows the access to a raw
>> >> patch
>> >> > or
>> >> > > >>>>>>> diff,
>> >> > > >>>>>>>>> it's
>> >> > > >>>>>>>>>>> just a matter of adding the ".patch" or ".diff" suffix
>> to
>> >> the
>> >> > > >>> end
>> >> > > >>>>>>> of
>> >> > > >>>>>>>>> the
>> >> > > >>>>>>>>>>> Pull Request URL.
>> >> > > >>>>>>>>>>> 
>> >> > > >>>>>>>>>>>
>> >> > > >>>>>>>>>>>
>> >> > > >>>>>>>>>>> +1 about having a 'paper trail'
>> >> > > >>>>>>>>>>>  of review comments
>> >> > > >>>>>>>>>>>
>> >> > > >>>>>>>>>>> o
>> >> > > >>>>>>>>>>> n JIRA and
>> >> > > >>>>>>>>>>> /or
>> >> > > >>>>>>>>>>> mailing list (I
>> >> > > >>>>>>>>>>>  would
>> >> > > >>>>>>>>>>> prefer the mailing list tbh). But as Michael and Flavio
>> >> > pointed
>> >> > > >>>>>>> out,
>> >> > > >>>>>>>> I
>> >> > > >>>>>>>>>>> never seen
>> >> > > >>>>>>>>>>> GH 
>> >> > > >>>>>>>>>>> PR review
>> >> > > >>>>>>>>>>> **
>> >> > > >>>>>>>>>>> comments
>> >> > > >>>>>>>>>>> **
>> >> > > >>>>>>>>>>> being written back to JIRA, at least not in Kafka,
>> >> Cassandra
>> >> > > >>>>>>>>>>> or
>> >> > > >>>>>>>>>>> Solr projects
>> >> > > >>>>>>>>>>> , that I have followed more closely.
>> >> > > >>>>>>>>>>>
>> >> > > >>>>>>>>>>> Eddie
>> >> > > >>>>>>>>>>>
>> >> > > >>>>>>>>>>>
>> >> > > >>>>>>>>>>> On Tue, Oct 4, 2016 at 6:40 PM, Michael Han <
>> >> > hanm@cloudera.com
>> >> > > >>>>
>> >> > > >>>>>>>> wrote:
>> >> > > >>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>> as long as the opening/closing/commenting all get
>> sent
>> >> to
>> >> > > >>> the
>> >> > > >>>>>>>>> mailing
>> >> > > >>>>>>>>>>>> list or recorded in jira
>> >> > > >>>>>>>>>>>> Yeah, this is my impression as well, that we need to
>> keep
>> >> > > >>> certain
>> >> > > >>>>>>>>> paper
>> >> > > >>>>>>>>>>>> trail regarding activities and comments on ASF side
>> >> (JIRA or
>> >> > > >>> mail
>> >> > > >>>>>>>>> list).
>> >> > > >>>>>>>>>>>> Infra page said:
>> >> > > >>>>>>>>>>>>
>> >> > > >>>>>>>>>>>> - Any Pull Request that gets opened, closed, reopened
>> or
>> >> > > >>>>>>>>> **commented**
>> >> > > >>>>>>>>>>>> on now gets recorded on the project's mailing list
>> >> > > >>>>>>>>>>>> - If a project has a JIRA instance, any PRs or
>> >> *comments* on
>> >> > > >>> PRs
>> >> > > >>>>>>>>> that
>> >> > > >>>>>>>>>>>> include a JIRA ticket ID will trigger an update on
>> that
>> >> > > >>> specific
>> >> > > >>>>>>>>>> ticket
>> >> > > >>>>>>>>>>>>
>> >> > > >>>>>>>>>>>> I checked a couple Kafka and Spark JIRAs but I don't
>> see
>> >> any
>> >> > > >>> of
>> >> > > >>>>>>> the
>> >> > > >>>>>>>>>>>> comments made in github PR were posted on JIRA, except
>> >> the
>> >> > > >>>>>>>> activities
>> >> > > >>>>>>>>>> (open
>> >> > > >>>>>>>>>>>> a PR, close a PR). Since both projects have been using
>> >> > github
>> >> > > >>> for
>> >> > > >>>>>>> a
>> >> > > >>>>>>>>>> while I
>> >> > > >>>>>>>>>>>> assume such practice of NOT integrating comments
>> between
>> >> > > >>> github
>> >> > > >>>>>>> and
>> >> > > >>>>>>>>> ASF
>> >> > > >>>>>>>>>>>> JIRA is acceptable? Though I feel it would be really
>> >> useful
>> >> > if
>> >> > > >>>>>>>>> comments
>> >> > > >>>>>>>>>>>> could converge in a single place as well, that will
>> >> provide
>> >> > a
>> >> > > >>>>>>> clear
>> >> > > >>>>>>>>>> history
>> >> > > >>>>>>>>>>>> for a given technical issue.
>> >> > > >>>>>>>>>>>>
>> >> > > >>>>>>>>>>>> On Tue, Oct 4, 2016 at 12:06 PM, Flavio Junqueira <
>> >> > > >>>> fpj@apache.org
>> >> > > >>>>>>>>
>> >> > > >>>>>>>>>> wrote:
>> >> > > >>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>> Until ZOOKEEPER-2597 <https://issues.apache.org/
>> >> > > >>>>>>>>>>>> jira/browse/ZOOKEEPER-2597>
>> >> > > >>>>>>>>>>>>> is fixed, we can't merge via github.
>> >> > > >>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>> For code reviews, we can use GH as long as the
>> >> > > >>>>>>>>>> opening/closing/commenting
>> >> > > >>>>>>>>>>>>> all get sent to the mailing list or recorded in
>> jira. I
>> >> > don't
>> >> > > >>>>>>> think
>> >> > > >>>>>>>>> we
>> >> > > >>>>>>>>>>>> have
>> >> > > >>>>>>>>>>>>> that yet, but it is possible according to this:
>> >> > > >>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>> https://blogs.apache.org/infra/entry/improved_
>> >> > > >>>>>>>>>>>>> integration_between_apache_and <
>> >> https://blogs.apache.org/
>> >> > > >>>>>>>>>>>>> infra/entry/improved_integration_between_apache_and>
>> >> > > >>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>> For now, we do need to upload patches and converge
>> using
>> >> > > >>> jira.
>> >> > > >>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>> I think Eddie has been looking at this process
>> trying to
>> >> > > >>>>>>> replicate
>> >> > > >>>>>>>>> the
>> >> > > >>>>>>>>>>>>> Kafka setup, so perhaps he can give an update if I'm
>> >> right.
>> >> > > >>>> Kafka
>> >> > > >>>>>>>>>> doesn't
>> >> > > >>>>>>>>>>>>> send every comment to the mailing list, though, but
>> I'm
>> >> not
>> >> > > >>> sure
>> >> > > >>>>>>> if
>> >> > > >>>>>>>>>>>> that's
>> >> > > >>>>>>>>>>>>> acceptable according to the ASF, I need to
>> double-check.
>> >> > > >>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>> -Flavio
>> >> > > >>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>> On 04 Oct 2016, at 19:42, Michael Han <
>> >> hanm@cloudera.com>
>> >> > > >>>>>>> wrote:
>> >> > > >>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>> Hi,
>> >> > > >>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>> Now we've moved to git, what is the policy for
>> >> uploading
>> >> > > >>>> patches
>> >> > > >>>>>>>> and
>> >> > > >>>>>>>>>>>>> doing
>> >> > > >>>>>>>>>>>>>> code reviews? I am asking because I've seen recently
>> >> there
>> >> > > >>> are
>> >> > > >>>>>>> git
>> >> > > >>>>>>>>>> pull
>> >> > > >>>>>>>>>>>>>> requests coming in without associated patch file
>> >> uploaded
>> >> > to
>> >> > > >>>>>>> JIRA.
>> >> > > >>>>>>>>>> I've
>> >> > > >>>>>>>>>>>>>> checked
>> >> > > >>>>>>>>>>>>>> https://cwiki.apache.org/confl
>> uence/display/ZOOKEEPER/
>> >> > > >>>>>>>>> HowToContribute
>> >> > > >>>>>>>>>> ,
>> >> > > >>>>>>>>>>>>>> looks like there is not much change regarding patch
>> >> > process
>> >> > > >>> -
>> >> > > >>>> so
>> >> > > >>>>>>>>>>>>> presumably
>> >> > > >>>>>>>>>>>>>> we still need to generate and upload patch file to
>> JIRA
>> >> > for
>> >> > > >>> the
>> >> > > >>>>>>>>>> record,
>> >> > > >>>>>>>>>>>>>> while using github (maybe in addition of review
>> board,
>> >> or
>> >> > in
>> >> > > >>>> the
>> >> > > >>>>>>>>>> future
>> >> > > >>>>>>>>>>>>>> with gerrit) to do code reviews?
>> >> > > >>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>> On Wed, Sep 21, 2016 at 6:05 AM, Edward Ribeiro <
>> >> > > >>>>>>>>>>>>> edward.ribeiro@gmail.com>
>> >> > > >>>>>>>>>>>>>> wrote:
>> >> > > >>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>> Cool, just open https://issues.apache.org/
>> >> > > >>>>>>>>> jira/browse/ZOOKEEPER-2597
>> >> > > >>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>> PS: I removed the REPO_HOME global variable.
>> >> > > >>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>> On Wed, Sep 21, 2016 at 6:53 AM, Flavio Junqueira <
>> >> > > >>>>>>>> fpj@apache.org>
>> >> > > >>>>>>>>>>>>> wrote:
>> >> > > >>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>> Better to have that in the form of a pull request
>> or
>> >> > diff.
>> >> > > >>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>> REPO_HOME does seem to be unused.
>> >> > > >>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>> -Flavio
>> >> > > >>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>> On 20 Sep 2016, at 18:57, Edward Ribeiro <
>> >> > > >>>>>>>>> edward.ribeiro@gmail.com
>> >> > > >>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>> wrote:
>> >> > > >>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>> Hey, I have started porting the kafka-merge.py to
>> >> work
>> >> > > >>> on ZK
>> >> > > >>>>>>>>> repos.
>> >> > > >>>>>>>>>>>> I
>> >> > > >>>>>>>>>>>>>>>> would
>> >> > > >>>>>>>>>>>>>>>>> need someone to review it and help me test it
>> now.
>> >> > > >>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>> The files were uploaded below, but I will create
>> a
>> >> > github
>> >> > > >>>>>>> repo
>> >> > > >>>>>>>>> yet
>> >> > > >>>>>>>>>>>>>>> today.
>> >> > > >>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>> https://www.dropbox.com/sh/od8bet2574jttm3/
>> >> > > >>>>>>>>>>>>>>>> AADv1DXTb8vfyVCmelFbYCEha?dl=0
>> >> > > >>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>> I uploaded the kafka version script so that you
>> can
>> >> use
>> >> > > >>> diff
>> >> > > >>>>>>> or
>> >> > > >>>>>>>>>> Meld
>> >> > > >>>>>>>>>>>>> to
>> >> > > >>>>>>>>>>>>>>>>> spot my changes, but feel free to grasp the
>> original
>> >> > file
>> >> > > >>>>>>> here:
>> >> > > >>>>>>>>>>>>>>>>> https://github.com/apache/
>> >> > kafka/blob/trunk/kafka-merge-
>> >> > > >>>> pr.py
>> >> > > >>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>> PS: It's just me or REPO_HOME env variable is not
>> >> used
>> >> > > >>>>>>> anywhere
>> >> > > >>>>>>>>> in
>> >> > > >>>>>>>>>>>> the
>> >> > > >>>>>>>>>>>>>>>>> merge script???
>> >> > > >>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>> Cheers,
>> >> > > >>>>>>>>>>>>>>>>> Eddie
>> >> > > >>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick Hunt <
>> >> > > >>>>>>>> phunt@apache.org
>> >> > > >>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>> wrote:
>> >> > > >>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin Reed <
>> >> > > >>>>>>>>> breed@apache.org>
>> >> > > >>>>>>>>>>>>>>>> wrote:
>> >> > > >>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>>> what you are suggesting sounds good, but i
>> don't
>> >> know
>> >> > > >>> how
>> >> > > >>>>>>> to
>> >> > > >>>>>>>> do
>> >> > > >>>>>>>>>>>> it?
>> >> > > >>>>>>>>>>>>>>>> since
>> >> > > >>>>>>>>>>>>>>>>>>> in the end we are still just accepting diffs on
>> >> > > >>> patches,
>> >> > > >>>>>>> the
>> >> > > >>>>>>>>> only
>> >> > > >>>>>>>>>>>>>>> thing
>> >> > > >>>>>>>>>>>>>>>>>>> that changes is that we use svn rather than git
>> >> > right?
>> >> > > >>>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>> Notice the workflow Kafka uses - which includes
>> >> "git
>> >> > > >>> apply"
>> >> > > >>>>>>>> and
>> >> > > >>>>>>>>>>>>>>>> specifying
>> >> > > >>>>>>>>>>>>>>>>>> the author tag when committers commit (so that
>> the
>> >> OP
>> >> > > >>> gets
>> >> > > >>>>>>>>> proper
>> >> > > >>>>>>>>>>>>>>>>>> attribution in the commit itself)
>> >> > > >>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>> https://cwiki.apache.org/confl
>> uence/display/KAFKA/
>> >> > > >>>>>>>>>>>>>>>> Manual+Commit+Workflow
>> >> > > >>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>> Patrick
>> >> > > >>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>>> i LOVE chris's idea! lets do it!
>> >> > > >>>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>>> ben
>> >> > > >>>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>>> On Sun, Sep 18, 2016 at 3:22 PM, Patrick Hunt <
>> >> > > >>>>>>>>> phunt@apache.org>
>> >> > > >>>>>>>>>>>>>>>> wrote:
>> >> > > >>>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>>>> Ben, do you also want to update the "Applying
>> a
>> >> > patch"
>> >> > > >>>>>>>> section
>> >> > > >>>>>>>>>> to
>> >> > > >>>>>>>>>>>>>>> make
>> >> > > >>>>>>>>>>>>>>>>>> it
>> >> > > >>>>>>>>>>>>>>>>>>>> git specific?
>> >> > > >>>>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>>>> We (committers) should move to a model where
>> >> authors
>> >> > > >>> get
>> >> > > >>>>>>>>> proper
>> >> > > >>>>>>>>>>>>>>> credit
>> >> > > >>>>>>>>>>>>>>>>>> in
>> >> > > >>>>>>>>>>>>>>>>>>>> git. Our old workflow in svn resulted in only
>> the
>> >> > > >>>>>>> committer
>> >> > > >>>>>>>>>> being
>> >> > > >>>>>>>>>>>>>>>>>> listed
>> >> > > >>>>>>>>>>>>>>>>>>>> (except that we listed the patch author in the
>> >> > commit
>> >> > > >>>>>>>>> message).
>> >> > > >>>>>>>>>>>> We
>> >> > > >>>>>>>>>>>>>>>>>> should
>> >> > > >>>>>>>>>>>>>>>>>>>> move to a model where the author of the patch
>> >> gets
>> >> > > >>> proper
>> >> > > >>>>>>>>> credit
>> >> > > >>>>>>>>>>>> in
>> >> > > >>>>>>>>>>>>>>>>>> git.
>> >> > > >>>>>>>>>>>>>>>>>>> I
>> >> > > >>>>>>>>>>>>>>>>>>>> believe we will get that if we use git for
>> patch
>> >> > > >>>>>>>>>>>>>>> creation/application?
>> >> > > >>>>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>>>> Chris brought up getting rid of CHANGES.txt
>> >> recently
>> >> > > >>> on
>> >> > > >>>>>>> the
>> >> > > >>>>>>>>> dev
>> >> > > >>>>>>>>>>>>> list
>> >> > > >>>>>>>>>>>>>>>>>> in a
>> >> > > >>>>>>>>>>>>>>>>>>>> separate thread - Chris do you want to
>> implement
>> >> > that
>> >> > > >>>>>>> change
>> >> > > >>>>>>>>> now
>> >> > > >>>>>>>>>>>>>>> that
>> >> > > >>>>>>>>>>>>>>>>>>> we've
>> >> > > >>>>>>>>>>>>>>>>>>>> moved to git?
>> >> > > >>>>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>>>> Patrick
>> >> > > >>>>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>>>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin
>> Reed <
>> >> > > >>>>>>>>>> breed@apache.org
>> >> > > >>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>> wrote:
>> >> > > >>>>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>>>>>> 1) actually in the previous step that was
>> just
>> >> > > >>> adding
>> >> > > >>>>>>> new
>> >> > > >>>>>>>>>>>> files.
>> >> > > >>>>>>>>>>>>>>> you
>> >> > > >>>>>>>>>>>>>>>>>>>>>> still
>> >> > > >>>>>>>>>>>>>>>>>>>>>>> need the commit -a for the rest of the
>> >> changes.
>> >> > > >>> that's
>> >> > > >>>>>>> my
>> >> > > >>>>>>>>>>>> normal
>> >> > > >>>>>>>>>>>>>>>>>>>>>> workflow.
>> >> > > >>>>>>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>>>>>> I think that will be confusing for most
>> folks.
>> >> > They
>> >> > > >>>>>>>>> typically
>> >> > > >>>>>>>>>>>>>>> stage
>> >> > > >>>>>>>>>>>>>>>>>>>>>> all the changes and then commit or don't
>> stage
>> >> and
>> >> > > >>> use
>> >> > > >>>>>>> -a.
>> >> > > >>>>>>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>>>>> do you mind fixing it with your workflow.
>> >> commit -a
>> >> > > >>>>>>> doesn't
>> >> > > >>>>>>>>> get
>> >> > > >>>>>>>>>>>>> new
>> >> > > >>>>>>>>>>>>>>>>>>>>> files, which is why you need to do the add,
>> but
>> >> i'm
>> >> > > >>> not
>> >> > > >>>>>>> the
>> >> > > >>>>>>>>>> most
>> >> > > >>>>>>>>>>>>>>>>>>>>> sophisticated git user, so
>> >> > > >>>>>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>>>>>>> 2) i figured since we are using git now
>> that
>> >> we
>> >> > > >>> should
>> >> > > >>>>>>>> use
>> >> > > >>>>>>>>>>>> git's
>> >> > > >>>>>>>>>>>>>>>>>>>>>> default.
>> >> > > >>>>>>>>>>>>>>>>>>>>>>> the patch should work (by default it seems
>> to
>> >> > strip
>> >> > > >>>> the
>> >> > > >>>>>>>>> first
>> >> > > >>>>>>>>>>>>>>> path
>> >> > > >>>>>>>>>>>>>>>>>>>>>> element).
>> >> > > >>>>>>>>>>>>>>>>>>>>>>> does it not work for you?
>> >> > > >>>>>>>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>>>>>> It will fail precommit in it's current
>> state.
>> >> > > >>>>>>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>>>>> fixed
>> >> > > >>>>>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>> --
>> >> > > >>>>>>>>>>>>>> Cheers
>> >> > > >>>>>>>>>>>>>> Michael.
>> >> > > >>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>
>> >> > > >>>>>>>>>>>>
>> >> > > >>>>>>>>>>>> --
>> >> > > >>>>>>>>>>>> Cheers
>> >> > > >>>>>>>>>>>> Michael.
>> >> > > >>>>>>>>>>>>
>> >> > > >>>>>>>>>>
>> >> > > >>>>>>>>>>
>> >> > > >>>>>>>>>
>> >> > > >>>>>>>>>
>> >> > > >>>>>>>>> --
>> >> > > >>>>>>>>> Cheers
>> >> > > >>>>>>>>> Michael.
>> >> > > >>>>>>>>>
>> >> > > >>>>>>>>
>> >> > > >>>>>>>
>> >> > > >>>>>
>> >> > > >>>>>
>> >> > > >>>>
>> >> > > >>>>
>> >> > > >>>> --
>> >> > > >>>> Cheers
>> >> > > >>>> Michael.
>> >> > > >>>>
>> >> > > >>>
>> >> > > >>
>> >> > > >>
>> >> > > >>
>> >> > > >> --
>> >> > > >> Cheers
>> >> > > >> Michael.
>> >> > > >>
>> >> > > >
>> >> > > >
>> >> > > >
>> >> > > > --
>> >> > > > Cheers
>> >> > > > Michael.
>> >> > >
>> >> > >
>> >> >
>> >>
>> >
>>
>
>

Re: [VOTE] move Apache Zookeeper to git

Posted by Patrick Hunt <ph...@apache.org>.

Thanks Edward, this should be very helpful for folks. I committed, however
I notice the PR is still open. I followed the steps here:
https://cwiki.apache.org/confluence/display/ZOOKEEPER/Committing+changes
however I don't see a way to close the PR?
https://github.com/apache/zookeeper/pull/103 says I don't have "write
access".

Patrick

On Thu, Nov 10, 2016 at 10:23 AM, Edward Ribeiro <ed...@gmail.com>
wrote:

> Hi Patrick,
>
> I've just opened a PR  https://github.com/apache/zookeeper/pull/103/ PR
>
> It asks for JIRA_PASSWORD at CLI prompt *IF* it's absent but JIRA_USERNAME
> is already set. Please, when you have time, see if it fits what you need
> and then I can open a JIRA, rename the feature branch, etc.
>
> Let me know if you have other ideas. I am open to other ways of
> incorporating the passing of JIRA_PASSWORD too.
>
> Edward
>
> On Wed, Nov 9, 2016 at 5:03 PM, Edward Ribeiro <ed...@gmail.com>
> wrote:
>
> > Hi Patrick,
> >
> > We can change the script so that it asks for jira password input on CLI
> > prompt if the JIRA username is set, for example. The change should be
> > straigthforward.
> >
> > Alternatively, the python systems I have dealt with put credentials for
> > database access, etc, in configuration -- sometimes hidden -- files (say,
> > .env), but yet it is clear text stored.
> >
> > Anyone has other suggestions?
> >
> > Eddie
> >
> > Em 9 de nov de 2016 4:18 PM, "Patrick Hunt" <ph...@apache.org> escreveu:
> >
> >> Is there any alternative to step 4 as documented here?
> >> https://cwiki.apache.org/confluence/display/ZOOKEEPER/Mergin
> >> g+Github+Pull+Requests
> >>
> >> specifically it's asking to "export JIRA_PASSWORD=mypassword" which I
> feel
> >> very uncomfortable doing.
> >>
> >> Patrick
> >>
> >> On Wed, Oct 26, 2016 at 11:12 AM, Edward Ribeiro <
> >> edward.ribeiro@gmail.com>
> >> wrote:
> >>
> >> > AFAIK, yes. I say, if you mean to run unit tests and other CI tasks on
> >> PR.
> >> >
> >> > PS: I have just created a simple script HowTo at
> >> > https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> >> > Merging+Github+Pull+Requests
> >> > and linked from https://cwiki.apache.org/
> confluence/display/ZOOKEEPER/
> >> > Index
> >> >
> >> > On Wed, Oct 26, 2016 at 3:59 PM, Flavio Junqueira <fp...@apache.org>
> >> wrote:
> >> >
> >> > > What about QA, are we still missing a github pre-commit queue?
> >> > >
> >> > > -Flavio
> >> > >
> >> > > > On 26 Oct 2016, at 18:53, Michael Han <ha...@cloudera.com> wrote:
> >> > > >
> >> > > > The comment bridging should be fixed now - see INFRA-12752 for
> more
> >> > > > details.
> >> > > >
> >> > > > On Wed, Oct 26, 2016 at 10:03 AM, Michael Han <ha...@cloudera.com>
> >> > wrote:
> >> > > >
> >> > > >>>> The git PR *review* comments for ZOOKEEPER-2597 didn't show up
> on
> >> > > JIRA.
> >> > > >>
> >> > > >> The bridge was working the day Infra made the change - see the
> >> > previous
> >> > > >> comments made by git bot on ZOOKEEPER-761. Now it seems stop
> >> working.
> >> > I
> >> > > am
> >> > > >> reopening INFRA-12752 and building a case.
> >> > > >>
> >> > > >> On Wed, Oct 26, 2016 at 9:45 AM, Edward Ribeiro <
> >> > > edward.ribeiro@gmail.com>
> >> > > >> wrote:
> >> > > >>
> >> > > >>> Dear community,
> >> > > >>>
> >> > > >>> The zk-merger-pr.py script has been merged into master (thanks a
> >> LOT
> >> > > Ben
> >> > > >>> Reed for reviewing/discussing/testing and commiting):
> >> > > >>> https://issues.apache.org/jira/browse/ZOOKEEPER-2597
> >> > > >>>
> >> > > >>> As stated in the issue and on GH, this tool is a modified
> version
> >> of
> >> > > >>> similar tools from Kafka, that is a copy of a Spark's one. It
> has
> >> > some
> >> > > >>> rough edges so we will certainly benefit from further
> enhancements
> >> > and
> >> > > >>> fixes. I changed the smallest possible pieces of code, just to
> >> make
> >> > it
> >> > > >>> work
> >> > > >>> on a ZK repo so the credits go to the original authors.
> >> > > >>>
> >> > > >>> Some notes:
> >> > > >>>
> >> > > >>> 1. The git PR *review* comments for ZOOKEEPER-2597 didn't show
> up
> >> on
> >> > > JIRA.
> >> > > >>> Only the opening and closing of the issue. Can we double check
> >> this
> >> > as
> >> > > >>> INFRA-12752 is closed, Michael Han?
> >> > > >>>
> >> > > >>> 2. I scribbled a draft on how use the tool at
> >> > > >>> https://docs.google.com/document/d/1i00ZXjrW2fu17vr_h7F1bUrq
> >> > > >>> Xg3urw4Hm7KirQDpPIU/edit
> >> > > >>> (still very crude, but feel free to improve it). I would like to
> >> move
> >> > > >>> this
> >> > > >>> text to https://cwiki.apache.org/confl
> >> uence/display/ZOOKEEPER/Index
> >> > > but
> >> > > >>> looks like I don't have permission to create a page there yet.
> Any
> >> > > help?
> >> > > >>>
> >> > > >>> Best regards,
> >> > > >>> Eddie
> >> > > >>>
> >> > > >>> On Sat, Oct 22, 2016 at 7:08 PM, Michael Han <hanm@cloudera.com
> >
> >> > > wrote:
> >> > > >>>
> >> > > >>>> FYI infra did some work in INFRA-12752 and the git PR comments
> >> can
> >> > be
> >> > > >>>> pushed to Apache JIRA.
> >> > > >>>>
> >> > > >>>> On Sat, Oct 8, 2016 at 8:01 AM, Flavio Junqueira <
> fpj@apache.org
> >> >
> >> > > >>> wrote:
> >> > > >>>>
> >> > > >>>>> This is not supported at the moment if nothing has changed:
> >> > > >>>>>
> >> > > >>>>> https://issues.apache.org/jira/browse/INFRA-11000 <
> >> > > >>>>> https://issues.apache.org/jira/browse/INFRA-11000>
> >> > > >>>>>
> >> > > >>>>> -Flavio
> >> > > >>>>>
> >> > > >>>>>> On 08 Oct 2016, at 00:54, Benjamin Reed <br...@apache.org>
> >> wrote:
> >> > > >>>>>>
> >> > > >>>>>> it doesn't look like we need to setup keys. this seems to
> work
> >> for
> >> > > >>> me:
> >> > > >>>>>>
> >> > > >>>>>> https://git-wip-us.apache.org/#committers-getting-started
> >> > > >>>>>>
> >> > > >>>>>> it does seem strange that we aren't using public keys and
> that
> >> i'm
> >> > > >>>>> sticking
> >> > > >>>>>> a password in .netrc :P i'm wondering if other projects were
> >> able
> >> > to
> >> > > >>>> get
> >> > > >>>>>> this going over ssh.
> >> > > >>>>>>
> >> > > >>>>>> i'll take a whack at cleaning up the svn and subversion
> >> > references.
> >> > > >>>>>>
> >> > > >>>>>> ben
> >> > > >>>>>>
> >> > > >>>>>> On Fri, Oct 7, 2016 at 12:59 PM, Camille Fournier <
> >> > > >>> camille@apache.org>
> >> > > >>>>>> wrote:
> >> > > >>>>>>
> >> > > >>>>>>> Hey folks,
> >> > > >>>>>>>
> >> > > >>>>>>> So I'm trying to get in a patch but this has not been
> updated
> >> to
> >> > > >>> tell
> >> > > >>>>>>> committers how to actually get the git keys set up:
> >> > > >>>>>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> >> > > >>>>> Committing+changes
> >> > > >>>>>>>
> >> > > >>>>>>> Can someone float me a link that says how to do this?
> >> > > >>>>>>>
> >> > > >>>>>>> Also a bunch of our documentation still discusses SVN and
> not
> >> > git,
> >> > > >>>> which
> >> > > >>>>>>> means we are not done with this migration. If you were
> pushing
> >> > for
> >> > > >>>> this
> >> > > >>>>>>> change can you please do some due diligence on the wikis and
> >> > > >>> correct
> >> > > >>>> the
> >> > > >>>>>>> stuff that refers to SVN?
> >> > > >>>>>>>
> >> > > >>>>>>> Thanks,
> >> > > >>>>>>> C
> >> > > >>>>>>>
> >> > > >>>>>>> On Wed, Oct 5, 2016 at 1:02 PM, Edward Ribeiro <
> >> > > >>>>> edward.ribeiro@gmail.com>
> >> > > >>>>>>> wrote:
> >> > > >>>>>>>
> >> > > >>>>>>>> Excuse me guys!
> >> > > >>>>>>>>
> >> > > >>>>>>>> I've written on Macbook Pro. No idea why GMail messed it
> up.
> >> I
> >> > was
> >> > > >>>> only
> >> > > >>>>>>>> able to see the strange characters when I pasted on a gist
> >> text
> >> > > >>> area.
> >> > > >>>>> The
> >> > > >>>>>>>> previous message is below, but if anyone is still having
> >> trouble
> >> > > >>> (I
> >> > > >>>>> tried
> >> > > >>>>>>>> to remove the weird character), I left a copy at:
> >> > > >>>>>>>> https://gist.github.com/eribeiro/
> da2a6a6c9a508610d52d0755fae
> >> 835
> >> > 2d
> >> > > >>>>>>>>
> >> > > >>>>>>>> "Hi,
> >> > > >>>>>>>>
> >> > > >>>>>>>> The patch attached on ZOOKEEPER-2597 is a straightforward
> >> > > >>> adaptation
> >> > > >>>> of
> >> > > >>>>>>>> Kafka's one. It takes care of merging Github PR into Apache
> >> git
> >> > > >>> repo
> >> > > >>>>> and
> >> > > >>>>>>> a
> >> > > >>>>>>>> subsequent closing of the PR on the GH side, among other
> >> things
> >> > > >>>>>>> (rewriting
> >> > > >>>>>>>> of commit messages, etc). The current status is: the script
> >> > needs
> >> > > >>> to
> >> > > >>>> be
> >> > > >>>>>>>> reviewed/validated by a committer. It has been some time
> >> since I
> >> > > >>>>> uploaded
> >> > > >>>>>>>> the patch, so I gonna do another pass through it in the
> >> > meantime.
> >> > > >>>>>>>>
> >> > > >>>>>>>> There are some workflow issues beyond the scope of
> >> > ZOOKEEPER-2597
> >> > > >>>> that
> >> > > >>>>>>> need
> >> > > >>>>>>>> to be sorted out (IMO):
> >> > > >>>>>>>>
> >> > > >>>>>>>> 1. The normal workflow is to open a JIRA ticket before
> doing
> >> any
> >> > > >>> GH
> >> > > >>>> PR,
> >> > > >>>>>>>> that is, no JIRA-less PRs. The PR should have a title of
> the
> >> > form
> >> > > >>>>>>>> "ZOOKEEPER-xxxx: Title". This will trigger the Apache
> >> > JIRA-Github
> >> > > >>>>>>>> integration and it's opening show up in the JIRA ticket.
> >> > > >>>>>>>>
> >> > > >>>>>>>> 2. OTOH, not every Kafka PR needs a corresponding JIRA
> >> ticket.
> >> > > >>> There
> >> > > >>>>> are
> >> > > >>>>>>> a
> >> > > >>>>>>>> class of PRs with "MINOR" title that represent trivial code
> >> > > >>> changes
> >> > > >>>> and
> >> > > >>>>>>>> "HOT-FIX" title that fix urgent, but simple bugs. Both
> bypass
> >> > the
> >> > > >>>> JIRA
> >> > > >>>>>>>> creation step, even tough they are still subject to review.
> >> It's
> >> > > >>>> worth
> >> > > >>>>>>>> adopting a similar approach for ZK project?
> >> > > >>>>>>>>
> >> > > >>>>>>>> 3. IIRC (didn't find any page to confirm), Cassandra
> project
> >> > > >>>>> encourages,
> >> > > >>>>>>>> but not demands, that contributors also upload a patch file
> >> to
> >> > > >>> JIRA
> >> > > >>>>> even
> >> > > >>>>>>> in
> >> > > >>>>>>>> the case of a GH PR (as to leave a audit trail, I guess).
> >> Or, at
> >> > > >>>>> least,
> >> > > >>>>>>> C*
> >> > > >>>>>>>> project leaves up to the contributors to either open a GH
> PR
> >> or
> >> > > >>>> upload
> >> > > >>>>>>> the
> >> > > >>>>>>>> patch file to JIRA.
> >> > > >>>>>>>>
> >> > > >>>>>>>>
> >> > > >>>>>>>> +1 about having a 'paper trail' of review comments on JIRA
> >> > and/or
> >> > > >>>>> mailing
> >> > > >>>>>>>> list (I would prefer the mailing list tbh). But as Michael
> >> and
> >> > > >>> Flavio
> >> > > >>>>>>>> pointed out, I never seen GH PR review **comments** being
> >> > written
> >> > > >>>> back
> >> > > >>>>> to
> >> > > >>>>>>>> JIRA, at least not in Kafka, Cassandra or Solr projects,
> >> that I
> >> > > >>> have
> >> > > >>>>>>>> followed more closely.
> >> > > >>>>>>>>
> >> > > >>>>>>>> Eddie"
> >> > > >>>>>>>>
> >> > > >>>>>>>>
> >> > > >>>>>>>> On Wed, Oct 5, 2016 at 1:35 PM, Michael Han <
> >> hanm@cloudera.com>
> >> > > >>>> wrote:
> >> > > >>>>>>>>
> >> > > >>>>>>>>> Eddie's mail contains lots of '=E2=80=8B'' which is
> unicode
> >> > > >>>> character
> >> > > >>>>>>>>> zero-width space, which might cause parsing trouble for
> some
> >> > mail
> >> > > >>>>>>>> clients.
> >> > > >>>>>>>>>
> >> > > >>>>>>>>> On Wed, Oct 5, 2016 at 6:42 AM, Flavio Junqueira <
> >> > fpj@apache.org
> >> > > >>>>
> >> > > >>>>>>> wrote:
> >> > > >>>>>>>>>
> >> > > >>>>>>>>>> Dude, I'm just not able to parse your e-mail, did you
> write
> >> > that
> >> > > >>>> on a
> >> > > >>>>>>>>>> phone or something?
> >> > > >>>>>>>>>>
> >> > > >>>>>>>>>> -Flavio
> >> > > >>>>>>>>>>
> >> > > >>>>>>>>>>> On 05 Oct 2016, at 03:54, Edward Ribeiro <
> >> > > >>>> edward.ribeiro@gmail.com
> >> > > >>>>>>>>
> >> > > >>>>>>>>>> wrote:
> >> > > >>>>>>>>>>>
> >> > > >>>>>>>>>>> Hi,
> >> > > >>>>>>>>>>>
> >> > > >>>>>>>>>>> The patch attached on ZOOKEEPER-2597 is a
> >> > > >>>>>>>>>>> straightforward adaptation of
> >> > > >>>>>>>>>>> Kafka's one. It takes care of merging Github PR into
> >> Apache
> >> > git
> >> > > >>>>>>> repo
> >> > > >>>>>>>>> and
> >> > > >>>>>>>>>>>  a
> >> > > >>>>>>>>>>> subsequent closing of the PR on the GH side
> >> > > >>>>>>>>>>>  among other things (rewriting of commit messages,
> etc)
> >> > > >>>>>>>>>>> . The current status is: the script needs to be
> >> > > >>> reviewed/validated
> >> > > >>>>>>>> by a
> >> > > >>>>>>>>>>> committer.
> >> > > >>>>>>>>>>> It has been some time since I uploaded the patch, so I
> >> gonna
> >> > > >>> do
> >> > > >>>>>>>>> another
> >> > > >>>>>>>>>>> pass through it in the meantime.
> >> > > >>>>>>>>>>>
> >> > > >>>>>>>>>>>
> >> > > >>>>>>>>>>> T
> >> > > >>>>>>>>>>> here are some workflow issues beyond the scope of
> >> > > >>> ZOOKEEPER-2597
> >> > > >>>>>>>>>>>  that need to be sorted out (IMO)
> >> > > >>>>>>>>>>> :
> >> > > >>>>>>>>>>>
> >> > > >>>>>>>>>>> 1. The normal workflow is to open a JIRA ticket before
> >> doing
> >> > > >>> any
> >> > > >>>> GH
> >> > > >>>>>>>> PR
> >> > > >>>>>>>>>>> , that is, no JIRA-less PRs.
> >> > > >>>>>>>>>>> The PR should have a title of the form "ZOOKEEPER-xxxx:
> >> > Title".
> >> > > >>>>>>> This
> >> > > >>>>>>>>> will
> >> > > >>>>>>>>>>> trigger the Apache JIRA-Github integration and it's
> >> opening
> >> > > >>> show
> >> > > >>>> up
> >> > > >>>>>>>> in
> >> > > >>>>>>>>>> the
> >> > > >>>>>>>>>>> JIRA ticket.
> >> > > >>>>>>>>>>>
> >> > > >>>>>>>>>>> 2.
> >> > > >>>>>>>>>>> OTOH, n
> >> > > >>>>>>>>>>> ot every Kafka PR needs a corresponding JIRA ticket
> >> > > >>>>>>>>>>> . 
> >> > > >>>>>>>>>>> There are a class of PR
> >> > > >>>>>>>>>>> s
> >> > > >>>>>>>>>>> with "MINOR"
> >> > > >>>>>>>>>>>  title
> >> > > >>>>>>>>>>> that represent trivial code changes
> >> > > >>>>>>>>>>>  and "HOT-FIX" title that fix urgent, but simple bugs.
> >> Both
> >> > > >>>>>>>>>>> bypass the JIRA creation step
> >> > > >>>>>>>>>>> , even tough they are still 
> >> > > >>>>>>>>>>> subject to review
> >> > > >>>>>>>>>>> .
> >> > > >>>>>>>>>>> It's worth adopting a similar approach for ZK project?
> >> > > >>>>>>>>>>>
> >> > > >>>>>>>>>>> 3. IIRC
> >> > > >>>>>>>>>>>  (didn't find any page to confirm)
> >> > > >>>>>>>>>>> , Cassandra project encourages, but not demands, that
> >> > > >>> contributors
> >> > > >>>>>>>> also
> >> > > >>>>>>>>>>> upload a patch file to JIRA even in the case of a GH PR
> >> > > >>>>>>>>>>>  (as to leave a audit trail, I guess)
> >> > > >>>>>>>>>>> .
> >> > > >>>>>>>>>>> Or
> >> > > >>>>>>>>>>> ,
> >> > > >>>>>>>>>>> at
> >> > > >>>>>>>>>>>  
> >> > > >>>>>>>>>>> least
> >> > > >>>>>>>>>>> ,
> >> > > >>>>>>>>>>> C* project 
> >> > > >>>>>>>>>>> leave
> >> > > >>>>>>>>>>> s
> >> > > >>>>>>>>>>> up to the contributor
> >> > > >>>>>>>>>>> s
> >> > > >>>>>>>>>>> to either open a GH PR or upload the patch file
> >> > > >>>>>>>>>>>  to JIRA. In fact, Github allows the access to a raw
> >> patch
> >> > or
> >> > > >>>>>>> diff,
> >> > > >>>>>>>>> it's
> >> > > >>>>>>>>>>> just a matter of adding the ".patch" or ".diff" suffix
> to
> >> the
> >> > > >>> end
> >> > > >>>>>>> of
> >> > > >>>>>>>>> the
> >> > > >>>>>>>>>>> Pull Request URL.
> >> > > >>>>>>>>>>> 
> >> > > >>>>>>>>>>>
> >> > > >>>>>>>>>>>
> >> > > >>>>>>>>>>> +1 about having a 'paper trail'
> >> > > >>>>>>>>>>>  of review comments
> >> > > >>>>>>>>>>>
> >> > > >>>>>>>>>>> o
> >> > > >>>>>>>>>>> n JIRA and
> >> > > >>>>>>>>>>> /or
> >> > > >>>>>>>>>>> mailing list (I
> >> > > >>>>>>>>>>>  would
> >> > > >>>>>>>>>>> prefer the mailing list tbh). But as Michael and Flavio
> >> > pointed
> >> > > >>>>>>> out,
> >> > > >>>>>>>> I
> >> > > >>>>>>>>>>> never seen
> >> > > >>>>>>>>>>> GH 
> >> > > >>>>>>>>>>> PR review
> >> > > >>>>>>>>>>> **
> >> > > >>>>>>>>>>> comments
> >> > > >>>>>>>>>>> **
> >> > > >>>>>>>>>>> being written back to JIRA, at least not in Kafka,
> >> Cassandra
> >> > > >>>>>>>>>>> or
> >> > > >>>>>>>>>>> Solr projects
> >> > > >>>>>>>>>>> , that I have followed more closely.
> >> > > >>>>>>>>>>>
> >> > > >>>>>>>>>>> Eddie
> >> > > >>>>>>>>>>>
> >> > > >>>>>>>>>>>
> >> > > >>>>>>>>>>> On Tue, Oct 4, 2016 at 6:40 PM, Michael Han <
> >> > hanm@cloudera.com
> >> > > >>>>
> >> > > >>>>>>>> wrote:
> >> > > >>>>>>>>>>>
> >> > > >>>>>>>>>>>>>> as long as the opening/closing/commenting all get
> sent
> >> to
> >> > > >>> the
> >> > > >>>>>>>>> mailing
> >> > > >>>>>>>>>>>> list or recorded in jira
> >> > > >>>>>>>>>>>> Yeah, this is my impression as well, that we need to
> keep
> >> > > >>> certain
> >> > > >>>>>>>>> paper
> >> > > >>>>>>>>>>>> trail regarding activities and comments on ASF side
> >> (JIRA or
> >> > > >>> mail
> >> > > >>>>>>>>> list).
> >> > > >>>>>>>>>>>> Infra page said:
> >> > > >>>>>>>>>>>>
> >> > > >>>>>>>>>>>> - Any Pull Request that gets opened, closed, reopened
> or
> >> > > >>>>>>>>> **commented**
> >> > > >>>>>>>>>>>> on now gets recorded on the project's mailing list
> >> > > >>>>>>>>>>>> - If a project has a JIRA instance, any PRs or
> >> *comments* on
> >> > > >>> PRs
> >> > > >>>>>>>>> that
> >> > > >>>>>>>>>>>> include a JIRA ticket ID will trigger an update on that
> >> > > >>> specific
> >> > > >>>>>>>>>> ticket
> >> > > >>>>>>>>>>>>
> >> > > >>>>>>>>>>>> I checked a couple Kafka and Spark JIRAs but I don't
> see
> >> any
> >> > > >>> of
> >> > > >>>>>>> the
> >> > > >>>>>>>>>>>> comments made in github PR were posted on JIRA, except
> >> the
> >> > > >>>>>>>> activities
> >> > > >>>>>>>>>> (open
> >> > > >>>>>>>>>>>> a PR, close a PR). Since both projects have been using
> >> > github
> >> > > >>> for
> >> > > >>>>>>> a
> >> > > >>>>>>>>>> while I
> >> > > >>>>>>>>>>>> assume such practice of NOT integrating comments
> between
> >> > > >>> github
> >> > > >>>>>>> and
> >> > > >>>>>>>>> ASF
> >> > > >>>>>>>>>>>> JIRA is acceptable? Though I feel it would be really
> >> useful
> >> > if
> >> > > >>>>>>>>> comments
> >> > > >>>>>>>>>>>> could converge in a single place as well, that will
> >> provide
> >> > a
> >> > > >>>>>>> clear
> >> > > >>>>>>>>>> history
> >> > > >>>>>>>>>>>> for a given technical issue.
> >> > > >>>>>>>>>>>>
> >> > > >>>>>>>>>>>> On Tue, Oct 4, 2016 at 12:06 PM, Flavio Junqueira <
> >> > > >>>> fpj@apache.org
> >> > > >>>>>>>>
> >> > > >>>>>>>>>> wrote:
> >> > > >>>>>>>>>>>>
> >> > > >>>>>>>>>>>>> Until ZOOKEEPER-2597 <https://issues.apache.org/
> >> > > >>>>>>>>>>>> jira/browse/ZOOKEEPER-2597>
> >> > > >>>>>>>>>>>>> is fixed, we can't merge via github.
> >> > > >>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>> For code reviews, we can use GH as long as the
> >> > > >>>>>>>>>> opening/closing/commenting
> >> > > >>>>>>>>>>>>> all get sent to the mailing list or recorded in jira.
> I
> >> > don't
> >> > > >>>>>>> think
> >> > > >>>>>>>>> we
> >> > > >>>>>>>>>>>> have
> >> > > >>>>>>>>>>>>> that yet, but it is possible according to this:
> >> > > >>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>> https://blogs.apache.org/infra/entry/improved_
> >> > > >>>>>>>>>>>>> integration_between_apache_and <
> >> https://blogs.apache.org/
> >> > > >>>>>>>>>>>>> infra/entry/improved_integration_between_apache_and>
> >> > > >>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>> For now, we do need to upload patches and converge
> using
> >> > > >>> jira.
> >> > > >>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>> I think Eddie has been looking at this process trying
> to
> >> > > >>>>>>> replicate
> >> > > >>>>>>>>> the
> >> > > >>>>>>>>>>>>> Kafka setup, so perhaps he can give an update if I'm
> >> right.
> >> > > >>>> Kafka
> >> > > >>>>>>>>>> doesn't
> >> > > >>>>>>>>>>>>> send every comment to the mailing list, though, but
> I'm
> >> not
> >> > > >>> sure
> >> > > >>>>>>> if
> >> > > >>>>>>>>>>>> that's
> >> > > >>>>>>>>>>>>> acceptable according to the ASF, I need to
> double-check.
> >> > > >>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>> -Flavio
> >> > > >>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>> On 04 Oct 2016, at 19:42, Michael Han <
> >> hanm@cloudera.com>
> >> > > >>>>>>> wrote:
> >> > > >>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>> Hi,
> >> > > >>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>> Now we've moved to git, what is the policy for
> >> uploading
> >> > > >>>> patches
> >> > > >>>>>>>> and
> >> > > >>>>>>>>>>>>> doing
> >> > > >>>>>>>>>>>>>> code reviews? I am asking because I've seen recently
> >> there
> >> > > >>> are
> >> > > >>>>>>> git
> >> > > >>>>>>>>>> pull
> >> > > >>>>>>>>>>>>>> requests coming in without associated patch file
> >> uploaded
> >> > to
> >> > > >>>>>>> JIRA.
> >> > > >>>>>>>>>> I've
> >> > > >>>>>>>>>>>>>> checked
> >> > > >>>>>>>>>>>>>> https://cwiki.apache.org/
> confluence/display/ZOOKEEPER/
> >> > > >>>>>>>>> HowToContribute
> >> > > >>>>>>>>>> ,
> >> > > >>>>>>>>>>>>>> looks like there is not much change regarding patch
> >> > process
> >> > > >>> -
> >> > > >>>> so
> >> > > >>>>>>>>>>>>> presumably
> >> > > >>>>>>>>>>>>>> we still need to generate and upload patch file to
> JIRA
> >> > for
> >> > > >>> the
> >> > > >>>>>>>>>> record,
> >> > > >>>>>>>>>>>>>> while using github (maybe in addition of review
> board,
> >> or
> >> > in
> >> > > >>>> the
> >> > > >>>>>>>>>> future
> >> > > >>>>>>>>>>>>>> with gerrit) to do code reviews?
> >> > > >>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>> On Wed, Sep 21, 2016 at 6:05 AM, Edward Ribeiro <
> >> > > >>>>>>>>>>>>> edward.ribeiro@gmail.com>
> >> > > >>>>>>>>>>>>>> wrote:
> >> > > >>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>> Cool, just open https://issues.apache.org/
> >> > > >>>>>>>>> jira/browse/ZOOKEEPER-2597
> >> > > >>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>> PS: I removed the REPO_HOME global variable.
> >> > > >>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>> On Wed, Sep 21, 2016 at 6:53 AM, Flavio Junqueira <
> >> > > >>>>>>>> fpj@apache.org>
> >> > > >>>>>>>>>>>>> wrote:
> >> > > >>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>> Better to have that in the form of a pull request
> or
> >> > diff.
> >> > > >>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>> REPO_HOME does seem to be unused.
> >> > > >>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>> -Flavio
> >> > > >>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>> On 20 Sep 2016, at 18:57, Edward Ribeiro <
> >> > > >>>>>>>>> edward.ribeiro@gmail.com
> >> > > >>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>> wrote:
> >> > > >>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>> Hey, I have started porting the kafka-merge.py to
> >> work
> >> > > >>> on ZK
> >> > > >>>>>>>>> repos.
> >> > > >>>>>>>>>>>> I
> >> > > >>>>>>>>>>>>>>>> would
> >> > > >>>>>>>>>>>>>>>>> need someone to review it and help me test it now.
> >> > > >>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>> The files were uploaded below, but I will create a
> >> > github
> >> > > >>>>>>> repo
> >> > > >>>>>>>>> yet
> >> > > >>>>>>>>>>>>>>> today.
> >> > > >>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>> https://www.dropbox.com/sh/od8bet2574jttm3/
> >> > > >>>>>>>>>>>>>>>> AADv1DXTb8vfyVCmelFbYCEha?dl=0
> >> > > >>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>> I uploaded the kafka version script so that you
> can
> >> use
> >> > > >>> diff
> >> > > >>>>>>> or
> >> > > >>>>>>>>>> Meld
> >> > > >>>>>>>>>>>>> to
> >> > > >>>>>>>>>>>>>>>>> spot my changes, but feel free to grasp the
> original
> >> > file
> >> > > >>>>>>> here:
> >> > > >>>>>>>>>>>>>>>>> https://github.com/apache/
> >> > kafka/blob/trunk/kafka-merge-
> >> > > >>>> pr.py
> >> > > >>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>> PS: It's just me or REPO_HOME env variable is not
> >> used
> >> > > >>>>>>> anywhere
> >> > > >>>>>>>>> in
> >> > > >>>>>>>>>>>> the
> >> > > >>>>>>>>>>>>>>>>> merge script???
> >> > > >>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>> Cheers,
> >> > > >>>>>>>>>>>>>>>>> Eddie
> >> > > >>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick Hunt <
> >> > > >>>>>>>> phunt@apache.org
> >> > > >>>>>>>>>>
> >> > > >>>>>>>>>>>>>>> wrote:
> >> > > >>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin Reed <
> >> > > >>>>>>>>> breed@apache.org>
> >> > > >>>>>>>>>>>>>>>> wrote:
> >> > > >>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>>> what you are suggesting sounds good, but i don't
> >> know
> >> > > >>> how
> >> > > >>>>>>> to
> >> > > >>>>>>>> do
> >> > > >>>>>>>>>>>> it?
> >> > > >>>>>>>>>>>>>>>> since
> >> > > >>>>>>>>>>>>>>>>>>> in the end we are still just accepting diffs on
> >> > > >>> patches,
> >> > > >>>>>>> the
> >> > > >>>>>>>>> only
> >> > > >>>>>>>>>>>>>>> thing
> >> > > >>>>>>>>>>>>>>>>>>> that changes is that we use svn rather than git
> >> > right?
> >> > > >>>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>> Notice the workflow Kafka uses - which includes
> >> "git
> >> > > >>> apply"
> >> > > >>>>>>>> and
> >> > > >>>>>>>>>>>>>>>> specifying
> >> > > >>>>>>>>>>>>>>>>>> the author tag when committers commit (so that
> the
> >> OP
> >> > > >>> gets
> >> > > >>>>>>>>> proper
> >> > > >>>>>>>>>>>>>>>>>> attribution in the commit itself)
> >> > > >>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>> https://cwiki.apache.org/
> confluence/display/KAFKA/
> >> > > >>>>>>>>>>>>>>>> Manual+Commit+Workflow
> >> > > >>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>> Patrick
> >> > > >>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>>> i LOVE chris's idea! lets do it!
> >> > > >>>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>>> ben
> >> > > >>>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>>> On Sun, Sep 18, 2016 at 3:22 PM, Patrick Hunt <
> >> > > >>>>>>>>> phunt@apache.org>
> >> > > >>>>>>>>>>>>>>>> wrote:
> >> > > >>>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>>>> Ben, do you also want to update the "Applying a
> >> > patch"
> >> > > >>>>>>>> section
> >> > > >>>>>>>>>> to
> >> > > >>>>>>>>>>>>>>> make
> >> > > >>>>>>>>>>>>>>>>>> it
> >> > > >>>>>>>>>>>>>>>>>>>> git specific?
> >> > > >>>>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>>>> We (committers) should move to a model where
> >> authors
> >> > > >>> get
> >> > > >>>>>>>>> proper
> >> > > >>>>>>>>>>>>>>> credit
> >> > > >>>>>>>>>>>>>>>>>> in
> >> > > >>>>>>>>>>>>>>>>>>>> git. Our old workflow in svn resulted in only
> the
> >> > > >>>>>>> committer
> >> > > >>>>>>>>>> being
> >> > > >>>>>>>>>>>>>>>>>> listed
> >> > > >>>>>>>>>>>>>>>>>>>> (except that we listed the patch author in the
> >> > commit
> >> > > >>>>>>>>> message).
> >> > > >>>>>>>>>>>> We
> >> > > >>>>>>>>>>>>>>>>>> should
> >> > > >>>>>>>>>>>>>>>>>>>> move to a model where the author of the patch
> >> gets
> >> > > >>> proper
> >> > > >>>>>>>>> credit
> >> > > >>>>>>>>>>>> in
> >> > > >>>>>>>>>>>>>>>>>> git.
> >> > > >>>>>>>>>>>>>>>>>>> I
> >> > > >>>>>>>>>>>>>>>>>>>> believe we will get that if we use git for
> patch
> >> > > >>>>>>>>>>>>>>> creation/application?
> >> > > >>>>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>>>> Chris brought up getting rid of CHANGES.txt
> >> recently
> >> > > >>> on
> >> > > >>>>>>> the
> >> > > >>>>>>>>> dev
> >> > > >>>>>>>>>>>>> list
> >> > > >>>>>>>>>>>>>>>>>> in a
> >> > > >>>>>>>>>>>>>>>>>>>> separate thread - Chris do you want to
> implement
> >> > that
> >> > > >>>>>>> change
> >> > > >>>>>>>>> now
> >> > > >>>>>>>>>>>>>>> that
> >> > > >>>>>>>>>>>>>>>>>>> we've
> >> > > >>>>>>>>>>>>>>>>>>>> moved to git?
> >> > > >>>>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>>>> Patrick
> >> > > >>>>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>>>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin Reed
> <
> >> > > >>>>>>>>>> breed@apache.org
> >> > > >>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>> wrote:
> >> > > >>>>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>>>>>> 1) actually in the previous step that was
> just
> >> > > >>> adding
> >> > > >>>>>>> new
> >> > > >>>>>>>>>>>> files.
> >> > > >>>>>>>>>>>>>>> you
> >> > > >>>>>>>>>>>>>>>>>>>>>> still
> >> > > >>>>>>>>>>>>>>>>>>>>>>> need the commit -a for the rest of the
> >> changes.
> >> > > >>> that's
> >> > > >>>>>>> my
> >> > > >>>>>>>>>>>> normal
> >> > > >>>>>>>>>>>>>>>>>>>>>> workflow.
> >> > > >>>>>>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>>>>>> I think that will be confusing for most
> folks.
> >> > They
> >> > > >>>>>>>>> typically
> >> > > >>>>>>>>>>>>>>> stage
> >> > > >>>>>>>>>>>>>>>>>>>>>> all the changes and then commit or don't
> stage
> >> and
> >> > > >>> use
> >> > > >>>>>>> -a.
> >> > > >>>>>>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>>>>> do you mind fixing it with your workflow.
> >> commit -a
> >> > > >>>>>>> doesn't
> >> > > >>>>>>>>> get
> >> > > >>>>>>>>>>>>> new
> >> > > >>>>>>>>>>>>>>>>>>>>> files, which is why you need to do the add,
> but
> >> i'm
> >> > > >>> not
> >> > > >>>>>>> the
> >> > > >>>>>>>>>> most
> >> > > >>>>>>>>>>>>>>>>>>>>> sophisticated git user, so
> >> > > >>>>>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>>>>>>> 2) i figured since we are using git now that
> >> we
> >> > > >>> should
> >> > > >>>>>>>> use
> >> > > >>>>>>>>>>>> git's
> >> > > >>>>>>>>>>>>>>>>>>>>>> default.
> >> > > >>>>>>>>>>>>>>>>>>>>>>> the patch should work (by default it seems
> to
> >> > strip
> >> > > >>>> the
> >> > > >>>>>>>>> first
> >> > > >>>>>>>>>>>>>>> path
> >> > > >>>>>>>>>>>>>>>>>>>>>> element).
> >> > > >>>>>>>>>>>>>>>>>>>>>>> does it not work for you?
> >> > > >>>>>>>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>>>>>> It will fail precommit in it's current state.
> >> > > >>>>>>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>>>>> fixed
> >> > > >>>>>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>> --
> >> > > >>>>>>>>>>>>>> Cheers
> >> > > >>>>>>>>>>>>>> Michael.
> >> > > >>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>>
> >> > > >>>>>>>>>>>>
> >> > > >>>>>>>>>>>>
> >> > > >>>>>>>>>>>> --
> >> > > >>>>>>>>>>>> Cheers
> >> > > >>>>>>>>>>>> Michael.
> >> > > >>>>>>>>>>>>
> >> > > >>>>>>>>>>
> >> > > >>>>>>>>>>
> >> > > >>>>>>>>>
> >> > > >>>>>>>>>
> >> > > >>>>>>>>> --
> >> > > >>>>>>>>> Cheers
> >> > > >>>>>>>>> Michael.
> >> > > >>>>>>>>>
> >> > > >>>>>>>>
> >> > > >>>>>>>
> >> > > >>>>>
> >> > > >>>>>
> >> > > >>>>
> >> > > >>>>
> >> > > >>>> --
> >> > > >>>> Cheers
> >> > > >>>> Michael.
> >> > > >>>>
> >> > > >>>
> >> > > >>
> >> > > >>
> >> > > >>
> >> > > >> --
> >> > > >> Cheers
> >> > > >> Michael.
> >> > > >>
> >> > > >
> >> > > >
> >> > > >
> >> > > > --
> >> > > > Cheers
> >> > > > Michael.
> >> > >
> >> > >
> >> >
> >>
> >
>

Re: [VOTE] move Apache Zookeeper to git

Posted by Edward Ribeiro <ed...@gmail.com>.

Hi Patrick,

I've just opened a PR  https://github.com/apache/zookeeper/pull/103/ PR

It asks for JIRA_PASSWORD at CLI prompt *IF* it's absent but JIRA_USERNAME
is already set. Please, when you have time, see if it fits what you need
and then I can open a JIRA, rename the feature branch, etc.

Let me know if you have other ideas. I am open to other ways of
incorporating the passing of JIRA_PASSWORD too.

Edward

On Wed, Nov 9, 2016 at 5:03 PM, Edward Ribeiro <ed...@gmail.com>
wrote:

> Hi Patrick,
>
> We can change the script so that it asks for jira password input on CLI
> prompt if the JIRA username is set, for example. The change should be
> straigthforward.
>
> Alternatively, the python systems I have dealt with put credentials for
> database access, etc, in configuration -- sometimes hidden -- files (say,
> .env), but yet it is clear text stored.
>
> Anyone has other suggestions?
>
> Eddie
>
> Em 9 de nov de 2016 4:18 PM, "Patrick Hunt" <ph...@apache.org> escreveu:
>
>> Is there any alternative to step 4 as documented here?
>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/Mergin
>> g+Github+Pull+Requests
>>
>> specifically it's asking to "export JIRA_PASSWORD=mypassword" which I feel
>> very uncomfortable doing.
>>
>> Patrick
>>
>> On Wed, Oct 26, 2016 at 11:12 AM, Edward Ribeiro <
>> edward.ribeiro@gmail.com>
>> wrote:
>>
>> > AFAIK, yes. I say, if you mean to run unit tests and other CI tasks on
>> PR.
>> >
>> > PS: I have just created a simple script HowTo at
>> > https://cwiki.apache.org/confluence/display/ZOOKEEPER/
>> > Merging+Github+Pull+Requests
>> > and linked from https://cwiki.apache.org/confluence/display/ZOOKEEPER/
>> > Index
>> >
>> > On Wed, Oct 26, 2016 at 3:59 PM, Flavio Junqueira <fp...@apache.org>
>> wrote:
>> >
>> > > What about QA, are we still missing a github pre-commit queue?
>> > >
>> > > -Flavio
>> > >
>> > > > On 26 Oct 2016, at 18:53, Michael Han <ha...@cloudera.com> wrote:
>> > > >
>> > > > The comment bridging should be fixed now - see INFRA-12752 for more
>> > > > details.
>> > > >
>> > > > On Wed, Oct 26, 2016 at 10:03 AM, Michael Han <ha...@cloudera.com>
>> > wrote:
>> > > >
>> > > >>>> The git PR *review* comments for ZOOKEEPER-2597 didn't show up on
>> > > JIRA.
>> > > >>
>> > > >> The bridge was working the day Infra made the change - see the
>> > previous
>> > > >> comments made by git bot on ZOOKEEPER-761. Now it seems stop
>> working.
>> > I
>> > > am
>> > > >> reopening INFRA-12752 and building a case.
>> > > >>
>> > > >> On Wed, Oct 26, 2016 at 9:45 AM, Edward Ribeiro <
>> > > edward.ribeiro@gmail.com>
>> > > >> wrote:
>> > > >>
>> > > >>> Dear community,
>> > > >>>
>> > > >>> The zk-merger-pr.py script has been merged into master (thanks a
>> LOT
>> > > Ben
>> > > >>> Reed for reviewing/discussing/testing and commiting):
>> > > >>> https://issues.apache.org/jira/browse/ZOOKEEPER-2597
>> > > >>>
>> > > >>> As stated in the issue and on GH, this tool is a modified version
>> of
>> > > >>> similar tools from Kafka, that is a copy of a Spark's one. It has
>> > some
>> > > >>> rough edges so we will certainly benefit from further enhancements
>> > and
>> > > >>> fixes. I changed the smallest possible pieces of code, just to
>> make
>> > it
>> > > >>> work
>> > > >>> on a ZK repo so the credits go to the original authors.
>> > > >>>
>> > > >>> Some notes:
>> > > >>>
>> > > >>> 1. The git PR *review* comments for ZOOKEEPER-2597 didn't show up
>> on
>> > > JIRA.
>> > > >>> Only the opening and closing of the issue. Can we double check
>> this
>> > as
>> > > >>> INFRA-12752 is closed, Michael Han?
>> > > >>>
>> > > >>> 2. I scribbled a draft on how use the tool at
>> > > >>> https://docs.google.com/document/d/1i00ZXjrW2fu17vr_h7F1bUrq
>> > > >>> Xg3urw4Hm7KirQDpPIU/edit
>> > > >>> (still very crude, but feel free to improve it). I would like to
>> move
>> > > >>> this
>> > > >>> text to https://cwiki.apache.org/confl
>> uence/display/ZOOKEEPER/Index
>> > > but
>> > > >>> looks like I don't have permission to create a page there yet. Any
>> > > help?
>> > > >>>
>> > > >>> Best regards,
>> > > >>> Eddie
>> > > >>>
>> > > >>> On Sat, Oct 22, 2016 at 7:08 PM, Michael Han <ha...@cloudera.com>
>> > > wrote:
>> > > >>>
>> > > >>>> FYI infra did some work in INFRA-12752 and the git PR comments
>> can
>> > be
>> > > >>>> pushed to Apache JIRA.
>> > > >>>>
>> > > >>>> On Sat, Oct 8, 2016 at 8:01 AM, Flavio Junqueira <fpj@apache.org
>> >
>> > > >>> wrote:
>> > > >>>>
>> > > >>>>> This is not supported at the moment if nothing has changed:
>> > > >>>>>
>> > > >>>>> https://issues.apache.org/jira/browse/INFRA-11000 <
>> > > >>>>> https://issues.apache.org/jira/browse/INFRA-11000>
>> > > >>>>>
>> > > >>>>> -Flavio
>> > > >>>>>
>> > > >>>>>> On 08 Oct 2016, at 00:54, Benjamin Reed <br...@apache.org>
>> wrote:
>> > > >>>>>>
>> > > >>>>>> it doesn't look like we need to setup keys. this seems to work
>> for
>> > > >>> me:
>> > > >>>>>>
>> > > >>>>>> https://git-wip-us.apache.org/#committers-getting-started
>> > > >>>>>>
>> > > >>>>>> it does seem strange that we aren't using public keys and that
>> i'm
>> > > >>>>> sticking
>> > > >>>>>> a password in .netrc :P i'm wondering if other projects were
>> able
>> > to
>> > > >>>> get
>> > > >>>>>> this going over ssh.
>> > > >>>>>>
>> > > >>>>>> i'll take a whack at cleaning up the svn and subversion
>> > references.
>> > > >>>>>>
>> > > >>>>>> ben
>> > > >>>>>>
>> > > >>>>>> On Fri, Oct 7, 2016 at 12:59 PM, Camille Fournier <
>> > > >>> camille@apache.org>
>> > > >>>>>> wrote:
>> > > >>>>>>
>> > > >>>>>>> Hey folks,
>> > > >>>>>>>
>> > > >>>>>>> So I'm trying to get in a patch but this has not been updated
>> to
>> > > >>> tell
>> > > >>>>>>> committers how to actually get the git keys set up:
>> > > >>>>>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
>> > > >>>>> Committing+changes
>> > > >>>>>>>
>> > > >>>>>>> Can someone float me a link that says how to do this?
>> > > >>>>>>>
>> > > >>>>>>> Also a bunch of our documentation still discusses SVN and not
>> > git,
>> > > >>>> which
>> > > >>>>>>> means we are not done with this migration. If you were pushing
>> > for
>> > > >>>> this
>> > > >>>>>>> change can you please do some due diligence on the wikis and
>> > > >>> correct
>> > > >>>> the
>> > > >>>>>>> stuff that refers to SVN?
>> > > >>>>>>>
>> > > >>>>>>> Thanks,
>> > > >>>>>>> C
>> > > >>>>>>>
>> > > >>>>>>> On Wed, Oct 5, 2016 at 1:02 PM, Edward Ribeiro <
>> > > >>>>> edward.ribeiro@gmail.com>
>> > > >>>>>>> wrote:
>> > > >>>>>>>
>> > > >>>>>>>> Excuse me guys!
>> > > >>>>>>>>
>> > > >>>>>>>> I've written on Macbook Pro. No idea why GMail messed it up.
>> I
>> > was
>> > > >>>> only
>> > > >>>>>>>> able to see the strange characters when I pasted on a gist
>> text
>> > > >>> area.
>> > > >>>>> The
>> > > >>>>>>>> previous message is below, but if anyone is still having
>> trouble
>> > > >>> (I
>> > > >>>>> tried
>> > > >>>>>>>> to remove the weird character), I left a copy at:
>> > > >>>>>>>> https://gist.github.com/eribeiro/da2a6a6c9a508610d52d0755fae
>> 835
>> > 2d
>> > > >>>>>>>>
>> > > >>>>>>>> "Hi,
>> > > >>>>>>>>
>> > > >>>>>>>> The patch attached on ZOOKEEPER-2597 is a straightforward
>> > > >>> adaptation
>> > > >>>> of
>> > > >>>>>>>> Kafka's one. It takes care of merging Github PR into Apache
>> git
>> > > >>> repo
>> > > >>>>> and
>> > > >>>>>>> a
>> > > >>>>>>>> subsequent closing of the PR on the GH side, among other
>> things
>> > > >>>>>>> (rewriting
>> > > >>>>>>>> of commit messages, etc). The current status is: the script
>> > needs
>> > > >>> to
>> > > >>>> be
>> > > >>>>>>>> reviewed/validated by a committer. It has been some time
>> since I
>> > > >>>>> uploaded
>> > > >>>>>>>> the patch, so I gonna do another pass through it in the
>> > meantime.
>> > > >>>>>>>>
>> > > >>>>>>>> There are some workflow issues beyond the scope of
>> > ZOOKEEPER-2597
>> > > >>>> that
>> > > >>>>>>> need
>> > > >>>>>>>> to be sorted out (IMO):
>> > > >>>>>>>>
>> > > >>>>>>>> 1. The normal workflow is to open a JIRA ticket before doing
>> any
>> > > >>> GH
>> > > >>>> PR,
>> > > >>>>>>>> that is, no JIRA-less PRs. The PR should have a title of the
>> > form
>> > > >>>>>>>> "ZOOKEEPER-xxxx: Title". This will trigger the Apache
>> > JIRA-Github
>> > > >>>>>>>> integration and it's opening show up in the JIRA ticket.
>> > > >>>>>>>>
>> > > >>>>>>>> 2. OTOH, not every Kafka PR needs a corresponding JIRA
>> ticket.
>> > > >>> There
>> > > >>>>> are
>> > > >>>>>>> a
>> > > >>>>>>>> class of PRs with "MINOR" title that represent trivial code
>> > > >>> changes
>> > > >>>> and
>> > > >>>>>>>> "HOT-FIX" title that fix urgent, but simple bugs. Both bypass
>> > the
>> > > >>>> JIRA
>> > > >>>>>>>> creation step, even tough they are still subject to review.
>> It's
>> > > >>>> worth
>> > > >>>>>>>> adopting a similar approach for ZK project?
>> > > >>>>>>>>
>> > > >>>>>>>> 3. IIRC (didn't find any page to confirm), Cassandra project
>> > > >>>>> encourages,
>> > > >>>>>>>> but not demands, that contributors also upload a patch file
>> to
>> > > >>> JIRA
>> > > >>>>> even
>> > > >>>>>>> in
>> > > >>>>>>>> the case of a GH PR (as to leave a audit trail, I guess).
>> Or, at
>> > > >>>>> least,
>> > > >>>>>>> C*
>> > > >>>>>>>> project leaves up to the contributors to either open a GH PR
>> or
>> > > >>>> upload
>> > > >>>>>>> the
>> > > >>>>>>>> patch file to JIRA.
>> > > >>>>>>>>
>> > > >>>>>>>>
>> > > >>>>>>>> +1 about having a 'paper trail' of review comments on JIRA
>> > and/or
>> > > >>>>> mailing
>> > > >>>>>>>> list (I would prefer the mailing list tbh). But as Michael
>> and
>> > > >>> Flavio
>> > > >>>>>>>> pointed out, I never seen GH PR review **comments** being
>> > written
>> > > >>>> back
>> > > >>>>> to
>> > > >>>>>>>> JIRA, at least not in Kafka, Cassandra or Solr projects,
>> that I
>> > > >>> have
>> > > >>>>>>>> followed more closely.
>> > > >>>>>>>>
>> > > >>>>>>>> Eddie"
>> > > >>>>>>>>
>> > > >>>>>>>>
>> > > >>>>>>>> On Wed, Oct 5, 2016 at 1:35 PM, Michael Han <
>> hanm@cloudera.com>
>> > > >>>> wrote:
>> > > >>>>>>>>
>> > > >>>>>>>>> Eddie's mail contains lots of '=E2=80=8B'' which is unicode
>> > > >>>> character
>> > > >>>>>>>>> zero-width space, which might cause parsing trouble for some
>> > mail
>> > > >>>>>>>> clients.
>> > > >>>>>>>>>
>> > > >>>>>>>>> On Wed, Oct 5, 2016 at 6:42 AM, Flavio Junqueira <
>> > fpj@apache.org
>> > > >>>>
>> > > >>>>>>> wrote:
>> > > >>>>>>>>>
>> > > >>>>>>>>>> Dude, I'm just not able to parse your e-mail, did you write
>> > that
>> > > >>>> on a
>> > > >>>>>>>>>> phone or something?
>> > > >>>>>>>>>>
>> > > >>>>>>>>>> -Flavio
>> > > >>>>>>>>>>
>> > > >>>>>>>>>>> On 05 Oct 2016, at 03:54, Edward Ribeiro <
>> > > >>>> edward.ribeiro@gmail.com
>> > > >>>>>>>>
>> > > >>>>>>>>>> wrote:
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>> Hi,
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>> The patch attached on ZOOKEEPER-2597 is a
>> > > >>>>>>>>>>> straightforward adaptation of
>> > > >>>>>>>>>>> Kafka's one. It takes care of merging Github PR into
>> Apache
>> > git
>> > > >>>>>>> repo
>> > > >>>>>>>>> and
>> > > >>>>>>>>>>>  a
>> > > >>>>>>>>>>> subsequent closing of the PR on the GH side
>> > > >>>>>>>>>>>  among other things (rewriting of commit messages, etc)
>> > > >>>>>>>>>>> . The current status is: the script needs to be
>> > > >>> reviewed/validated
>> > > >>>>>>>> by a
>> > > >>>>>>>>>>> committer.
>> > > >>>>>>>>>>> It has been some time since I uploaded the patch, so I
>> gonna
>> > > >>> do
>> > > >>>>>>>>> another
>> > > >>>>>>>>>>> pass through it in the meantime.
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>> T
>> > > >>>>>>>>>>> here are some workflow issues beyond the scope of
>> > > >>> ZOOKEEPER-2597
>> > > >>>>>>>>>>>  that need to be sorted out (IMO)
>> > > >>>>>>>>>>> :
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>> 1. The normal workflow is to open a JIRA ticket before
>> doing
>> > > >>> any
>> > > >>>> GH
>> > > >>>>>>>> PR
>> > > >>>>>>>>>>> , that is, no JIRA-less PRs.
>> > > >>>>>>>>>>> The PR should have a title of the form "ZOOKEEPER-xxxx:
>> > Title".
>> > > >>>>>>> This
>> > > >>>>>>>>> will
>> > > >>>>>>>>>>> trigger the Apache JIRA-Github integration and it's
>> opening
>> > > >>> show
>> > > >>>> up
>> > > >>>>>>>> in
>> > > >>>>>>>>>> the
>> > > >>>>>>>>>>> JIRA ticket.
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>> 2.
>> > > >>>>>>>>>>> OTOH, n
>> > > >>>>>>>>>>> ot every Kafka PR needs a corresponding JIRA ticket
>> > > >>>>>>>>>>> . 
>> > > >>>>>>>>>>> There are a class of PR
>> > > >>>>>>>>>>> s
>> > > >>>>>>>>>>> with "MINOR"
>> > > >>>>>>>>>>>  title
>> > > >>>>>>>>>>> that represent trivial code changes
>> > > >>>>>>>>>>>  and "HOT-FIX" title that fix urgent, but simple bugs.
>> Both
>> > > >>>>>>>>>>> bypass the JIRA creation step
>> > > >>>>>>>>>>> , even tough they are still 
>> > > >>>>>>>>>>> subject to review
>> > > >>>>>>>>>>> .
>> > > >>>>>>>>>>> It's worth adopting a similar approach for ZK project?
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>> 3. IIRC
>> > > >>>>>>>>>>>  (didn't find any page to confirm)
>> > > >>>>>>>>>>> , Cassandra project encourages, but not demands, that
>> > > >>> contributors
>> > > >>>>>>>> also
>> > > >>>>>>>>>>> upload a patch file to JIRA even in the case of a GH PR
>> > > >>>>>>>>>>>  (as to leave a audit trail, I guess)
>> > > >>>>>>>>>>> .
>> > > >>>>>>>>>>> Or
>> > > >>>>>>>>>>> ,
>> > > >>>>>>>>>>> at
>> > > >>>>>>>>>>>  
>> > > >>>>>>>>>>> least
>> > > >>>>>>>>>>> ,
>> > > >>>>>>>>>>> C* project 
>> > > >>>>>>>>>>> leave
>> > > >>>>>>>>>>> s
>> > > >>>>>>>>>>> up to the contributor
>> > > >>>>>>>>>>> s
>> > > >>>>>>>>>>> to either open a GH PR or upload the patch file
>> > > >>>>>>>>>>>  to JIRA. In fact, Github allows the access to a raw
>> patch
>> > or
>> > > >>>>>>> diff,
>> > > >>>>>>>>> it's
>> > > >>>>>>>>>>> just a matter of adding the ".patch" or ".diff" suffix to
>> the
>> > > >>> end
>> > > >>>>>>> of
>> > > >>>>>>>>> the
>> > > >>>>>>>>>>> Pull Request URL.
>> > > >>>>>>>>>>> 
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>> +1 about having a 'paper trail'
>> > > >>>>>>>>>>>  of review comments
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>> o
>> > > >>>>>>>>>>> n JIRA and
>> > > >>>>>>>>>>> /or
>> > > >>>>>>>>>>> mailing list (I
>> > > >>>>>>>>>>>  would
>> > > >>>>>>>>>>> prefer the mailing list tbh). But as Michael and Flavio
>> > pointed
>> > > >>>>>>> out,
>> > > >>>>>>>> I
>> > > >>>>>>>>>>> never seen
>> > > >>>>>>>>>>> GH 
>> > > >>>>>>>>>>> PR review
>> > > >>>>>>>>>>> **
>> > > >>>>>>>>>>> comments
>> > > >>>>>>>>>>> **
>> > > >>>>>>>>>>> being written back to JIRA, at least not in Kafka,
>> Cassandra
>> > > >>>>>>>>>>> or
>> > > >>>>>>>>>>> Solr projects
>> > > >>>>>>>>>>> , that I have followed more closely.
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>> Eddie
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>> On Tue, Oct 4, 2016 at 6:40 PM, Michael Han <
>> > hanm@cloudera.com
>> > > >>>>
>> > > >>>>>>>> wrote:
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>>>>> as long as the opening/closing/commenting all get sent
>> to
>> > > >>> the
>> > > >>>>>>>>> mailing
>> > > >>>>>>>>>>>> list or recorded in jira
>> > > >>>>>>>>>>>> Yeah, this is my impression as well, that we need to keep
>> > > >>> certain
>> > > >>>>>>>>> paper
>> > > >>>>>>>>>>>> trail regarding activities and comments on ASF side
>> (JIRA or
>> > > >>> mail
>> > > >>>>>>>>> list).
>> > > >>>>>>>>>>>> Infra page said:
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>> - Any Pull Request that gets opened, closed, reopened or
>> > > >>>>>>>>> **commented**
>> > > >>>>>>>>>>>> on now gets recorded on the project's mailing list
>> > > >>>>>>>>>>>> - If a project has a JIRA instance, any PRs or
>> *comments* on
>> > > >>> PRs
>> > > >>>>>>>>> that
>> > > >>>>>>>>>>>> include a JIRA ticket ID will trigger an update on that
>> > > >>> specific
>> > > >>>>>>>>>> ticket
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>> I checked a couple Kafka and Spark JIRAs but I don't see
>> any
>> > > >>> of
>> > > >>>>>>> the
>> > > >>>>>>>>>>>> comments made in github PR were posted on JIRA, except
>> the
>> > > >>>>>>>> activities
>> > > >>>>>>>>>> (open
>> > > >>>>>>>>>>>> a PR, close a PR). Since both projects have been using
>> > github
>> > > >>> for
>> > > >>>>>>> a
>> > > >>>>>>>>>> while I
>> > > >>>>>>>>>>>> assume such practice of NOT integrating comments between
>> > > >>> github
>> > > >>>>>>> and
>> > > >>>>>>>>> ASF
>> > > >>>>>>>>>>>> JIRA is acceptable? Though I feel it would be really
>> useful
>> > if
>> > > >>>>>>>>> comments
>> > > >>>>>>>>>>>> could converge in a single place as well, that will
>> provide
>> > a
>> > > >>>>>>> clear
>> > > >>>>>>>>>> history
>> > > >>>>>>>>>>>> for a given technical issue.
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>> On Tue, Oct 4, 2016 at 12:06 PM, Flavio Junqueira <
>> > > >>>> fpj@apache.org
>> > > >>>>>>>>
>> > > >>>>>>>>>> wrote:
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>>> Until ZOOKEEPER-2597 <https://issues.apache.org/
>> > > >>>>>>>>>>>> jira/browse/ZOOKEEPER-2597>
>> > > >>>>>>>>>>>>> is fixed, we can't merge via github.
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>>> For code reviews, we can use GH as long as the
>> > > >>>>>>>>>> opening/closing/commenting
>> > > >>>>>>>>>>>>> all get sent to the mailing list or recorded in jira. I
>> > don't
>> > > >>>>>>> think
>> > > >>>>>>>>> we
>> > > >>>>>>>>>>>> have
>> > > >>>>>>>>>>>>> that yet, but it is possible according to this:
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>>> https://blogs.apache.org/infra/entry/improved_
>> > > >>>>>>>>>>>>> integration_between_apache_and <
>> https://blogs.apache.org/
>> > > >>>>>>>>>>>>> infra/entry/improved_integration_between_apache_and>
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>>> For now, we do need to upload patches and converge using
>> > > >>> jira.
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>>> I think Eddie has been looking at this process trying to
>> > > >>>>>>> replicate
>> > > >>>>>>>>> the
>> > > >>>>>>>>>>>>> Kafka setup, so perhaps he can give an update if I'm
>> right.
>> > > >>>> Kafka
>> > > >>>>>>>>>> doesn't
>> > > >>>>>>>>>>>>> send every comment to the mailing list, though, but I'm
>> not
>> > > >>> sure
>> > > >>>>>>> if
>> > > >>>>>>>>>>>> that's
>> > > >>>>>>>>>>>>> acceptable according to the ASF, I need to double-check.
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>>> -Flavio
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>> On 04 Oct 2016, at 19:42, Michael Han <
>> hanm@cloudera.com>
>> > > >>>>>>> wrote:
>> > > >>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>> Hi,
>> > > >>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>> Now we've moved to git, what is the policy for
>> uploading
>> > > >>>> patches
>> > > >>>>>>>> and
>> > > >>>>>>>>>>>>> doing
>> > > >>>>>>>>>>>>>> code reviews? I am asking because I've seen recently
>> there
>> > > >>> are
>> > > >>>>>>> git
>> > > >>>>>>>>>> pull
>> > > >>>>>>>>>>>>>> requests coming in without associated patch file
>> uploaded
>> > to
>> > > >>>>>>> JIRA.
>> > > >>>>>>>>>> I've
>> > > >>>>>>>>>>>>>> checked
>> > > >>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
>> > > >>>>>>>>> HowToContribute
>> > > >>>>>>>>>> ,
>> > > >>>>>>>>>>>>>> looks like there is not much change regarding patch
>> > process
>> > > >>> -
>> > > >>>> so
>> > > >>>>>>>>>>>>> presumably
>> > > >>>>>>>>>>>>>> we still need to generate and upload patch file to JIRA
>> > for
>> > > >>> the
>> > > >>>>>>>>>> record,
>> > > >>>>>>>>>>>>>> while using github (maybe in addition of review board,
>> or
>> > in
>> > > >>>> the
>> > > >>>>>>>>>> future
>> > > >>>>>>>>>>>>>> with gerrit) to do code reviews?
>> > > >>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>> On Wed, Sep 21, 2016 at 6:05 AM, Edward Ribeiro <
>> > > >>>>>>>>>>>>> edward.ribeiro@gmail.com>
>> > > >>>>>>>>>>>>>> wrote:
>> > > >>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>> Cool, just open https://issues.apache.org/
>> > > >>>>>>>>> jira/browse/ZOOKEEPER-2597
>> > > >>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>> PS: I removed the REPO_HOME global variable.
>> > > >>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>> On Wed, Sep 21, 2016 at 6:53 AM, Flavio Junqueira <
>> > > >>>>>>>> fpj@apache.org>
>> > > >>>>>>>>>>>>> wrote:
>> > > >>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>> Better to have that in the form of a pull request or
>> > diff.
>> > > >>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>> REPO_HOME does seem to be unused.
>> > > >>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>> -Flavio
>> > > >>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>> On 20 Sep 2016, at 18:57, Edward Ribeiro <
>> > > >>>>>>>>> edward.ribeiro@gmail.com
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>> wrote:
>> > > >>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>> Hey, I have started porting the kafka-merge.py to
>> work
>> > > >>> on ZK
>> > > >>>>>>>>> repos.
>> > > >>>>>>>>>>>> I
>> > > >>>>>>>>>>>>>>>> would
>> > > >>>>>>>>>>>>>>>>> need someone to review it and help me test it now.
>> > > >>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>> The files were uploaded below, but I will create a
>> > github
>> > > >>>>>>> repo
>> > > >>>>>>>>> yet
>> > > >>>>>>>>>>>>>>> today.
>> > > >>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>> https://www.dropbox.com/sh/od8bet2574jttm3/
>> > > >>>>>>>>>>>>>>>> AADv1DXTb8vfyVCmelFbYCEha?dl=0
>> > > >>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>> I uploaded the kafka version script so that you can
>> use
>> > > >>> diff
>> > > >>>>>>> or
>> > > >>>>>>>>>> Meld
>> > > >>>>>>>>>>>>> to
>> > > >>>>>>>>>>>>>>>>> spot my changes, but feel free to grasp the original
>> > file
>> > > >>>>>>> here:
>> > > >>>>>>>>>>>>>>>>> https://github.com/apache/
>> > kafka/blob/trunk/kafka-merge-
>> > > >>>> pr.py
>> > > >>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>> PS: It's just me or REPO_HOME env variable is not
>> used
>> > > >>>>>>> anywhere
>> > > >>>>>>>>> in
>> > > >>>>>>>>>>>> the
>> > > >>>>>>>>>>>>>>>>> merge script???
>> > > >>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>> Cheers,
>> > > >>>>>>>>>>>>>>>>> Eddie
>> > > >>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick Hunt <
>> > > >>>>>>>> phunt@apache.org
>> > > >>>>>>>>>>
>> > > >>>>>>>>>>>>>>> wrote:
>> > > >>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin Reed <
>> > > >>>>>>>>> breed@apache.org>
>> > > >>>>>>>>>>>>>>>> wrote:
>> > > >>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>> what you are suggesting sounds good, but i don't
>> know
>> > > >>> how
>> > > >>>>>>> to
>> > > >>>>>>>> do
>> > > >>>>>>>>>>>> it?
>> > > >>>>>>>>>>>>>>>> since
>> > > >>>>>>>>>>>>>>>>>>> in the end we are still just accepting diffs on
>> > > >>> patches,
>> > > >>>>>>> the
>> > > >>>>>>>>> only
>> > > >>>>>>>>>>>>>>> thing
>> > > >>>>>>>>>>>>>>>>>>> that changes is that we use svn rather than git
>> > right?
>> > > >>>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>> Notice the workflow Kafka uses - which includes
>> "git
>> > > >>> apply"
>> > > >>>>>>>> and
>> > > >>>>>>>>>>>>>>>> specifying
>> > > >>>>>>>>>>>>>>>>>> the author tag when committers commit (so that the
>> OP
>> > > >>> gets
>> > > >>>>>>>>> proper
>> > > >>>>>>>>>>>>>>>>>> attribution in the commit itself)
>> > > >>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/
>> > > >>>>>>>>>>>>>>>> Manual+Commit+Workflow
>> > > >>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>> Patrick
>> > > >>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>> i LOVE chris's idea! lets do it!
>> > > >>>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>> ben
>> > > >>>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>> On Sun, Sep 18, 2016 at 3:22 PM, Patrick Hunt <
>> > > >>>>>>>>> phunt@apache.org>
>> > > >>>>>>>>>>>>>>>> wrote:
>> > > >>>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>>> Ben, do you also want to update the "Applying a
>> > patch"
>> > > >>>>>>>> section
>> > > >>>>>>>>>> to
>> > > >>>>>>>>>>>>>>> make
>> > > >>>>>>>>>>>>>>>>>> it
>> > > >>>>>>>>>>>>>>>>>>>> git specific?
>> > > >>>>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>>> We (committers) should move to a model where
>> authors
>> > > >>> get
>> > > >>>>>>>>> proper
>> > > >>>>>>>>>>>>>>> credit
>> > > >>>>>>>>>>>>>>>>>> in
>> > > >>>>>>>>>>>>>>>>>>>> git. Our old workflow in svn resulted in only the
>> > > >>>>>>> committer
>> > > >>>>>>>>>> being
>> > > >>>>>>>>>>>>>>>>>> listed
>> > > >>>>>>>>>>>>>>>>>>>> (except that we listed the patch author in the
>> > commit
>> > > >>>>>>>>> message).
>> > > >>>>>>>>>>>> We
>> > > >>>>>>>>>>>>>>>>>> should
>> > > >>>>>>>>>>>>>>>>>>>> move to a model where the author of the patch
>> gets
>> > > >>> proper
>> > > >>>>>>>>> credit
>> > > >>>>>>>>>>>> in
>> > > >>>>>>>>>>>>>>>>>> git.
>> > > >>>>>>>>>>>>>>>>>>> I
>> > > >>>>>>>>>>>>>>>>>>>> believe we will get that if we use git for patch
>> > > >>>>>>>>>>>>>>> creation/application?
>> > > >>>>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>>> Chris brought up getting rid of CHANGES.txt
>> recently
>> > > >>> on
>> > > >>>>>>> the
>> > > >>>>>>>>> dev
>> > > >>>>>>>>>>>>> list
>> > > >>>>>>>>>>>>>>>>>> in a
>> > > >>>>>>>>>>>>>>>>>>>> separate thread - Chris do you want to implement
>> > that
>> > > >>>>>>> change
>> > > >>>>>>>>> now
>> > > >>>>>>>>>>>>>>> that
>> > > >>>>>>>>>>>>>>>>>>> we've
>> > > >>>>>>>>>>>>>>>>>>>> moved to git?
>> > > >>>>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>>> Patrick
>> > > >>>>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin Reed <
>> > > >>>>>>>>>> breed@apache.org
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>> wrote:
>> > > >>>>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>>>>> 1) actually in the previous step that was just
>> > > >>> adding
>> > > >>>>>>> new
>> > > >>>>>>>>>>>> files.
>> > > >>>>>>>>>>>>>>> you
>> > > >>>>>>>>>>>>>>>>>>>>>> still
>> > > >>>>>>>>>>>>>>>>>>>>>>> need the commit -a for the rest of the
>> changes.
>> > > >>> that's
>> > > >>>>>>> my
>> > > >>>>>>>>>>>> normal
>> > > >>>>>>>>>>>>>>>>>>>>>> workflow.
>> > > >>>>>>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>>>>> I think that will be confusing for most folks.
>> > They
>> > > >>>>>>>>> typically
>> > > >>>>>>>>>>>>>>> stage
>> > > >>>>>>>>>>>>>>>>>>>>>> all the changes and then commit or don't stage
>> and
>> > > >>> use
>> > > >>>>>>> -a.
>> > > >>>>>>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>>>> do you mind fixing it with your workflow.
>> commit -a
>> > > >>>>>>> doesn't
>> > > >>>>>>>>> get
>> > > >>>>>>>>>>>>> new
>> > > >>>>>>>>>>>>>>>>>>>>> files, which is why you need to do the add, but
>> i'm
>> > > >>> not
>> > > >>>>>>> the
>> > > >>>>>>>>>> most
>> > > >>>>>>>>>>>>>>>>>>>>> sophisticated git user, so
>> > > >>>>>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>>>>>> 2) i figured since we are using git now that
>> we
>> > > >>> should
>> > > >>>>>>>> use
>> > > >>>>>>>>>>>> git's
>> > > >>>>>>>>>>>>>>>>>>>>>> default.
>> > > >>>>>>>>>>>>>>>>>>>>>>> the patch should work (by default it seems to
>> > strip
>> > > >>>> the
>> > > >>>>>>>>> first
>> > > >>>>>>>>>>>>>>> path
>> > > >>>>>>>>>>>>>>>>>>>>>> element).
>> > > >>>>>>>>>>>>>>>>>>>>>>> does it not work for you?
>> > > >>>>>>>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>>>>> It will fail precommit in it's current state.
>> > > >>>>>>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>>>> fixed
>> > > >>>>>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>> --
>> > > >>>>>>>>>>>>>> Cheers
>> > > >>>>>>>>>>>>>> Michael.
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>> --
>> > > >>>>>>>>>>>> Cheers
>> > > >>>>>>>>>>>> Michael.
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>
>> > > >>>>>>>>>>
>> > > >>>>>>>>>
>> > > >>>>>>>>>
>> > > >>>>>>>>> --
>> > > >>>>>>>>> Cheers
>> > > >>>>>>>>> Michael.
>> > > >>>>>>>>>
>> > > >>>>>>>>
>> > > >>>>>>>
>> > > >>>>>
>> > > >>>>>
>> > > >>>>
>> > > >>>>
>> > > >>>> --
>> > > >>>> Cheers
>> > > >>>> Michael.
>> > > >>>>
>> > > >>>
>> > > >>
>> > > >>
>> > > >>
>> > > >> --
>> > > >> Cheers
>> > > >> Michael.
>> > > >>
>> > > >
>> > > >
>> > > >
>> > > > --
>> > > > Cheers
>> > > > Michael.
>> > >
>> > >
>> >
>>
>

Re: [VOTE] move Apache Zookeeper to git

Posted by Edward Ribeiro <ed...@gmail.com>.

Hi Patrick,

We can change the script so that it asks for jira password input on CLI
prompt if the JIRA username is set, for example. The change should be
straigthforward.

Alternatively, the python systems I have dealt with put credentials for
database access, etc, in configuration -- sometimes hidden -- files (say,
.env), but yet it is clear text stored.

Anyone has other suggestions?

Eddie

Em 9 de nov de 2016 4:18 PM, "Patrick Hunt" <ph...@apache.org> escreveu:

> Is there any alternative to step 4 as documented here?
> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> Merging+Github+Pull+Requests
>
> specifically it's asking to "export JIRA_PASSWORD=mypassword" which I feel
> very uncomfortable doing.
>
> Patrick
>
> On Wed, Oct 26, 2016 at 11:12 AM, Edward Ribeiro <edward.ribeiro@gmail.com
> >
> wrote:
>
> > AFAIK, yes. I say, if you mean to run unit tests and other CI tasks on
> PR.
> >
> > PS: I have just created a simple script HowTo at
> > https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> > Merging+Github+Pull+Requests
> > and linked from https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> > Index
> >
> > On Wed, Oct 26, 2016 at 3:59 PM, Flavio Junqueira <fp...@apache.org>
> wrote:
> >
> > > What about QA, are we still missing a github pre-commit queue?
> > >
> > > -Flavio
> > >
> > > > On 26 Oct 2016, at 18:53, Michael Han <ha...@cloudera.com> wrote:
> > > >
> > > > The comment bridging should be fixed now - see INFRA-12752 for more
> > > > details.
> > > >
> > > > On Wed, Oct 26, 2016 at 10:03 AM, Michael Han <ha...@cloudera.com>
> > wrote:
> > > >
> > > >>>> The git PR *review* comments for ZOOKEEPER-2597 didn't show up on
> > > JIRA.
> > > >>
> > > >> The bridge was working the day Infra made the change - see the
> > previous
> > > >> comments made by git bot on ZOOKEEPER-761. Now it seems stop
> working.
> > I
> > > am
> > > >> reopening INFRA-12752 and building a case.
> > > >>
> > > >> On Wed, Oct 26, 2016 at 9:45 AM, Edward Ribeiro <
> > > edward.ribeiro@gmail.com>
> > > >> wrote:
> > > >>
> > > >>> Dear community,
> > > >>>
> > > >>> The zk-merger-pr.py script has been merged into master (thanks a
> LOT
> > > Ben
> > > >>> Reed for reviewing/discussing/testing and commiting):
> > > >>> https://issues.apache.org/jira/browse/ZOOKEEPER-2597
> > > >>>
> > > >>> As stated in the issue and on GH, this tool is a modified version
> of
> > > >>> similar tools from Kafka, that is a copy of a Spark's one. It has
> > some
> > > >>> rough edges so we will certainly benefit from further enhancements
> > and
> > > >>> fixes. I changed the smallest possible pieces of code, just to make
> > it
> > > >>> work
> > > >>> on a ZK repo so the credits go to the original authors.
> > > >>>
> > > >>> Some notes:
> > > >>>
> > > >>> 1. The git PR *review* comments for ZOOKEEPER-2597 didn't show up
> on
> > > JIRA.
> > > >>> Only the opening and closing of the issue. Can we double check this
> > as
> > > >>> INFRA-12752 is closed, Michael Han?
> > > >>>
> > > >>> 2. I scribbled a draft on how use the tool at
> > > >>> https://docs.google.com/document/d/1i00ZXjrW2fu17vr_h7F1bUrq
> > > >>> Xg3urw4Hm7KirQDpPIU/edit
> > > >>> (still very crude, but feel free to improve it). I would like to
> move
> > > >>> this
> > > >>> text to https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> Index
> > > but
> > > >>> looks like I don't have permission to create a page there yet. Any
> > > help?
> > > >>>
> > > >>> Best regards,
> > > >>> Eddie
> > > >>>
> > > >>> On Sat, Oct 22, 2016 at 7:08 PM, Michael Han <ha...@cloudera.com>
> > > wrote:
> > > >>>
> > > >>>> FYI infra did some work in INFRA-12752 and the git PR comments can
> > be
> > > >>>> pushed to Apache JIRA.
> > > >>>>
> > > >>>> On Sat, Oct 8, 2016 at 8:01 AM, Flavio Junqueira <fp...@apache.org>
> > > >>> wrote:
> > > >>>>
> > > >>>>> This is not supported at the moment if nothing has changed:
> > > >>>>>
> > > >>>>> https://issues.apache.org/jira/browse/INFRA-11000 <
> > > >>>>> https://issues.apache.org/jira/browse/INFRA-11000>
> > > >>>>>
> > > >>>>> -Flavio
> > > >>>>>
> > > >>>>>> On 08 Oct 2016, at 00:54, Benjamin Reed <br...@apache.org>
> wrote:
> > > >>>>>>
> > > >>>>>> it doesn't look like we need to setup keys. this seems to work
> for
> > > >>> me:
> > > >>>>>>
> > > >>>>>> https://git-wip-us.apache.org/#committers-getting-started
> > > >>>>>>
> > > >>>>>> it does seem strange that we aren't using public keys and that
> i'm
> > > >>>>> sticking
> > > >>>>>> a password in .netrc :P i'm wondering if other projects were
> able
> > to
> > > >>>> get
> > > >>>>>> this going over ssh.
> > > >>>>>>
> > > >>>>>> i'll take a whack at cleaning up the svn and subversion
> > references.
> > > >>>>>>
> > > >>>>>> ben
> > > >>>>>>
> > > >>>>>> On Fri, Oct 7, 2016 at 12:59 PM, Camille Fournier <
> > > >>> camille@apache.org>
> > > >>>>>> wrote:
> > > >>>>>>
> > > >>>>>>> Hey folks,
> > > >>>>>>>
> > > >>>>>>> So I'm trying to get in a patch but this has not been updated
> to
> > > >>> tell
> > > >>>>>>> committers how to actually get the git keys set up:
> > > >>>>>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> > > >>>>> Committing+changes
> > > >>>>>>>
> > > >>>>>>> Can someone float me a link that says how to do this?
> > > >>>>>>>
> > > >>>>>>> Also a bunch of our documentation still discusses SVN and not
> > git,
> > > >>>> which
> > > >>>>>>> means we are not done with this migration. If you were pushing
> > for
> > > >>>> this
> > > >>>>>>> change can you please do some due diligence on the wikis and
> > > >>> correct
> > > >>>> the
> > > >>>>>>> stuff that refers to SVN?
> > > >>>>>>>
> > > >>>>>>> Thanks,
> > > >>>>>>> C
> > > >>>>>>>
> > > >>>>>>> On Wed, Oct 5, 2016 at 1:02 PM, Edward Ribeiro <
> > > >>>>> edward.ribeiro@gmail.com>
> > > >>>>>>> wrote:
> > > >>>>>>>
> > > >>>>>>>> Excuse me guys!
> > > >>>>>>>>
> > > >>>>>>>> I've written on Macbook Pro. No idea why GMail messed it up. I
> > was
> > > >>>> only
> > > >>>>>>>> able to see the strange characters when I pasted on a gist
> text
> > > >>> area.
> > > >>>>> The
> > > >>>>>>>> previous message is below, but if anyone is still having
> trouble
> > > >>> (I
> > > >>>>> tried
> > > >>>>>>>> to remove the weird character), I left a copy at:
> > > >>>>>>>> https://gist.github.com/eribeiro/
> da2a6a6c9a508610d52d0755fae835
> > 2d
> > > >>>>>>>>
> > > >>>>>>>> "Hi,
> > > >>>>>>>>
> > > >>>>>>>> The patch attached on ZOOKEEPER-2597 is a straightforward
> > > >>> adaptation
> > > >>>> of
> > > >>>>>>>> Kafka's one. It takes care of merging Github PR into Apache
> git
> > > >>> repo
> > > >>>>> and
> > > >>>>>>> a
> > > >>>>>>>> subsequent closing of the PR on the GH side, among other
> things
> > > >>>>>>> (rewriting
> > > >>>>>>>> of commit messages, etc). The current status is: the script
> > needs
> > > >>> to
> > > >>>> be
> > > >>>>>>>> reviewed/validated by a committer. It has been some time
> since I
> > > >>>>> uploaded
> > > >>>>>>>> the patch, so I gonna do another pass through it in the
> > meantime.
> > > >>>>>>>>
> > > >>>>>>>> There are some workflow issues beyond the scope of
> > ZOOKEEPER-2597
> > > >>>> that
> > > >>>>>>> need
> > > >>>>>>>> to be sorted out (IMO):
> > > >>>>>>>>
> > > >>>>>>>> 1. The normal workflow is to open a JIRA ticket before doing
> any
> > > >>> GH
> > > >>>> PR,
> > > >>>>>>>> that is, no JIRA-less PRs. The PR should have a title of the
> > form
> > > >>>>>>>> "ZOOKEEPER-xxxx: Title". This will trigger the Apache
> > JIRA-Github
> > > >>>>>>>> integration and it's opening show up in the JIRA ticket.
> > > >>>>>>>>
> > > >>>>>>>> 2. OTOH, not every Kafka PR needs a corresponding JIRA ticket.
> > > >>> There
> > > >>>>> are
> > > >>>>>>> a
> > > >>>>>>>> class of PRs with "MINOR" title that represent trivial code
> > > >>> changes
> > > >>>> and
> > > >>>>>>>> "HOT-FIX" title that fix urgent, but simple bugs. Both bypass
> > the
> > > >>>> JIRA
> > > >>>>>>>> creation step, even tough they are still subject to review.
> It's
> > > >>>> worth
> > > >>>>>>>> adopting a similar approach for ZK project?
> > > >>>>>>>>
> > > >>>>>>>> 3. IIRC (didn't find any page to confirm), Cassandra project
> > > >>>>> encourages,
> > > >>>>>>>> but not demands, that contributors also upload a patch file to
> > > >>> JIRA
> > > >>>>> even
> > > >>>>>>> in
> > > >>>>>>>> the case of a GH PR (as to leave a audit trail, I guess). Or,
> at
> > > >>>>> least,
> > > >>>>>>> C*
> > > >>>>>>>> project leaves up to the contributors to either open a GH PR
> or
> > > >>>> upload
> > > >>>>>>> the
> > > >>>>>>>> patch file to JIRA.
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> +1 about having a 'paper trail' of review comments on JIRA
> > and/or
> > > >>>>> mailing
> > > >>>>>>>> list (I would prefer the mailing list tbh). But as Michael and
> > > >>> Flavio
> > > >>>>>>>> pointed out, I never seen GH PR review **comments** being
> > written
> > > >>>> back
> > > >>>>> to
> > > >>>>>>>> JIRA, at least not in Kafka, Cassandra or Solr projects, that
> I
> > > >>> have
> > > >>>>>>>> followed more closely.
> > > >>>>>>>>
> > > >>>>>>>> Eddie"
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>> On Wed, Oct 5, 2016 at 1:35 PM, Michael Han <
> hanm@cloudera.com>
> > > >>>> wrote:
> > > >>>>>>>>
> > > >>>>>>>>> Eddie's mail contains lots of '=E2=80=8B'' which is unicode
> > > >>>> character
> > > >>>>>>>>> zero-width space, which might cause parsing trouble for some
> > mail
> > > >>>>>>>> clients.
> > > >>>>>>>>>
> > > >>>>>>>>> On Wed, Oct 5, 2016 at 6:42 AM, Flavio Junqueira <
> > fpj@apache.org
> > > >>>>
> > > >>>>>>> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>>> Dude, I'm just not able to parse your e-mail, did you write
> > that
> > > >>>> on a
> > > >>>>>>>>>> phone or something?
> > > >>>>>>>>>>
> > > >>>>>>>>>> -Flavio
> > > >>>>>>>>>>
> > > >>>>>>>>>>> On 05 Oct 2016, at 03:54, Edward Ribeiro <
> > > >>>> edward.ribeiro@gmail.com
> > > >>>>>>>>
> > > >>>>>>>>>> wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Hi,
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> The patch attached on ZOOKEEPER-2597 is a
> > > >>>>>>>>>>> straightforward adaptation of
> > > >>>>>>>>>>> Kafka's one. It takes care of merging Github PR into Apache
> > git
> > > >>>>>>> repo
> > > >>>>>>>>> and
> > > >>>>>>>>>>>  a
> > > >>>>>>>>>>> subsequent closing of the PR on the GH side
> > > >>>>>>>>>>>  among other things (rewriting of commit messages, etc)
> > > >>>>>>>>>>> . The current status is: the script needs to be
> > > >>> reviewed/validated
> > > >>>>>>>> by a
> > > >>>>>>>>>>> committer.
> > > >>>>>>>>>>> It has been some time since I uploaded the patch, so I
> gonna
> > > >>> do
> > > >>>>>>>>> another
> > > >>>>>>>>>>> pass through it in the meantime.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> T
> > > >>>>>>>>>>> here are some workflow issues beyond the scope of
> > > >>> ZOOKEEPER-2597
> > > >>>>>>>>>>>  that need to be sorted out (IMO)
> > > >>>>>>>>>>> :
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> 1. The normal workflow is to open a JIRA ticket before
> doing
> > > >>> any
> > > >>>> GH
> > > >>>>>>>> PR
> > > >>>>>>>>>>> , that is, no JIRA-less PRs.
> > > >>>>>>>>>>> The PR should have a title of the form "ZOOKEEPER-xxxx:
> > Title".
> > > >>>>>>> This
> > > >>>>>>>>> will
> > > >>>>>>>>>>> trigger the Apache JIRA-Github integration and it's opening
> > > >>> show
> > > >>>> up
> > > >>>>>>>> in
> > > >>>>>>>>>> the
> > > >>>>>>>>>>> JIRA ticket.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> 2.
> > > >>>>>>>>>>> OTOH, n
> > > >>>>>>>>>>> ot every Kafka PR needs a corresponding JIRA ticket
> > > >>>>>>>>>>> . 
> > > >>>>>>>>>>> There are a class of PR
> > > >>>>>>>>>>> s
> > > >>>>>>>>>>> with "MINOR"
> > > >>>>>>>>>>>  title
> > > >>>>>>>>>>> that represent trivial code changes
> > > >>>>>>>>>>>  and "HOT-FIX" title that fix urgent, but simple bugs.
> Both
> > > >>>>>>>>>>> bypass the JIRA creation step
> > > >>>>>>>>>>> , even tough they are still 
> > > >>>>>>>>>>> subject to review
> > > >>>>>>>>>>> .
> > > >>>>>>>>>>> It's worth adopting a similar approach for ZK project?
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> 3. IIRC
> > > >>>>>>>>>>>  (didn't find any page to confirm)
> > > >>>>>>>>>>> , Cassandra project encourages, but not demands, that
> > > >>> contributors
> > > >>>>>>>> also
> > > >>>>>>>>>>> upload a patch file to JIRA even in the case of a GH PR
> > > >>>>>>>>>>>  (as to leave a audit trail, I guess)
> > > >>>>>>>>>>> .
> > > >>>>>>>>>>> Or
> > > >>>>>>>>>>> ,
> > > >>>>>>>>>>> at
> > > >>>>>>>>>>>  
> > > >>>>>>>>>>> least
> > > >>>>>>>>>>> ,
> > > >>>>>>>>>>> C* project 
> > > >>>>>>>>>>> leave
> > > >>>>>>>>>>> s
> > > >>>>>>>>>>> up to the contributor
> > > >>>>>>>>>>> s
> > > >>>>>>>>>>> to either open a GH PR or upload the patch file
> > > >>>>>>>>>>>  to JIRA. In fact, Github allows the access to a raw patch
> > or
> > > >>>>>>> diff,
> > > >>>>>>>>> it's
> > > >>>>>>>>>>> just a matter of adding the ".patch" or ".diff" suffix to
> the
> > > >>> end
> > > >>>>>>> of
> > > >>>>>>>>> the
> > > >>>>>>>>>>> Pull Request URL.
> > > >>>>>>>>>>> 
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> +1 about having a 'paper trail'
> > > >>>>>>>>>>>  of review comments
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> o
> > > >>>>>>>>>>> n JIRA and
> > > >>>>>>>>>>> /or
> > > >>>>>>>>>>> mailing list (I
> > > >>>>>>>>>>>  would
> > > >>>>>>>>>>> prefer the mailing list tbh). But as Michael and Flavio
> > pointed
> > > >>>>>>> out,
> > > >>>>>>>> I
> > > >>>>>>>>>>> never seen
> > > >>>>>>>>>>> GH 
> > > >>>>>>>>>>> PR review
> > > >>>>>>>>>>> **
> > > >>>>>>>>>>> comments
> > > >>>>>>>>>>> **
> > > >>>>>>>>>>> being written back to JIRA, at least not in Kafka,
> Cassandra
> > > >>>>>>>>>>> or
> > > >>>>>>>>>>> Solr projects
> > > >>>>>>>>>>> , that I have followed more closely.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> Eddie
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> On Tue, Oct 4, 2016 at 6:40 PM, Michael Han <
> > hanm@cloudera.com
> > > >>>>
> > > >>>>>>>> wrote:
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>>>> as long as the opening/closing/commenting all get sent
> to
> > > >>> the
> > > >>>>>>>>> mailing
> > > >>>>>>>>>>>> list or recorded in jira
> > > >>>>>>>>>>>> Yeah, this is my impression as well, that we need to keep
> > > >>> certain
> > > >>>>>>>>> paper
> > > >>>>>>>>>>>> trail regarding activities and comments on ASF side (JIRA
> or
> > > >>> mail
> > > >>>>>>>>> list).
> > > >>>>>>>>>>>> Infra page said:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> - Any Pull Request that gets opened, closed, reopened or
> > > >>>>>>>>> **commented**
> > > >>>>>>>>>>>> on now gets recorded on the project's mailing list
> > > >>>>>>>>>>>> - If a project has a JIRA instance, any PRs or *comments*
> on
> > > >>> PRs
> > > >>>>>>>>> that
> > > >>>>>>>>>>>> include a JIRA ticket ID will trigger an update on that
> > > >>> specific
> > > >>>>>>>>>> ticket
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> I checked a couple Kafka and Spark JIRAs but I don't see
> any
> > > >>> of
> > > >>>>>>> the
> > > >>>>>>>>>>>> comments made in github PR were posted on JIRA, except the
> > > >>>>>>>> activities
> > > >>>>>>>>>> (open
> > > >>>>>>>>>>>> a PR, close a PR). Since both projects have been using
> > github
> > > >>> for
> > > >>>>>>> a
> > > >>>>>>>>>> while I
> > > >>>>>>>>>>>> assume such practice of NOT integrating comments between
> > > >>> github
> > > >>>>>>> and
> > > >>>>>>>>> ASF
> > > >>>>>>>>>>>> JIRA is acceptable? Though I feel it would be really
> useful
> > if
> > > >>>>>>>>> comments
> > > >>>>>>>>>>>> could converge in a single place as well, that will
> provide
> > a
> > > >>>>>>> clear
> > > >>>>>>>>>> history
> > > >>>>>>>>>>>> for a given technical issue.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> On Tue, Oct 4, 2016 at 12:06 PM, Flavio Junqueira <
> > > >>>> fpj@apache.org
> > > >>>>>>>>
> > > >>>>>>>>>> wrote:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> Until ZOOKEEPER-2597 <https://issues.apache.org/
> > > >>>>>>>>>>>> jira/browse/ZOOKEEPER-2597>
> > > >>>>>>>>>>>>> is fixed, we can't merge via github.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> For code reviews, we can use GH as long as the
> > > >>>>>>>>>> opening/closing/commenting
> > > >>>>>>>>>>>>> all get sent to the mailing list or recorded in jira. I
> > don't
> > > >>>>>>> think
> > > >>>>>>>>> we
> > > >>>>>>>>>>>> have
> > > >>>>>>>>>>>>> that yet, but it is possible according to this:
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> https://blogs.apache.org/infra/entry/improved_
> > > >>>>>>>>>>>>> integration_between_apache_and <
> https://blogs.apache.org/
> > > >>>>>>>>>>>>> infra/entry/improved_integration_between_apache_and>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> For now, we do need to upload patches and converge using
> > > >>> jira.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> I think Eddie has been looking at this process trying to
> > > >>>>>>> replicate
> > > >>>>>>>>> the
> > > >>>>>>>>>>>>> Kafka setup, so perhaps he can give an update if I'm
> right.
> > > >>>> Kafka
> > > >>>>>>>>>> doesn't
> > > >>>>>>>>>>>>> send every comment to the mailing list, though, but I'm
> not
> > > >>> sure
> > > >>>>>>> if
> > > >>>>>>>>>>>> that's
> > > >>>>>>>>>>>>> acceptable according to the ASF, I need to double-check.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> -Flavio
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> On 04 Oct 2016, at 19:42, Michael Han <
> hanm@cloudera.com>
> > > >>>>>>> wrote:
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Hi,
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> Now we've moved to git, what is the policy for uploading
> > > >>>> patches
> > > >>>>>>>> and
> > > >>>>>>>>>>>>> doing
> > > >>>>>>>>>>>>>> code reviews? I am asking because I've seen recently
> there
> > > >>> are
> > > >>>>>>> git
> > > >>>>>>>>>> pull
> > > >>>>>>>>>>>>>> requests coming in without associated patch file
> uploaded
> > to
> > > >>>>>>> JIRA.
> > > >>>>>>>>>> I've
> > > >>>>>>>>>>>>>> checked
> > > >>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> > > >>>>>>>>> HowToContribute
> > > >>>>>>>>>> ,
> > > >>>>>>>>>>>>>> looks like there is not much change regarding patch
> > process
> > > >>> -
> > > >>>> so
> > > >>>>>>>>>>>>> presumably
> > > >>>>>>>>>>>>>> we still need to generate and upload patch file to JIRA
> > for
> > > >>> the
> > > >>>>>>>>>> record,
> > > >>>>>>>>>>>>>> while using github (maybe in addition of review board,
> or
> > in
> > > >>>> the
> > > >>>>>>>>>> future
> > > >>>>>>>>>>>>>> with gerrit) to do code reviews?
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> On Wed, Sep 21, 2016 at 6:05 AM, Edward Ribeiro <
> > > >>>>>>>>>>>>> edward.ribeiro@gmail.com>
> > > >>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Cool, just open https://issues.apache.org/
> > > >>>>>>>>> jira/browse/ZOOKEEPER-2597
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> PS: I removed the REPO_HOME global variable.
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> On Wed, Sep 21, 2016 at 6:53 AM, Flavio Junqueira <
> > > >>>>>>>> fpj@apache.org>
> > > >>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> Better to have that in the form of a pull request or
> > diff.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> REPO_HOME does seem to be unused.
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> -Flavio
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> On 20 Sep 2016, at 18:57, Edward Ribeiro <
> > > >>>>>>>>> edward.ribeiro@gmail.com
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Hey, I have started porting the kafka-merge.py to
> work
> > > >>> on ZK
> > > >>>>>>>>> repos.
> > > >>>>>>>>>>>> I
> > > >>>>>>>>>>>>>>>> would
> > > >>>>>>>>>>>>>>>>> need someone to review it and help me test it now.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> The files were uploaded below, but I will create a
> > github
> > > >>>>>>> repo
> > > >>>>>>>>> yet
> > > >>>>>>>>>>>>>>> today.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> https://www.dropbox.com/sh/od8bet2574jttm3/
> > > >>>>>>>>>>>>>>>> AADv1DXTb8vfyVCmelFbYCEha?dl=0
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> I uploaded the kafka version script so that you can
> use
> > > >>> diff
> > > >>>>>>> or
> > > >>>>>>>>>> Meld
> > > >>>>>>>>>>>>> to
> > > >>>>>>>>>>>>>>>>> spot my changes, but feel free to grasp the original
> > file
> > > >>>>>>> here:
> > > >>>>>>>>>>>>>>>>> https://github.com/apache/
> > kafka/blob/trunk/kafka-merge-
> > > >>>> pr.py
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> PS: It's just me or REPO_HOME env variable is not
> used
> > > >>>>>>> anywhere
> > > >>>>>>>>> in
> > > >>>>>>>>>>>> the
> > > >>>>>>>>>>>>>>>>> merge script???
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> Cheers,
> > > >>>>>>>>>>>>>>>>> Eddie
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick Hunt <
> > > >>>>>>>> phunt@apache.org
> > > >>>>>>>>>>
> > > >>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin Reed <
> > > >>>>>>>>> breed@apache.org>
> > > >>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> what you are suggesting sounds good, but i don't
> know
> > > >>> how
> > > >>>>>>> to
> > > >>>>>>>> do
> > > >>>>>>>>>>>> it?
> > > >>>>>>>>>>>>>>>> since
> > > >>>>>>>>>>>>>>>>>>> in the end we are still just accepting diffs on
> > > >>> patches,
> > > >>>>>>> the
> > > >>>>>>>>> only
> > > >>>>>>>>>>>>>>> thing
> > > >>>>>>>>>>>>>>>>>>> that changes is that we use svn rather than git
> > right?
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> Notice the workflow Kafka uses - which includes "git
> > > >>> apply"
> > > >>>>>>>> and
> > > >>>>>>>>>>>>>>>> specifying
> > > >>>>>>>>>>>>>>>>>> the author tag when committers commit (so that the
> OP
> > > >>> gets
> > > >>>>>>>>> proper
> > > >>>>>>>>>>>>>>>>>> attribution in the commit itself)
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/
> > > >>>>>>>>>>>>>>>> Manual+Commit+Workflow
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> Patrick
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> i LOVE chris's idea! lets do it!
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> ben
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>> On Sun, Sep 18, 2016 at 3:22 PM, Patrick Hunt <
> > > >>>>>>>>> phunt@apache.org>
> > > >>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> Ben, do you also want to update the "Applying a
> > patch"
> > > >>>>>>>> section
> > > >>>>>>>>>> to
> > > >>>>>>>>>>>>>>> make
> > > >>>>>>>>>>>>>>>>>> it
> > > >>>>>>>>>>>>>>>>>>>> git specific?
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> We (committers) should move to a model where
> authors
> > > >>> get
> > > >>>>>>>>> proper
> > > >>>>>>>>>>>>>>> credit
> > > >>>>>>>>>>>>>>>>>> in
> > > >>>>>>>>>>>>>>>>>>>> git. Our old workflow in svn resulted in only the
> > > >>>>>>> committer
> > > >>>>>>>>>> being
> > > >>>>>>>>>>>>>>>>>> listed
> > > >>>>>>>>>>>>>>>>>>>> (except that we listed the patch author in the
> > commit
> > > >>>>>>>>> message).
> > > >>>>>>>>>>>> We
> > > >>>>>>>>>>>>>>>>>> should
> > > >>>>>>>>>>>>>>>>>>>> move to a model where the author of the patch gets
> > > >>> proper
> > > >>>>>>>>> credit
> > > >>>>>>>>>>>> in
> > > >>>>>>>>>>>>>>>>>> git.
> > > >>>>>>>>>>>>>>>>>>> I
> > > >>>>>>>>>>>>>>>>>>>> believe we will get that if we use git for patch
> > > >>>>>>>>>>>>>>> creation/application?
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> Chris brought up getting rid of CHANGES.txt
> recently
> > > >>> on
> > > >>>>>>> the
> > > >>>>>>>>> dev
> > > >>>>>>>>>>>>> list
> > > >>>>>>>>>>>>>>>>>> in a
> > > >>>>>>>>>>>>>>>>>>>> separate thread - Chris do you want to implement
> > that
> > > >>>>>>> change
> > > >>>>>>>>> now
> > > >>>>>>>>>>>>>>> that
> > > >>>>>>>>>>>>>>>>>>> we've
> > > >>>>>>>>>>>>>>>>>>>> moved to git?
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> Patrick
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin Reed <
> > > >>>>>>>>>> breed@apache.org
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> 1) actually in the previous step that was just
> > > >>> adding
> > > >>>>>>> new
> > > >>>>>>>>>>>> files.
> > > >>>>>>>>>>>>>>> you
> > > >>>>>>>>>>>>>>>>>>>>>> still
> > > >>>>>>>>>>>>>>>>>>>>>>> need the commit -a for the rest of the changes.
> > > >>> that's
> > > >>>>>>> my
> > > >>>>>>>>>>>> normal
> > > >>>>>>>>>>>>>>>>>>>>>> workflow.
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> I think that will be confusing for most folks.
> > They
> > > >>>>>>>>> typically
> > > >>>>>>>>>>>>>>> stage
> > > >>>>>>>>>>>>>>>>>>>>>> all the changes and then commit or don't stage
> and
> > > >>> use
> > > >>>>>>> -a.
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> do you mind fixing it with your workflow. commit
> -a
> > > >>>>>>> doesn't
> > > >>>>>>>>> get
> > > >>>>>>>>>>>>> new
> > > >>>>>>>>>>>>>>>>>>>>> files, which is why you need to do the add, but
> i'm
> > > >>> not
> > > >>>>>>> the
> > > >>>>>>>>>> most
> > > >>>>>>>>>>>>>>>>>>>>> sophisticated git user, so
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>> 2) i figured since we are using git now that we
> > > >>> should
> > > >>>>>>>> use
> > > >>>>>>>>>>>> git's
> > > >>>>>>>>>>>>>>>>>>>>>> default.
> > > >>>>>>>>>>>>>>>>>>>>>>> the patch should work (by default it seems to
> > strip
> > > >>>> the
> > > >>>>>>>>> first
> > > >>>>>>>>>>>>>>> path
> > > >>>>>>>>>>>>>>>>>>>>>> element).
> > > >>>>>>>>>>>>>>>>>>>>>>> does it not work for you?
> > > >>>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>> It will fail precommit in it's current state.
> > > >>>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>> fixed
> > > >>>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> --
> > > >>>>>>>>>>>>>> Cheers
> > > >>>>>>>>>>>>>> Michael.
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> --
> > > >>>>>>>>>>>> Cheers
> > > >>>>>>>>>>>> Michael.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> --
> > > >>>>>>>>> Cheers
> > > >>>>>>>>> Michael.
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> Cheers
> > > >>>> Michael.
> > > >>>>
> > > >>>
> > > >>
> > > >>
> > > >>
> > > >> --
> > > >> Cheers
> > > >> Michael.
> > > >>
> > > >
> > > >
> > > >
> > > > --
> > > > Cheers
> > > > Michael.
> > >
> > >
> >
>

Re: [VOTE] move Apache Zookeeper to git

Posted by Patrick Hunt <ph...@apache.org>.

Is there any alternative to step 4 as documented here?
https://cwiki.apache.org/confluence/display/ZOOKEEPER/Merging+Github+Pull+Requests

specifically it's asking to "export JIRA_PASSWORD=mypassword" which I feel
very uncomfortable doing.

Patrick

On Wed, Oct 26, 2016 at 11:12 AM, Edward Ribeiro <ed...@gmail.com>
wrote:

> AFAIK, yes. I say, if you mean to run unit tests and other CI tasks on PR.
>
> PS: I have just created a simple script HowTo at
> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> Merging+Github+Pull+Requests
> and linked from https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> Index
>
> On Wed, Oct 26, 2016 at 3:59 PM, Flavio Junqueira <fp...@apache.org> wrote:
>
> > What about QA, are we still missing a github pre-commit queue?
> >
> > -Flavio
> >
> > > On 26 Oct 2016, at 18:53, Michael Han <ha...@cloudera.com> wrote:
> > >
> > > The comment bridging should be fixed now - see INFRA-12752 for more
> > > details.
> > >
> > > On Wed, Oct 26, 2016 at 10:03 AM, Michael Han <ha...@cloudera.com>
> wrote:
> > >
> > >>>> The git PR *review* comments for ZOOKEEPER-2597 didn't show up on
> > JIRA.
> > >>
> > >> The bridge was working the day Infra made the change - see the
> previous
> > >> comments made by git bot on ZOOKEEPER-761. Now it seems stop working.
> I
> > am
> > >> reopening INFRA-12752 and building a case.
> > >>
> > >> On Wed, Oct 26, 2016 at 9:45 AM, Edward Ribeiro <
> > edward.ribeiro@gmail.com>
> > >> wrote:
> > >>
> > >>> Dear community,
> > >>>
> > >>> The zk-merger-pr.py script has been merged into master (thanks a LOT
> > Ben
> > >>> Reed for reviewing/discussing/testing and commiting):
> > >>> https://issues.apache.org/jira/browse/ZOOKEEPER-2597
> > >>>
> > >>> As stated in the issue and on GH, this tool is a modified version of
> > >>> similar tools from Kafka, that is a copy of a Spark's one. It has
> some
> > >>> rough edges so we will certainly benefit from further enhancements
> and
> > >>> fixes. I changed the smallest possible pieces of code, just to make
> it
> > >>> work
> > >>> on a ZK repo so the credits go to the original authors.
> > >>>
> > >>> Some notes:
> > >>>
> > >>> 1. The git PR *review* comments for ZOOKEEPER-2597 didn't show up on
> > JIRA.
> > >>> Only the opening and closing of the issue. Can we double check this
> as
> > >>> INFRA-12752 is closed, Michael Han?
> > >>>
> > >>> 2. I scribbled a draft on how use the tool at
> > >>> https://docs.google.com/document/d/1i00ZXjrW2fu17vr_h7F1bUrq
> > >>> Xg3urw4Hm7KirQDpPIU/edit
> > >>> (still very crude, but feel free to improve it). I would like to move
> > >>> this
> > >>> text to https://cwiki.apache.org/confluence/display/ZOOKEEPER/Index
> > but
> > >>> looks like I don't have permission to create a page there yet. Any
> > help?
> > >>>
> > >>> Best regards,
> > >>> Eddie
> > >>>
> > >>> On Sat, Oct 22, 2016 at 7:08 PM, Michael Han <ha...@cloudera.com>
> > wrote:
> > >>>
> > >>>> FYI infra did some work in INFRA-12752 and the git PR comments can
> be
> > >>>> pushed to Apache JIRA.
> > >>>>
> > >>>> On Sat, Oct 8, 2016 at 8:01 AM, Flavio Junqueira <fp...@apache.org>
> > >>> wrote:
> > >>>>
> > >>>>> This is not supported at the moment if nothing has changed:
> > >>>>>
> > >>>>> https://issues.apache.org/jira/browse/INFRA-11000 <
> > >>>>> https://issues.apache.org/jira/browse/INFRA-11000>
> > >>>>>
> > >>>>> -Flavio
> > >>>>>
> > >>>>>> On 08 Oct 2016, at 00:54, Benjamin Reed <br...@apache.org> wrote:
> > >>>>>>
> > >>>>>> it doesn't look like we need to setup keys. this seems to work for
> > >>> me:
> > >>>>>>
> > >>>>>> https://git-wip-us.apache.org/#committers-getting-started
> > >>>>>>
> > >>>>>> it does seem strange that we aren't using public keys and that i'm
> > >>>>> sticking
> > >>>>>> a password in .netrc :P i'm wondering if other projects were able
> to
> > >>>> get
> > >>>>>> this going over ssh.
> > >>>>>>
> > >>>>>> i'll take a whack at cleaning up the svn and subversion
> references.
> > >>>>>>
> > >>>>>> ben
> > >>>>>>
> > >>>>>> On Fri, Oct 7, 2016 at 12:59 PM, Camille Fournier <
> > >>> camille@apache.org>
> > >>>>>> wrote:
> > >>>>>>
> > >>>>>>> Hey folks,
> > >>>>>>>
> > >>>>>>> So I'm trying to get in a patch but this has not been updated to
> > >>> tell
> > >>>>>>> committers how to actually get the git keys set up:
> > >>>>>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> > >>>>> Committing+changes
> > >>>>>>>
> > >>>>>>> Can someone float me a link that says how to do this?
> > >>>>>>>
> > >>>>>>> Also a bunch of our documentation still discusses SVN and not
> git,
> > >>>> which
> > >>>>>>> means we are not done with this migration. If you were pushing
> for
> > >>>> this
> > >>>>>>> change can you please do some due diligence on the wikis and
> > >>> correct
> > >>>> the
> > >>>>>>> stuff that refers to SVN?
> > >>>>>>>
> > >>>>>>> Thanks,
> > >>>>>>> C
> > >>>>>>>
> > >>>>>>> On Wed, Oct 5, 2016 at 1:02 PM, Edward Ribeiro <
> > >>>>> edward.ribeiro@gmail.com>
> > >>>>>>> wrote:
> > >>>>>>>
> > >>>>>>>> Excuse me guys!
> > >>>>>>>>
> > >>>>>>>> I've written on Macbook Pro. No idea why GMail messed it up. I
> was
> > >>>> only
> > >>>>>>>> able to see the strange characters when I pasted on a gist text
> > >>> area.
> > >>>>> The
> > >>>>>>>> previous message is below, but if anyone is still having trouble
> > >>> (I
> > >>>>> tried
> > >>>>>>>> to remove the weird character), I left a copy at:
> > >>>>>>>> https://gist.github.com/eribeiro/da2a6a6c9a508610d52d0755fae835
> 2d
> > >>>>>>>>
> > >>>>>>>> "Hi,
> > >>>>>>>>
> > >>>>>>>> The patch attached on ZOOKEEPER-2597 is a straightforward
> > >>> adaptation
> > >>>> of
> > >>>>>>>> Kafka's one. It takes care of merging Github PR into Apache git
> > >>> repo
> > >>>>> and
> > >>>>>>> a
> > >>>>>>>> subsequent closing of the PR on the GH side, among other things
> > >>>>>>> (rewriting
> > >>>>>>>> of commit messages, etc). The current status is: the script
> needs
> > >>> to
> > >>>> be
> > >>>>>>>> reviewed/validated by a committer. It has been some time since I
> > >>>>> uploaded
> > >>>>>>>> the patch, so I gonna do another pass through it in the
> meantime.
> > >>>>>>>>
> > >>>>>>>> There are some workflow issues beyond the scope of
> ZOOKEEPER-2597
> > >>>> that
> > >>>>>>> need
> > >>>>>>>> to be sorted out (IMO):
> > >>>>>>>>
> > >>>>>>>> 1. The normal workflow is to open a JIRA ticket before doing any
> > >>> GH
> > >>>> PR,
> > >>>>>>>> that is, no JIRA-less PRs. The PR should have a title of the
> form
> > >>>>>>>> "ZOOKEEPER-xxxx: Title". This will trigger the Apache
> JIRA-Github
> > >>>>>>>> integration and it's opening show up in the JIRA ticket.
> > >>>>>>>>
> > >>>>>>>> 2. OTOH, not every Kafka PR needs a corresponding JIRA ticket.
> > >>> There
> > >>>>> are
> > >>>>>>> a
> > >>>>>>>> class of PRs with "MINOR" title that represent trivial code
> > >>> changes
> > >>>> and
> > >>>>>>>> "HOT-FIX" title that fix urgent, but simple bugs. Both bypass
> the
> > >>>> JIRA
> > >>>>>>>> creation step, even tough they are still subject to review. It's
> > >>>> worth
> > >>>>>>>> adopting a similar approach for ZK project?
> > >>>>>>>>
> > >>>>>>>> 3. IIRC (didn't find any page to confirm), Cassandra project
> > >>>>> encourages,
> > >>>>>>>> but not demands, that contributors also upload a patch file to
> > >>> JIRA
> > >>>>> even
> > >>>>>>> in
> > >>>>>>>> the case of a GH PR (as to leave a audit trail, I guess). Or, at
> > >>>>> least,
> > >>>>>>> C*
> > >>>>>>>> project leaves up to the contributors to either open a GH PR or
> > >>>> upload
> > >>>>>>> the
> > >>>>>>>> patch file to JIRA.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> +1 about having a 'paper trail' of review comments on JIRA
> and/or
> > >>>>> mailing
> > >>>>>>>> list (I would prefer the mailing list tbh). But as Michael and
> > >>> Flavio
> > >>>>>>>> pointed out, I never seen GH PR review **comments** being
> written
> > >>>> back
> > >>>>> to
> > >>>>>>>> JIRA, at least not in Kafka, Cassandra or Solr projects, that I
> > >>> have
> > >>>>>>>> followed more closely.
> > >>>>>>>>
> > >>>>>>>> Eddie"
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>> On Wed, Oct 5, 2016 at 1:35 PM, Michael Han <ha...@cloudera.com>
> > >>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> Eddie's mail contains lots of '=E2=80=8B'' which is unicode
> > >>>> character
> > >>>>>>>>> zero-width space, which might cause parsing trouble for some
> mail
> > >>>>>>>> clients.
> > >>>>>>>>>
> > >>>>>>>>> On Wed, Oct 5, 2016 at 6:42 AM, Flavio Junqueira <
> fpj@apache.org
> > >>>>
> > >>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> Dude, I'm just not able to parse your e-mail, did you write
> that
> > >>>> on a
> > >>>>>>>>>> phone or something?
> > >>>>>>>>>>
> > >>>>>>>>>> -Flavio
> > >>>>>>>>>>
> > >>>>>>>>>>> On 05 Oct 2016, at 03:54, Edward Ribeiro <
> > >>>> edward.ribeiro@gmail.com
> > >>>>>>>>
> > >>>>>>>>>> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>> Hi,
> > >>>>>>>>>>>
> > >>>>>>>>>>> The patch attached on ZOOKEEPER-2597 is a
> > >>>>>>>>>>> straightforward adaptation of
> > >>>>>>>>>>> Kafka's one. It takes care of merging Github PR into Apache
> git
> > >>>>>>> repo
> > >>>>>>>>> and
> > >>>>>>>>>>>  a
> > >>>>>>>>>>> subsequent closing of the PR on the GH side
> > >>>>>>>>>>>  among other things (rewriting of commit messages, etc)
> > >>>>>>>>>>> . The current status is: the script needs to be
> > >>> reviewed/validated
> > >>>>>>>> by a
> > >>>>>>>>>>> committer.
> > >>>>>>>>>>> It has been some time since I uploaded the patch, so I gonna
> > >>> do
> > >>>>>>>>> another
> > >>>>>>>>>>> pass through it in the meantime.
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> T
> > >>>>>>>>>>> here are some workflow issues beyond the scope of
> > >>> ZOOKEEPER-2597
> > >>>>>>>>>>>  that need to be sorted out (IMO)
> > >>>>>>>>>>> :
> > >>>>>>>>>>>
> > >>>>>>>>>>> 1. The normal workflow is to open a JIRA ticket before doing
> > >>> any
> > >>>> GH
> > >>>>>>>> PR
> > >>>>>>>>>>> , that is, no JIRA-less PRs.
> > >>>>>>>>>>> The PR should have a title of the form "ZOOKEEPER-xxxx:
> Title".
> > >>>>>>> This
> > >>>>>>>>> will
> > >>>>>>>>>>> trigger the Apache JIRA-Github integration and it's opening
> > >>> show
> > >>>> up
> > >>>>>>>> in
> > >>>>>>>>>> the
> > >>>>>>>>>>> JIRA ticket.
> > >>>>>>>>>>>
> > >>>>>>>>>>> 2.
> > >>>>>>>>>>> OTOH, n
> > >>>>>>>>>>> ot every Kafka PR needs a corresponding JIRA ticket
> > >>>>>>>>>>> . 
> > >>>>>>>>>>> There are a class of PR
> > >>>>>>>>>>> s
> > >>>>>>>>>>> with "MINOR"
> > >>>>>>>>>>>  title
> > >>>>>>>>>>> that represent trivial code changes
> > >>>>>>>>>>>  and "HOT-FIX" title that fix urgent, but simple bugs. Both
> > >>>>>>>>>>> bypass the JIRA creation step
> > >>>>>>>>>>> , even tough they are still 
> > >>>>>>>>>>> subject to review
> > >>>>>>>>>>> .
> > >>>>>>>>>>> It's worth adopting a similar approach for ZK project?
> > >>>>>>>>>>>
> > >>>>>>>>>>> 3. IIRC
> > >>>>>>>>>>>  (didn't find any page to confirm)
> > >>>>>>>>>>> , Cassandra project encourages, but not demands, that
> > >>> contributors
> > >>>>>>>> also
> > >>>>>>>>>>> upload a patch file to JIRA even in the case of a GH PR
> > >>>>>>>>>>>  (as to leave a audit trail, I guess)
> > >>>>>>>>>>> .
> > >>>>>>>>>>> Or
> > >>>>>>>>>>> ,
> > >>>>>>>>>>> at
> > >>>>>>>>>>>  
> > >>>>>>>>>>> least
> > >>>>>>>>>>> ,
> > >>>>>>>>>>> C* project 
> > >>>>>>>>>>> leave
> > >>>>>>>>>>> s
> > >>>>>>>>>>> up to the contributor
> > >>>>>>>>>>> s
> > >>>>>>>>>>> to either open a GH PR or upload the patch file
> > >>>>>>>>>>>  to JIRA. In fact, Github allows the access to a raw patch
> or
> > >>>>>>> diff,
> > >>>>>>>>> it's
> > >>>>>>>>>>> just a matter of adding the ".patch" or ".diff" suffix to the
> > >>> end
> > >>>>>>> of
> > >>>>>>>>> the
> > >>>>>>>>>>> Pull Request URL.
> > >>>>>>>>>>> 
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> +1 about having a 'paper trail'
> > >>>>>>>>>>>  of review comments
> > >>>>>>>>>>>
> > >>>>>>>>>>> o
> > >>>>>>>>>>> n JIRA and
> > >>>>>>>>>>> /or
> > >>>>>>>>>>> mailing list (I
> > >>>>>>>>>>>  would
> > >>>>>>>>>>> prefer the mailing list tbh). But as Michael and Flavio
> pointed
> > >>>>>>> out,
> > >>>>>>>> I
> > >>>>>>>>>>> never seen
> > >>>>>>>>>>> GH 
> > >>>>>>>>>>> PR review
> > >>>>>>>>>>> **
> > >>>>>>>>>>> comments
> > >>>>>>>>>>> **
> > >>>>>>>>>>> being written back to JIRA, at least not in Kafka, Cassandra
> > >>>>>>>>>>> or
> > >>>>>>>>>>> Solr projects
> > >>>>>>>>>>> , that I have followed more closely.
> > >>>>>>>>>>>
> > >>>>>>>>>>> Eddie
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> On Tue, Oct 4, 2016 at 6:40 PM, Michael Han <
> hanm@cloudera.com
> > >>>>
> > >>>>>>>> wrote:
> > >>>>>>>>>>>
> > >>>>>>>>>>>>>> as long as the opening/closing/commenting all get sent to
> > >>> the
> > >>>>>>>>> mailing
> > >>>>>>>>>>>> list or recorded in jira
> > >>>>>>>>>>>> Yeah, this is my impression as well, that we need to keep
> > >>> certain
> > >>>>>>>>> paper
> > >>>>>>>>>>>> trail regarding activities and comments on ASF side (JIRA or
> > >>> mail
> > >>>>>>>>> list).
> > >>>>>>>>>>>> Infra page said:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> - Any Pull Request that gets opened, closed, reopened or
> > >>>>>>>>> **commented**
> > >>>>>>>>>>>> on now gets recorded on the project's mailing list
> > >>>>>>>>>>>> - If a project has a JIRA instance, any PRs or *comments* on
> > >>> PRs
> > >>>>>>>>> that
> > >>>>>>>>>>>> include a JIRA ticket ID will trigger an update on that
> > >>> specific
> > >>>>>>>>>> ticket
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I checked a couple Kafka and Spark JIRAs but I don't see any
> > >>> of
> > >>>>>>> the
> > >>>>>>>>>>>> comments made in github PR were posted on JIRA, except the
> > >>>>>>>> activities
> > >>>>>>>>>> (open
> > >>>>>>>>>>>> a PR, close a PR). Since both projects have been using
> github
> > >>> for
> > >>>>>>> a
> > >>>>>>>>>> while I
> > >>>>>>>>>>>> assume such practice of NOT integrating comments between
> > >>> github
> > >>>>>>> and
> > >>>>>>>>> ASF
> > >>>>>>>>>>>> JIRA is acceptable? Though I feel it would be really useful
> if
> > >>>>>>>>> comments
> > >>>>>>>>>>>> could converge in a single place as well, that will provide
> a
> > >>>>>>> clear
> > >>>>>>>>>> history
> > >>>>>>>>>>>> for a given technical issue.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On Tue, Oct 4, 2016 at 12:06 PM, Flavio Junqueira <
> > >>>> fpj@apache.org
> > >>>>>>>>
> > >>>>>>>>>> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> Until ZOOKEEPER-2597 <https://issues.apache.org/
> > >>>>>>>>>>>> jira/browse/ZOOKEEPER-2597>
> > >>>>>>>>>>>>> is fixed, we can't merge via github.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> For code reviews, we can use GH as long as the
> > >>>>>>>>>> opening/closing/commenting
> > >>>>>>>>>>>>> all get sent to the mailing list or recorded in jira. I
> don't
> > >>>>>>> think
> > >>>>>>>>> we
> > >>>>>>>>>>>> have
> > >>>>>>>>>>>>> that yet, but it is possible according to this:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> https://blogs.apache.org/infra/entry/improved_
> > >>>>>>>>>>>>> integration_between_apache_and <https://blogs.apache.org/
> > >>>>>>>>>>>>> infra/entry/improved_integration_between_apache_and>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> For now, we do need to upload patches and converge using
> > >>> jira.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> I think Eddie has been looking at this process trying to
> > >>>>>>> replicate
> > >>>>>>>>> the
> > >>>>>>>>>>>>> Kafka setup, so perhaps he can give an update if I'm right.
> > >>>> Kafka
> > >>>>>>>>>> doesn't
> > >>>>>>>>>>>>> send every comment to the mailing list, though, but I'm not
> > >>> sure
> > >>>>>>> if
> > >>>>>>>>>>>> that's
> > >>>>>>>>>>>>> acceptable according to the ASF, I need to double-check.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> -Flavio
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On 04 Oct 2016, at 19:42, Michael Han <ha...@cloudera.com>
> > >>>>>>> wrote:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Hi,
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> Now we've moved to git, what is the policy for uploading
> > >>>> patches
> > >>>>>>>> and
> > >>>>>>>>>>>>> doing
> > >>>>>>>>>>>>>> code reviews? I am asking because I've seen recently there
> > >>> are
> > >>>>>>> git
> > >>>>>>>>>> pull
> > >>>>>>>>>>>>>> requests coming in without associated patch file uploaded
> to
> > >>>>>>> JIRA.
> > >>>>>>>>>> I've
> > >>>>>>>>>>>>>> checked
> > >>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> > >>>>>>>>> HowToContribute
> > >>>>>>>>>> ,
> > >>>>>>>>>>>>>> looks like there is not much change regarding patch
> process
> > >>> -
> > >>>> so
> > >>>>>>>>>>>>> presumably
> > >>>>>>>>>>>>>> we still need to generate and upload patch file to JIRA
> for
> > >>> the
> > >>>>>>>>>> record,
> > >>>>>>>>>>>>>> while using github (maybe in addition of review board, or
> in
> > >>>> the
> > >>>>>>>>>> future
> > >>>>>>>>>>>>>> with gerrit) to do code reviews?
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On Wed, Sep 21, 2016 at 6:05 AM, Edward Ribeiro <
> > >>>>>>>>>>>>> edward.ribeiro@gmail.com>
> > >>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Cool, just open https://issues.apache.org/
> > >>>>>>>>> jira/browse/ZOOKEEPER-2597
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> PS: I removed the REPO_HOME global variable.
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> On Wed, Sep 21, 2016 at 6:53 AM, Flavio Junqueira <
> > >>>>>>>> fpj@apache.org>
> > >>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> Better to have that in the form of a pull request or
> diff.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> REPO_HOME does seem to be unused.
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> -Flavio
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> On 20 Sep 2016, at 18:57, Edward Ribeiro <
> > >>>>>>>>> edward.ribeiro@gmail.com
> > >>>>>>>>>>>
> > >>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Hey, I have started porting the kafka-merge.py to work
> > >>> on ZK
> > >>>>>>>>> repos.
> > >>>>>>>>>>>> I
> > >>>>>>>>>>>>>>>> would
> > >>>>>>>>>>>>>>>>> need someone to review it and help me test it now.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> The files were uploaded below, but I will create a
> github
> > >>>>>>> repo
> > >>>>>>>>> yet
> > >>>>>>>>>>>>>>> today.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> https://www.dropbox.com/sh/od8bet2574jttm3/
> > >>>>>>>>>>>>>>>> AADv1DXTb8vfyVCmelFbYCEha?dl=0
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> I uploaded the kafka version script so that you can use
> > >>> diff
> > >>>>>>> or
> > >>>>>>>>>> Meld
> > >>>>>>>>>>>>> to
> > >>>>>>>>>>>>>>>>> spot my changes, but feel free to grasp the original
> file
> > >>>>>>> here:
> > >>>>>>>>>>>>>>>>> https://github.com/apache/
> kafka/blob/trunk/kafka-merge-
> > >>>> pr.py
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> PS: It's just me or REPO_HOME env variable is not used
> > >>>>>>> anywhere
> > >>>>>>>>> in
> > >>>>>>>>>>>> the
> > >>>>>>>>>>>>>>>>> merge script???
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> Cheers,
> > >>>>>>>>>>>>>>>>> Eddie
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick Hunt <
> > >>>>>>>> phunt@apache.org
> > >>>>>>>>>>
> > >>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin Reed <
> > >>>>>>>>> breed@apache.org>
> > >>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> what you are suggesting sounds good, but i don't know
> > >>> how
> > >>>>>>> to
> > >>>>>>>> do
> > >>>>>>>>>>>> it?
> > >>>>>>>>>>>>>>>> since
> > >>>>>>>>>>>>>>>>>>> in the end we are still just accepting diffs on
> > >>> patches,
> > >>>>>>> the
> > >>>>>>>>> only
> > >>>>>>>>>>>>>>> thing
> > >>>>>>>>>>>>>>>>>>> that changes is that we use svn rather than git
> right?
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Notice the workflow Kafka uses - which includes "git
> > >>> apply"
> > >>>>>>>> and
> > >>>>>>>>>>>>>>>> specifying
> > >>>>>>>>>>>>>>>>>> the author tag when committers commit (so that the OP
> > >>> gets
> > >>>>>>>>> proper
> > >>>>>>>>>>>>>>>>>> attribution in the commit itself)
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/
> > >>>>>>>>>>>>>>>> Manual+Commit+Workflow
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> Patrick
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> i LOVE chris's idea! lets do it!
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> ben
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>> On Sun, Sep 18, 2016 at 3:22 PM, Patrick Hunt <
> > >>>>>>>>> phunt@apache.org>
> > >>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> Ben, do you also want to update the "Applying a
> patch"
> > >>>>>>>> section
> > >>>>>>>>>> to
> > >>>>>>>>>>>>>>> make
> > >>>>>>>>>>>>>>>>>> it
> > >>>>>>>>>>>>>>>>>>>> git specific?
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> We (committers) should move to a model where authors
> > >>> get
> > >>>>>>>>> proper
> > >>>>>>>>>>>>>>> credit
> > >>>>>>>>>>>>>>>>>> in
> > >>>>>>>>>>>>>>>>>>>> git. Our old workflow in svn resulted in only the
> > >>>>>>> committer
> > >>>>>>>>>> being
> > >>>>>>>>>>>>>>>>>> listed
> > >>>>>>>>>>>>>>>>>>>> (except that we listed the patch author in the
> commit
> > >>>>>>>>> message).
> > >>>>>>>>>>>> We
> > >>>>>>>>>>>>>>>>>> should
> > >>>>>>>>>>>>>>>>>>>> move to a model where the author of the patch gets
> > >>> proper
> > >>>>>>>>> credit
> > >>>>>>>>>>>> in
> > >>>>>>>>>>>>>>>>>> git.
> > >>>>>>>>>>>>>>>>>>> I
> > >>>>>>>>>>>>>>>>>>>> believe we will get that if we use git for patch
> > >>>>>>>>>>>>>>> creation/application?
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> Chris brought up getting rid of CHANGES.txt recently
> > >>> on
> > >>>>>>> the
> > >>>>>>>>> dev
> > >>>>>>>>>>>>> list
> > >>>>>>>>>>>>>>>>>> in a
> > >>>>>>>>>>>>>>>>>>>> separate thread - Chris do you want to implement
> that
> > >>>>>>> change
> > >>>>>>>>> now
> > >>>>>>>>>>>>>>> that
> > >>>>>>>>>>>>>>>>>>> we've
> > >>>>>>>>>>>>>>>>>>>> moved to git?
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> Patrick
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin Reed <
> > >>>>>>>>>> breed@apache.org
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> 1) actually in the previous step that was just
> > >>> adding
> > >>>>>>> new
> > >>>>>>>>>>>> files.
> > >>>>>>>>>>>>>>> you
> > >>>>>>>>>>>>>>>>>>>>>> still
> > >>>>>>>>>>>>>>>>>>>>>>> need the commit -a for the rest of the changes.
> > >>> that's
> > >>>>>>> my
> > >>>>>>>>>>>> normal
> > >>>>>>>>>>>>>>>>>>>>>> workflow.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> I think that will be confusing for most folks.
> They
> > >>>>>>>>> typically
> > >>>>>>>>>>>>>>> stage
> > >>>>>>>>>>>>>>>>>>>>>> all the changes and then commit or don't stage and
> > >>> use
> > >>>>>>> -a.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> do you mind fixing it with your workflow. commit -a
> > >>>>>>> doesn't
> > >>>>>>>>> get
> > >>>>>>>>>>>>> new
> > >>>>>>>>>>>>>>>>>>>>> files, which is why you need to do the add, but i'm
> > >>> not
> > >>>>>>> the
> > >>>>>>>>>> most
> > >>>>>>>>>>>>>>>>>>>>> sophisticated git user, so
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>> 2) i figured since we are using git now that we
> > >>> should
> > >>>>>>>> use
> > >>>>>>>>>>>> git's
> > >>>>>>>>>>>>>>>>>>>>>> default.
> > >>>>>>>>>>>>>>>>>>>>>>> the patch should work (by default it seems to
> strip
> > >>>> the
> > >>>>>>>>> first
> > >>>>>>>>>>>>>>> path
> > >>>>>>>>>>>>>>>>>>>>>> element).
> > >>>>>>>>>>>>>>>>>>>>>>> does it not work for you?
> > >>>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>> It will fail precommit in it's current state.
> > >>>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>> fixed
> > >>>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> --
> > >>>>>>>>>>>>>> Cheers
> > >>>>>>>>>>>>>> Michael.
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> --
> > >>>>>>>>>>>> Cheers
> > >>>>>>>>>>>> Michael.
> > >>>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> --
> > >>>>>>>>> Cheers
> > >>>>>>>>> Michael.
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Cheers
> > >>>> Michael.
> > >>>>
> > >>>
> > >>
> > >>
> > >>
> > >> --
> > >> Cheers
> > >> Michael.
> > >>
> > >
> > >
> > >
> > > --
> > > Cheers
> > > Michael.
> >
> >
>

Re: [VOTE] move Apache Zookeeper to git

Posted by Edward Ribeiro <ed...@gmail.com>.

AFAIK, yes. I say, if you mean to run unit tests and other CI tasks on PR.

PS: I have just created a simple script HowTo at
https://cwiki.apache.org/confluence/display/ZOOKEEPER/Merging+Github+Pull+Requests
and linked from https://cwiki.apache.org/confluence/display/ZOOKEEPER/Index

On Wed, Oct 26, 2016 at 3:59 PM, Flavio Junqueira <fp...@apache.org> wrote:

> What about QA, are we still missing a github pre-commit queue?
>
> -Flavio
>
> > On 26 Oct 2016, at 18:53, Michael Han <ha...@cloudera.com> wrote:
> >
> > The comment bridging should be fixed now - see INFRA-12752 for more
> > details.
> >
> > On Wed, Oct 26, 2016 at 10:03 AM, Michael Han <ha...@cloudera.com> wrote:
> >
> >>>> The git PR *review* comments for ZOOKEEPER-2597 didn't show up on
> JIRA.
> >>
> >> The bridge was working the day Infra made the change - see the previous
> >> comments made by git bot on ZOOKEEPER-761. Now it seems stop working. I
> am
> >> reopening INFRA-12752 and building a case.
> >>
> >> On Wed, Oct 26, 2016 at 9:45 AM, Edward Ribeiro <
> edward.ribeiro@gmail.com>
> >> wrote:
> >>
> >>> Dear community,
> >>>
> >>> The zk-merger-pr.py script has been merged into master (thanks a LOT
> Ben
> >>> Reed for reviewing/discussing/testing and commiting):
> >>> https://issues.apache.org/jira/browse/ZOOKEEPER-2597
> >>>
> >>> As stated in the issue and on GH, this tool is a modified version of
> >>> similar tools from Kafka, that is a copy of a Spark's one. It has some
> >>> rough edges so we will certainly benefit from further enhancements and
> >>> fixes. I changed the smallest possible pieces of code, just to make it
> >>> work
> >>> on a ZK repo so the credits go to the original authors.
> >>>
> >>> Some notes:
> >>>
> >>> 1. The git PR *review* comments for ZOOKEEPER-2597 didn't show up on
> JIRA.
> >>> Only the opening and closing of the issue. Can we double check this as
> >>> INFRA-12752 is closed, Michael Han?
> >>>
> >>> 2. I scribbled a draft on how use the tool at
> >>> https://docs.google.com/document/d/1i00ZXjrW2fu17vr_h7F1bUrq
> >>> Xg3urw4Hm7KirQDpPIU/edit
> >>> (still very crude, but feel free to improve it). I would like to move
> >>> this
> >>> text to https://cwiki.apache.org/confluence/display/ZOOKEEPER/Index
> but
> >>> looks like I don't have permission to create a page there yet. Any
> help?
> >>>
> >>> Best regards,
> >>> Eddie
> >>>
> >>> On Sat, Oct 22, 2016 at 7:08 PM, Michael Han <ha...@cloudera.com>
> wrote:
> >>>
> >>>> FYI infra did some work in INFRA-12752 and the git PR comments can be
> >>>> pushed to Apache JIRA.
> >>>>
> >>>> On Sat, Oct 8, 2016 at 8:01 AM, Flavio Junqueira <fp...@apache.org>
> >>> wrote:
> >>>>
> >>>>> This is not supported at the moment if nothing has changed:
> >>>>>
> >>>>> https://issues.apache.org/jira/browse/INFRA-11000 <
> >>>>> https://issues.apache.org/jira/browse/INFRA-11000>
> >>>>>
> >>>>> -Flavio
> >>>>>
> >>>>>> On 08 Oct 2016, at 00:54, Benjamin Reed <br...@apache.org> wrote:
> >>>>>>
> >>>>>> it doesn't look like we need to setup keys. this seems to work for
> >>> me:
> >>>>>>
> >>>>>> https://git-wip-us.apache.org/#committers-getting-started
> >>>>>>
> >>>>>> it does seem strange that we aren't using public keys and that i'm
> >>>>> sticking
> >>>>>> a password in .netrc :P i'm wondering if other projects were able to
> >>>> get
> >>>>>> this going over ssh.
> >>>>>>
> >>>>>> i'll take a whack at cleaning up the svn and subversion references.
> >>>>>>
> >>>>>> ben
> >>>>>>
> >>>>>> On Fri, Oct 7, 2016 at 12:59 PM, Camille Fournier <
> >>> camille@apache.org>
> >>>>>> wrote:
> >>>>>>
> >>>>>>> Hey folks,
> >>>>>>>
> >>>>>>> So I'm trying to get in a patch but this has not been updated to
> >>> tell
> >>>>>>> committers how to actually get the git keys set up:
> >>>>>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> >>>>> Committing+changes
> >>>>>>>
> >>>>>>> Can someone float me a link that says how to do this?
> >>>>>>>
> >>>>>>> Also a bunch of our documentation still discusses SVN and not git,
> >>>> which
> >>>>>>> means we are not done with this migration. If you were pushing for
> >>>> this
> >>>>>>> change can you please do some due diligence on the wikis and
> >>> correct
> >>>> the
> >>>>>>> stuff that refers to SVN?
> >>>>>>>
> >>>>>>> Thanks,
> >>>>>>> C
> >>>>>>>
> >>>>>>> On Wed, Oct 5, 2016 at 1:02 PM, Edward Ribeiro <
> >>>>> edward.ribeiro@gmail.com>
> >>>>>>> wrote:
> >>>>>>>
> >>>>>>>> Excuse me guys!
> >>>>>>>>
> >>>>>>>> I've written on Macbook Pro. No idea why GMail messed it up. I was
> >>>> only
> >>>>>>>> able to see the strange characters when I pasted on a gist text
> >>> area.
> >>>>> The
> >>>>>>>> previous message is below, but if anyone is still having trouble
> >>> (I
> >>>>> tried
> >>>>>>>> to remove the weird character), I left a copy at:
> >>>>>>>> https://gist.github.com/eribeiro/da2a6a6c9a508610d52d0755fae8352d
> >>>>>>>>
> >>>>>>>> "Hi,
> >>>>>>>>
> >>>>>>>> The patch attached on ZOOKEEPER-2597 is a straightforward
> >>> adaptation
> >>>> of
> >>>>>>>> Kafka's one. It takes care of merging Github PR into Apache git
> >>> repo
> >>>>> and
> >>>>>>> a
> >>>>>>>> subsequent closing of the PR on the GH side, among other things
> >>>>>>> (rewriting
> >>>>>>>> of commit messages, etc). The current status is: the script needs
> >>> to
> >>>> be
> >>>>>>>> reviewed/validated by a committer. It has been some time since I
> >>>>> uploaded
> >>>>>>>> the patch, so I gonna do another pass through it in the meantime.
> >>>>>>>>
> >>>>>>>> There are some workflow issues beyond the scope of ZOOKEEPER-2597
> >>>> that
> >>>>>>> need
> >>>>>>>> to be sorted out (IMO):
> >>>>>>>>
> >>>>>>>> 1. The normal workflow is to open a JIRA ticket before doing any
> >>> GH
> >>>> PR,
> >>>>>>>> that is, no JIRA-less PRs. The PR should have a title of the form
> >>>>>>>> "ZOOKEEPER-xxxx: Title". This will trigger the Apache JIRA-Github
> >>>>>>>> integration and it's opening show up in the JIRA ticket.
> >>>>>>>>
> >>>>>>>> 2. OTOH, not every Kafka PR needs a corresponding JIRA ticket.
> >>> There
> >>>>> are
> >>>>>>> a
> >>>>>>>> class of PRs with "MINOR" title that represent trivial code
> >>> changes
> >>>> and
> >>>>>>>> "HOT-FIX" title that fix urgent, but simple bugs. Both bypass the
> >>>> JIRA
> >>>>>>>> creation step, even tough they are still subject to review. It's
> >>>> worth
> >>>>>>>> adopting a similar approach for ZK project?
> >>>>>>>>
> >>>>>>>> 3. IIRC (didn't find any page to confirm), Cassandra project
> >>>>> encourages,
> >>>>>>>> but not demands, that contributors also upload a patch file to
> >>> JIRA
> >>>>> even
> >>>>>>> in
> >>>>>>>> the case of a GH PR (as to leave a audit trail, I guess). Or, at
> >>>>> least,
> >>>>>>> C*
> >>>>>>>> project leaves up to the contributors to either open a GH PR or
> >>>> upload
> >>>>>>> the
> >>>>>>>> patch file to JIRA.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> +1 about having a 'paper trail' of review comments on JIRA and/or
> >>>>> mailing
> >>>>>>>> list (I would prefer the mailing list tbh). But as Michael and
> >>> Flavio
> >>>>>>>> pointed out, I never seen GH PR review **comments** being written
> >>>> back
> >>>>> to
> >>>>>>>> JIRA, at least not in Kafka, Cassandra or Solr projects, that I
> >>> have
> >>>>>>>> followed more closely.
> >>>>>>>>
> >>>>>>>> Eddie"
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Wed, Oct 5, 2016 at 1:35 PM, Michael Han <ha...@cloudera.com>
> >>>> wrote:
> >>>>>>>>
> >>>>>>>>> Eddie's mail contains lots of '=E2=80=8B'' which is unicode
> >>>> character
> >>>>>>>>> zero-width space, which might cause parsing trouble for some mail
> >>>>>>>> clients.
> >>>>>>>>>
> >>>>>>>>> On Wed, Oct 5, 2016 at 6:42 AM, Flavio Junqueira <fpj@apache.org
> >>>>
> >>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Dude, I'm just not able to parse your e-mail, did you write that
> >>>> on a
> >>>>>>>>>> phone or something?
> >>>>>>>>>>
> >>>>>>>>>> -Flavio
> >>>>>>>>>>
> >>>>>>>>>>> On 05 Oct 2016, at 03:54, Edward Ribeiro <
> >>>> edward.ribeiro@gmail.com
> >>>>>>>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>> Hi,
> >>>>>>>>>>>
> >>>>>>>>>>> The patch attached on ZOOKEEPER-2597 is a
> >>>>>>>>>>> straightforward adaptation of
> >>>>>>>>>>> Kafka's one. It takes care of merging Github PR into Apache git
> >>>>>>> repo
> >>>>>>>>> and
> >>>>>>>>>>>  a
> >>>>>>>>>>> subsequent closing of the PR on the GH side
> >>>>>>>>>>>  among other things (rewriting of commit messages, etc)
> >>>>>>>>>>> . The current status is: the script needs to be
> >>> reviewed/validated
> >>>>>>>> by a
> >>>>>>>>>>> committer.
> >>>>>>>>>>> It has been some time since I uploaded the patch, so I gonna
> >>> do
> >>>>>>>>> another
> >>>>>>>>>>> pass through it in the meantime.
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> T
> >>>>>>>>>>> here are some workflow issues beyond the scope of
> >>> ZOOKEEPER-2597
> >>>>>>>>>>>  that need to be sorted out (IMO)
> >>>>>>>>>>> :
> >>>>>>>>>>>
> >>>>>>>>>>> 1. The normal workflow is to open a JIRA ticket before doing
> >>> any
> >>>> GH
> >>>>>>>> PR
> >>>>>>>>>>> , that is, no JIRA-less PRs.
> >>>>>>>>>>> The PR should have a title of the form "ZOOKEEPER-xxxx: Title".
> >>>>>>> This
> >>>>>>>>> will
> >>>>>>>>>>> trigger the Apache JIRA-Github integration and it's opening
> >>> show
> >>>> up
> >>>>>>>> in
> >>>>>>>>>> the
> >>>>>>>>>>> JIRA ticket.
> >>>>>>>>>>>
> >>>>>>>>>>> 2.
> >>>>>>>>>>> OTOH, n
> >>>>>>>>>>> ot every Kafka PR needs a corresponding JIRA ticket
> >>>>>>>>>>> . 
> >>>>>>>>>>> There are a class of PR
> >>>>>>>>>>> s
> >>>>>>>>>>> with "MINOR"
> >>>>>>>>>>>  title
> >>>>>>>>>>> that represent trivial code changes
> >>>>>>>>>>>  and "HOT-FIX" title that fix urgent, but simple bugs. Both
> >>>>>>>>>>> bypass the JIRA creation step
> >>>>>>>>>>> , even tough they are still 
> >>>>>>>>>>> subject to review
> >>>>>>>>>>> .
> >>>>>>>>>>> It's worth adopting a similar approach for ZK project?
> >>>>>>>>>>>
> >>>>>>>>>>> 3. IIRC
> >>>>>>>>>>>  (didn't find any page to confirm)
> >>>>>>>>>>> , Cassandra project encourages, but not demands, that
> >>> contributors
> >>>>>>>> also
> >>>>>>>>>>> upload a patch file to JIRA even in the case of a GH PR
> >>>>>>>>>>>  (as to leave a audit trail, I guess)
> >>>>>>>>>>> .
> >>>>>>>>>>> Or
> >>>>>>>>>>> ,
> >>>>>>>>>>> at
> >>>>>>>>>>>  
> >>>>>>>>>>> least
> >>>>>>>>>>> ,
> >>>>>>>>>>> C* project 
> >>>>>>>>>>> leave
> >>>>>>>>>>> s
> >>>>>>>>>>> up to the contributor
> >>>>>>>>>>> s
> >>>>>>>>>>> to either open a GH PR or upload the patch file
> >>>>>>>>>>>  to JIRA. In fact, Github allows the access to a raw patch or
> >>>>>>> diff,
> >>>>>>>>> it's
> >>>>>>>>>>> just a matter of adding the ".patch" or ".diff" suffix to the
> >>> end
> >>>>>>> of
> >>>>>>>>> the
> >>>>>>>>>>> Pull Request URL.
> >>>>>>>>>>> 
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> +1 about having a 'paper trail'
> >>>>>>>>>>>  of review comments
> >>>>>>>>>>>
> >>>>>>>>>>> o
> >>>>>>>>>>> n JIRA and
> >>>>>>>>>>> /or
> >>>>>>>>>>> mailing list (I
> >>>>>>>>>>>  would
> >>>>>>>>>>> prefer the mailing list tbh). But as Michael and Flavio pointed
> >>>>>>> out,
> >>>>>>>> I
> >>>>>>>>>>> never seen
> >>>>>>>>>>> GH 
> >>>>>>>>>>> PR review
> >>>>>>>>>>> **
> >>>>>>>>>>> comments
> >>>>>>>>>>> **
> >>>>>>>>>>> being written back to JIRA, at least not in Kafka, Cassandra
> >>>>>>>>>>> or
> >>>>>>>>>>> Solr projects
> >>>>>>>>>>> , that I have followed more closely.
> >>>>>>>>>>>
> >>>>>>>>>>> Eddie
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> On Tue, Oct 4, 2016 at 6:40 PM, Michael Han <hanm@cloudera.com
> >>>>
> >>>>>>>> wrote:
> >>>>>>>>>>>
> >>>>>>>>>>>>>> as long as the opening/closing/commenting all get sent to
> >>> the
> >>>>>>>>> mailing
> >>>>>>>>>>>> list or recorded in jira
> >>>>>>>>>>>> Yeah, this is my impression as well, that we need to keep
> >>> certain
> >>>>>>>>> paper
> >>>>>>>>>>>> trail regarding activities and comments on ASF side (JIRA or
> >>> mail
> >>>>>>>>> list).
> >>>>>>>>>>>> Infra page said:
> >>>>>>>>>>>>
> >>>>>>>>>>>> - Any Pull Request that gets opened, closed, reopened or
> >>>>>>>>> **commented**
> >>>>>>>>>>>> on now gets recorded on the project's mailing list
> >>>>>>>>>>>> - If a project has a JIRA instance, any PRs or *comments* on
> >>> PRs
> >>>>>>>>> that
> >>>>>>>>>>>> include a JIRA ticket ID will trigger an update on that
> >>> specific
> >>>>>>>>>> ticket
> >>>>>>>>>>>>
> >>>>>>>>>>>> I checked a couple Kafka and Spark JIRAs but I don't see any
> >>> of
> >>>>>>> the
> >>>>>>>>>>>> comments made in github PR were posted on JIRA, except the
> >>>>>>>> activities
> >>>>>>>>>> (open
> >>>>>>>>>>>> a PR, close a PR). Since both projects have been using github
> >>> for
> >>>>>>> a
> >>>>>>>>>> while I
> >>>>>>>>>>>> assume such practice of NOT integrating comments between
> >>> github
> >>>>>>> and
> >>>>>>>>> ASF
> >>>>>>>>>>>> JIRA is acceptable? Though I feel it would be really useful if
> >>>>>>>>> comments
> >>>>>>>>>>>> could converge in a single place as well, that will provide a
> >>>>>>> clear
> >>>>>>>>>> history
> >>>>>>>>>>>> for a given technical issue.
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Tue, Oct 4, 2016 at 12:06 PM, Flavio Junqueira <
> >>>> fpj@apache.org
> >>>>>>>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> Until ZOOKEEPER-2597 <https://issues.apache.org/
> >>>>>>>>>>>> jira/browse/ZOOKEEPER-2597>
> >>>>>>>>>>>>> is fixed, we can't merge via github.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> For code reviews, we can use GH as long as the
> >>>>>>>>>> opening/closing/commenting
> >>>>>>>>>>>>> all get sent to the mailing list or recorded in jira. I don't
> >>>>>>> think
> >>>>>>>>> we
> >>>>>>>>>>>> have
> >>>>>>>>>>>>> that yet, but it is possible according to this:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> https://blogs.apache.org/infra/entry/improved_
> >>>>>>>>>>>>> integration_between_apache_and <https://blogs.apache.org/
> >>>>>>>>>>>>> infra/entry/improved_integration_between_apache_and>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> For now, we do need to upload patches and converge using
> >>> jira.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> I think Eddie has been looking at this process trying to
> >>>>>>> replicate
> >>>>>>>>> the
> >>>>>>>>>>>>> Kafka setup, so perhaps he can give an update if I'm right.
> >>>> Kafka
> >>>>>>>>>> doesn't
> >>>>>>>>>>>>> send every comment to the mailing list, though, but I'm not
> >>> sure
> >>>>>>> if
> >>>>>>>>>>>> that's
> >>>>>>>>>>>>> acceptable according to the ASF, I need to double-check.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> -Flavio
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> On 04 Oct 2016, at 19:42, Michael Han <ha...@cloudera.com>
> >>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Hi,
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> Now we've moved to git, what is the policy for uploading
> >>>> patches
> >>>>>>>> and
> >>>>>>>>>>>>> doing
> >>>>>>>>>>>>>> code reviews? I am asking because I've seen recently there
> >>> are
> >>>>>>> git
> >>>>>>>>>> pull
> >>>>>>>>>>>>>> requests coming in without associated patch file uploaded to
> >>>>>>> JIRA.
> >>>>>>>>>> I've
> >>>>>>>>>>>>>> checked
> >>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> >>>>>>>>> HowToContribute
> >>>>>>>>>> ,
> >>>>>>>>>>>>>> looks like there is not much change regarding patch process
> >>> -
> >>>> so
> >>>>>>>>>>>>> presumably
> >>>>>>>>>>>>>> we still need to generate and upload patch file to JIRA for
> >>> the
> >>>>>>>>>> record,
> >>>>>>>>>>>>>> while using github (maybe in addition of review board, or in
> >>>> the
> >>>>>>>>>> future
> >>>>>>>>>>>>>> with gerrit) to do code reviews?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Wed, Sep 21, 2016 at 6:05 AM, Edward Ribeiro <
> >>>>>>>>>>>>> edward.ribeiro@gmail.com>
> >>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Cool, just open https://issues.apache.org/
> >>>>>>>>> jira/browse/ZOOKEEPER-2597
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> PS: I removed the REPO_HOME global variable.
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Wed, Sep 21, 2016 at 6:53 AM, Flavio Junqueira <
> >>>>>>>> fpj@apache.org>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> Better to have that in the form of a pull request or diff.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> REPO_HOME does seem to be unused.
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> -Flavio
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On 20 Sep 2016, at 18:57, Edward Ribeiro <
> >>>>>>>>> edward.ribeiro@gmail.com
> >>>>>>>>>>>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Hey, I have started porting the kafka-merge.py to work
> >>> on ZK
> >>>>>>>>> repos.
> >>>>>>>>>>>> I
> >>>>>>>>>>>>>>>> would
> >>>>>>>>>>>>>>>>> need someone to review it and help me test it now.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> The files were uploaded below, but I will create a github
> >>>>>>> repo
> >>>>>>>>> yet
> >>>>>>>>>>>>>>> today.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> https://www.dropbox.com/sh/od8bet2574jttm3/
> >>>>>>>>>>>>>>>> AADv1DXTb8vfyVCmelFbYCEha?dl=0
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I uploaded the kafka version script so that you can use
> >>> diff
> >>>>>>> or
> >>>>>>>>>> Meld
> >>>>>>>>>>>>> to
> >>>>>>>>>>>>>>>>> spot my changes, but feel free to grasp the original file
> >>>>>>> here:
> >>>>>>>>>>>>>>>>> https://github.com/apache/kafka/blob/trunk/kafka-merge-
> >>>> pr.py
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> PS: It's just me or REPO_HOME env variable is not used
> >>>>>>> anywhere
> >>>>>>>>> in
> >>>>>>>>>>>> the
> >>>>>>>>>>>>>>>>> merge script???
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> Cheers,
> >>>>>>>>>>>>>>>>> Eddie
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick Hunt <
> >>>>>>>> phunt@apache.org
> >>>>>>>>>>
> >>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin Reed <
> >>>>>>>>> breed@apache.org>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> what you are suggesting sounds good, but i don't know
> >>> how
> >>>>>>> to
> >>>>>>>> do
> >>>>>>>>>>>> it?
> >>>>>>>>>>>>>>>> since
> >>>>>>>>>>>>>>>>>>> in the end we are still just accepting diffs on
> >>> patches,
> >>>>>>> the
> >>>>>>>>> only
> >>>>>>>>>>>>>>> thing
> >>>>>>>>>>>>>>>>>>> that changes is that we use svn rather than git right?
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Notice the workflow Kafka uses - which includes "git
> >>> apply"
> >>>>>>>> and
> >>>>>>>>>>>>>>>> specifying
> >>>>>>>>>>>>>>>>>> the author tag when committers commit (so that the OP
> >>> gets
> >>>>>>>>> proper
> >>>>>>>>>>>>>>>>>> attribution in the commit itself)
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/
> >>>>>>>>>>>>>>>> Manual+Commit+Workflow
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> Patrick
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> i LOVE chris's idea! lets do it!
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> ben
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>> On Sun, Sep 18, 2016 at 3:22 PM, Patrick Hunt <
> >>>>>>>>> phunt@apache.org>
> >>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Ben, do you also want to update the "Applying a patch"
> >>>>>>>> section
> >>>>>>>>>> to
> >>>>>>>>>>>>>>> make
> >>>>>>>>>>>>>>>>>> it
> >>>>>>>>>>>>>>>>>>>> git specific?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> We (committers) should move to a model where authors
> >>> get
> >>>>>>>>> proper
> >>>>>>>>>>>>>>> credit
> >>>>>>>>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>>>> git. Our old workflow in svn resulted in only the
> >>>>>>> committer
> >>>>>>>>>> being
> >>>>>>>>>>>>>>>>>> listed
> >>>>>>>>>>>>>>>>>>>> (except that we listed the patch author in the commit
> >>>>>>>>> message).
> >>>>>>>>>>>> We
> >>>>>>>>>>>>>>>>>> should
> >>>>>>>>>>>>>>>>>>>> move to a model where the author of the patch gets
> >>> proper
> >>>>>>>>> credit
> >>>>>>>>>>>> in
> >>>>>>>>>>>>>>>>>> git.
> >>>>>>>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>>>>>>> believe we will get that if we use git for patch
> >>>>>>>>>>>>>>> creation/application?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Chris brought up getting rid of CHANGES.txt recently
> >>> on
> >>>>>>> the
> >>>>>>>>> dev
> >>>>>>>>>>>>> list
> >>>>>>>>>>>>>>>>>> in a
> >>>>>>>>>>>>>>>>>>>> separate thread - Chris do you want to implement that
> >>>>>>> change
> >>>>>>>>> now
> >>>>>>>>>>>>>>> that
> >>>>>>>>>>>>>>>>>>> we've
> >>>>>>>>>>>>>>>>>>>> moved to git?
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> Patrick
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin Reed <
> >>>>>>>>>> breed@apache.org
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> 1) actually in the previous step that was just
> >>> adding
> >>>>>>> new
> >>>>>>>>>>>> files.
> >>>>>>>>>>>>>>> you
> >>>>>>>>>>>>>>>>>>>>>> still
> >>>>>>>>>>>>>>>>>>>>>>> need the commit -a for the rest of the changes.
> >>> that's
> >>>>>>> my
> >>>>>>>>>>>> normal
> >>>>>>>>>>>>>>>>>>>>>> workflow.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> I think that will be confusing for most folks. They
> >>>>>>>>> typically
> >>>>>>>>>>>>>>> stage
> >>>>>>>>>>>>>>>>>>>>>> all the changes and then commit or don't stage and
> >>> use
> >>>>>>> -a.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> do you mind fixing it with your workflow. commit -a
> >>>>>>> doesn't
> >>>>>>>>> get
> >>>>>>>>>>>>> new
> >>>>>>>>>>>>>>>>>>>>> files, which is why you need to do the add, but i'm
> >>> not
> >>>>>>> the
> >>>>>>>>>> most
> >>>>>>>>>>>>>>>>>>>>> sophisticated git user, so
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>> 2) i figured since we are using git now that we
> >>> should
> >>>>>>>> use
> >>>>>>>>>>>> git's
> >>>>>>>>>>>>>>>>>>>>>> default.
> >>>>>>>>>>>>>>>>>>>>>>> the patch should work (by default it seems to strip
> >>>> the
> >>>>>>>>> first
> >>>>>>>>>>>>>>> path
> >>>>>>>>>>>>>>>>>>>>>> element).
> >>>>>>>>>>>>>>>>>>>>>>> does it not work for you?
> >>>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>> It will fail precommit in it's current state.
> >>>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>> fixed
> >>>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> --
> >>>>>>>>>>>>>> Cheers
> >>>>>>>>>>>>>> Michael.
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> --
> >>>>>>>>>>>> Cheers
> >>>>>>>>>>>> Michael.
> >>>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Cheers
> >>>>>>>>> Michael.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Cheers
> >>>> Michael.
> >>>>
> >>>
> >>
> >>
> >>
> >> --
> >> Cheers
> >> Michael.
> >>
> >
> >
> >
> > --
> > Cheers
> > Michael.
>
>

Re: [VOTE] move Apache Zookeeper to git

Posted by Flavio Junqueira <fp...@apache.org>.

What about QA, are we still missing a github pre-commit queue?

-Flavio

> On 26 Oct 2016, at 18:53, Michael Han <ha...@cloudera.com> wrote:
> 
> The comment bridging should be fixed now - see INFRA-12752 for more
> details.
> 
> On Wed, Oct 26, 2016 at 10:03 AM, Michael Han <ha...@cloudera.com> wrote:
> 
>>>> The git PR *review* comments for ZOOKEEPER-2597 didn't show up on JIRA.
>> 
>> The bridge was working the day Infra made the change - see the previous
>> comments made by git bot on ZOOKEEPER-761. Now it seems stop working. I am
>> reopening INFRA-12752 and building a case.
>> 
>> On Wed, Oct 26, 2016 at 9:45 AM, Edward Ribeiro <ed...@gmail.com>
>> wrote:
>> 
>>> Dear community,
>>> 
>>> The zk-merger-pr.py script has been merged into master (thanks a LOT Ben
>>> Reed for reviewing/discussing/testing and commiting):
>>> https://issues.apache.org/jira/browse/ZOOKEEPER-2597
>>> 
>>> As stated in the issue and on GH, this tool is a modified version of
>>> similar tools from Kafka, that is a copy of a Spark's one. It has some
>>> rough edges so we will certainly benefit from further enhancements and
>>> fixes. I changed the smallest possible pieces of code, just to make it
>>> work
>>> on a ZK repo so the credits go to the original authors.
>>> 
>>> Some notes:
>>> 
>>> 1. The git PR *review* comments for ZOOKEEPER-2597 didn't show up on JIRA.
>>> Only the opening and closing of the issue. Can we double check this as
>>> INFRA-12752 is closed, Michael Han?
>>> 
>>> 2. I scribbled a draft on how use the tool at
>>> https://docs.google.com/document/d/1i00ZXjrW2fu17vr_h7F1bUrq
>>> Xg3urw4Hm7KirQDpPIU/edit
>>> (still very crude, but feel free to improve it). I would like to move
>>> this
>>> text to https://cwiki.apache.org/confluence/display/ZOOKEEPER/Index but
>>> looks like I don't have permission to create a page there yet. Any help?
>>> 
>>> Best regards,
>>> Eddie
>>> 
>>> On Sat, Oct 22, 2016 at 7:08 PM, Michael Han <ha...@cloudera.com> wrote:
>>> 
>>>> FYI infra did some work in INFRA-12752 and the git PR comments can be
>>>> pushed to Apache JIRA.
>>>> 
>>>> On Sat, Oct 8, 2016 at 8:01 AM, Flavio Junqueira <fp...@apache.org>
>>> wrote:
>>>> 
>>>>> This is not supported at the moment if nothing has changed:
>>>>> 
>>>>> https://issues.apache.org/jira/browse/INFRA-11000 <
>>>>> https://issues.apache.org/jira/browse/INFRA-11000>
>>>>> 
>>>>> -Flavio
>>>>> 
>>>>>> On 08 Oct 2016, at 00:54, Benjamin Reed <br...@apache.org> wrote:
>>>>>> 
>>>>>> it doesn't look like we need to setup keys. this seems to work for
>>> me:
>>>>>> 
>>>>>> https://git-wip-us.apache.org/#committers-getting-started
>>>>>> 
>>>>>> it does seem strange that we aren't using public keys and that i'm
>>>>> sticking
>>>>>> a password in .netrc :P i'm wondering if other projects were able to
>>>> get
>>>>>> this going over ssh.
>>>>>> 
>>>>>> i'll take a whack at cleaning up the svn and subversion references.
>>>>>> 
>>>>>> ben
>>>>>> 
>>>>>> On Fri, Oct 7, 2016 at 12:59 PM, Camille Fournier <
>>> camille@apache.org>
>>>>>> wrote:
>>>>>> 
>>>>>>> Hey folks,
>>>>>>> 
>>>>>>> So I'm trying to get in a patch but this has not been updated to
>>> tell
>>>>>>> committers how to actually get the git keys set up:
>>>>>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
>>>>> Committing+changes
>>>>>>> 
>>>>>>> Can someone float me a link that says how to do this?
>>>>>>> 
>>>>>>> Also a bunch of our documentation still discusses SVN and not git,
>>>> which
>>>>>>> means we are not done with this migration. If you were pushing for
>>>> this
>>>>>>> change can you please do some due diligence on the wikis and
>>> correct
>>>> the
>>>>>>> stuff that refers to SVN?
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> C
>>>>>>> 
>>>>>>> On Wed, Oct 5, 2016 at 1:02 PM, Edward Ribeiro <
>>>>> edward.ribeiro@gmail.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>>> Excuse me guys!
>>>>>>>> 
>>>>>>>> I've written on Macbook Pro. No idea why GMail messed it up. I was
>>>> only
>>>>>>>> able to see the strange characters when I pasted on a gist text
>>> area.
>>>>> The
>>>>>>>> previous message is below, but if anyone is still having trouble
>>> (I
>>>>> tried
>>>>>>>> to remove the weird character), I left a copy at:
>>>>>>>> https://gist.github.com/eribeiro/da2a6a6c9a508610d52d0755fae8352d
>>>>>>>> 
>>>>>>>> "Hi,
>>>>>>>> 
>>>>>>>> The patch attached on ZOOKEEPER-2597 is a straightforward
>>> adaptation
>>>> of
>>>>>>>> Kafka's one. It takes care of merging Github PR into Apache git
>>> repo
>>>>> and
>>>>>>> a
>>>>>>>> subsequent closing of the PR on the GH side, among other things
>>>>>>> (rewriting
>>>>>>>> of commit messages, etc). The current status is: the script needs
>>> to
>>>> be
>>>>>>>> reviewed/validated by a committer. It has been some time since I
>>>>> uploaded
>>>>>>>> the patch, so I gonna do another pass through it in the meantime.
>>>>>>>> 
>>>>>>>> There are some workflow issues beyond the scope of ZOOKEEPER-2597
>>>> that
>>>>>>> need
>>>>>>>> to be sorted out (IMO):
>>>>>>>> 
>>>>>>>> 1. The normal workflow is to open a JIRA ticket before doing any
>>> GH
>>>> PR,
>>>>>>>> that is, no JIRA-less PRs. The PR should have a title of the form
>>>>>>>> "ZOOKEEPER-xxxx: Title". This will trigger the Apache JIRA-Github
>>>>>>>> integration and it's opening show up in the JIRA ticket.
>>>>>>>> 
>>>>>>>> 2. OTOH, not every Kafka PR needs a corresponding JIRA ticket.
>>> There
>>>>> are
>>>>>>> a
>>>>>>>> class of PRs with "MINOR" title that represent trivial code
>>> changes
>>>> and
>>>>>>>> "HOT-FIX" title that fix urgent, but simple bugs. Both bypass the
>>>> JIRA
>>>>>>>> creation step, even tough they are still subject to review. It's
>>>> worth
>>>>>>>> adopting a similar approach for ZK project?
>>>>>>>> 
>>>>>>>> 3. IIRC (didn't find any page to confirm), Cassandra project
>>>>> encourages,
>>>>>>>> but not demands, that contributors also upload a patch file to
>>> JIRA
>>>>> even
>>>>>>> in
>>>>>>>> the case of a GH PR (as to leave a audit trail, I guess). Or, at
>>>>> least,
>>>>>>> C*
>>>>>>>> project leaves up to the contributors to either open a GH PR or
>>>> upload
>>>>>>> the
>>>>>>>> patch file to JIRA.
>>>>>>>> 
>>>>>>>> 
>>>>>>>> +1 about having a 'paper trail' of review comments on JIRA and/or
>>>>> mailing
>>>>>>>> list (I would prefer the mailing list tbh). But as Michael and
>>> Flavio
>>>>>>>> pointed out, I never seen GH PR review **comments** being written
>>>> back
>>>>> to
>>>>>>>> JIRA, at least not in Kafka, Cassandra or Solr projects, that I
>>> have
>>>>>>>> followed more closely.
>>>>>>>> 
>>>>>>>> Eddie"
>>>>>>>> 
>>>>>>>> 
>>>>>>>> On Wed, Oct 5, 2016 at 1:35 PM, Michael Han <ha...@cloudera.com>
>>>> wrote:
>>>>>>>> 
>>>>>>>>> Eddie's mail contains lots of '=E2=80=8B'' which is unicode
>>>> character
>>>>>>>>> zero-width space, which might cause parsing trouble for some mail
>>>>>>>> clients.
>>>>>>>>> 
>>>>>>>>> On Wed, Oct 5, 2016 at 6:42 AM, Flavio Junqueira <fpj@apache.org
>>>> 
>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> Dude, I'm just not able to parse your e-mail, did you write that
>>>> on a
>>>>>>>>>> phone or something?
>>>>>>>>>> 
>>>>>>>>>> -Flavio
>>>>>>>>>> 
>>>>>>>>>>> On 05 Oct 2016, at 03:54, Edward Ribeiro <
>>>> edward.ribeiro@gmail.com
>>>>>>>> 
>>>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>> Hi,
>>>>>>>>>>> 
>>>>>>>>>>> The patch attached on ZOOKEEPER-2597 is a
>>>>>>>>>>> straightforward adaptation of
>>>>>>>>>>> Kafka's one. It takes care of merging Github PR into Apache git
>>>>>>> repo
>>>>>>>>> and
>>>>>>>>>>>  a
>>>>>>>>>>> subsequent closing of the PR on the GH side
>>>>>>>>>>>  among other things (rewriting of commit messages, etc)
>>>>>>>>>>> . The current status is: the script needs to be
>>> reviewed/validated
>>>>>>>> by a
>>>>>>>>>>> committer.
>>>>>>>>>>> It has been some time since I uploaded the patch, so I gonna
>>> do
>>>>>>>>> another
>>>>>>>>>>> pass through it in the meantime.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> T
>>>>>>>>>>> here are some workflow issues beyond the scope of
>>> ZOOKEEPER-2597
>>>>>>>>>>>  that need to be sorted out (IMO)
>>>>>>>>>>> :
>>>>>>>>>>> 
>>>>>>>>>>> 1. The normal workflow is to open a JIRA ticket before doing
>>> any
>>>> GH
>>>>>>>> PR
>>>>>>>>>>> , that is, no JIRA-less PRs.
>>>>>>>>>>> The PR should have a title of the form "ZOOKEEPER-xxxx: Title".
>>>>>>> This
>>>>>>>>> will
>>>>>>>>>>> trigger the Apache JIRA-Github integration and it's opening
>>> show
>>>> up
>>>>>>>> in
>>>>>>>>>> the
>>>>>>>>>>> JIRA ticket.
>>>>>>>>>>> 
>>>>>>>>>>> 2.
>>>>>>>>>>> OTOH, n
>>>>>>>>>>> ot every Kafka PR needs a corresponding JIRA ticket
>>>>>>>>>>> . 
>>>>>>>>>>> There are a class of PR
>>>>>>>>>>> s
>>>>>>>>>>> with "MINOR"
>>>>>>>>>>>  title
>>>>>>>>>>> that represent trivial code changes
>>>>>>>>>>>  and "HOT-FIX" title that fix urgent, but simple bugs. Both
>>>>>>>>>>> bypass the JIRA creation step
>>>>>>>>>>> , even tough they are still 
>>>>>>>>>>> subject to review
>>>>>>>>>>> .
>>>>>>>>>>> It's worth adopting a similar approach for ZK project?
>>>>>>>>>>> 
>>>>>>>>>>> 3. IIRC
>>>>>>>>>>>  (didn't find any page to confirm)
>>>>>>>>>>> , Cassandra project encourages, but not demands, that
>>> contributors
>>>>>>>> also
>>>>>>>>>>> upload a patch file to JIRA even in the case of a GH PR
>>>>>>>>>>>  (as to leave a audit trail, I guess)
>>>>>>>>>>> .
>>>>>>>>>>> Or
>>>>>>>>>>> ,
>>>>>>>>>>> at
>>>>>>>>>>>  
>>>>>>>>>>> least
>>>>>>>>>>> ,
>>>>>>>>>>> C* project 
>>>>>>>>>>> leave
>>>>>>>>>>> s
>>>>>>>>>>> up to the contributor
>>>>>>>>>>> s
>>>>>>>>>>> to either open a GH PR or upload the patch file
>>>>>>>>>>>  to JIRA. In fact, Github allows the access to a raw patch or
>>>>>>> diff,
>>>>>>>>> it's
>>>>>>>>>>> just a matter of adding the ".patch" or ".diff" suffix to the
>>> end
>>>>>>> of
>>>>>>>>> the
>>>>>>>>>>> Pull Request URL.
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> +1 about having a 'paper trail'
>>>>>>>>>>>  of review comments
>>>>>>>>>>> 
>>>>>>>>>>> o
>>>>>>>>>>> n JIRA and
>>>>>>>>>>> /or
>>>>>>>>>>> mailing list (I
>>>>>>>>>>>  would
>>>>>>>>>>> prefer the mailing list tbh). But as Michael and Flavio pointed
>>>>>>> out,
>>>>>>>> I
>>>>>>>>>>> never seen
>>>>>>>>>>> GH 
>>>>>>>>>>> PR review
>>>>>>>>>>> **
>>>>>>>>>>> comments
>>>>>>>>>>> **
>>>>>>>>>>> being written back to JIRA, at least not in Kafka, Cassandra
>>>>>>>>>>> or
>>>>>>>>>>> Solr projects
>>>>>>>>>>> , that I have followed more closely.
>>>>>>>>>>> 
>>>>>>>>>>> Eddie
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> On Tue, Oct 4, 2016 at 6:40 PM, Michael Han <hanm@cloudera.com
>>>> 
>>>>>>>> wrote:
>>>>>>>>>>> 
>>>>>>>>>>>>>> as long as the opening/closing/commenting all get sent to
>>> the
>>>>>>>>> mailing
>>>>>>>>>>>> list or recorded in jira
>>>>>>>>>>>> Yeah, this is my impression as well, that we need to keep
>>> certain
>>>>>>>>> paper
>>>>>>>>>>>> trail regarding activities and comments on ASF side (JIRA or
>>> mail
>>>>>>>>> list).
>>>>>>>>>>>> Infra page said:
>>>>>>>>>>>> 
>>>>>>>>>>>> - Any Pull Request that gets opened, closed, reopened or
>>>>>>>>> **commented**
>>>>>>>>>>>> on now gets recorded on the project's mailing list
>>>>>>>>>>>> - If a project has a JIRA instance, any PRs or *comments* on
>>> PRs
>>>>>>>>> that
>>>>>>>>>>>> include a JIRA ticket ID will trigger an update on that
>>> specific
>>>>>>>>>> ticket
>>>>>>>>>>>> 
>>>>>>>>>>>> I checked a couple Kafka and Spark JIRAs but I don't see any
>>> of
>>>>>>> the
>>>>>>>>>>>> comments made in github PR were posted on JIRA, except the
>>>>>>>> activities
>>>>>>>>>> (open
>>>>>>>>>>>> a PR, close a PR). Since both projects have been using github
>>> for
>>>>>>> a
>>>>>>>>>> while I
>>>>>>>>>>>> assume such practice of NOT integrating comments between
>>> github
>>>>>>> and
>>>>>>>>> ASF
>>>>>>>>>>>> JIRA is acceptable? Though I feel it would be really useful if
>>>>>>>>> comments
>>>>>>>>>>>> could converge in a single place as well, that will provide a
>>>>>>> clear
>>>>>>>>>> history
>>>>>>>>>>>> for a given technical issue.
>>>>>>>>>>>> 
>>>>>>>>>>>> On Tue, Oct 4, 2016 at 12:06 PM, Flavio Junqueira <
>>>> fpj@apache.org
>>>>>>>> 
>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> Until ZOOKEEPER-2597 <https://issues.apache.org/
>>>>>>>>>>>> jira/browse/ZOOKEEPER-2597>
>>>>>>>>>>>>> is fixed, we can't merge via github.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> For code reviews, we can use GH as long as the
>>>>>>>>>> opening/closing/commenting
>>>>>>>>>>>>> all get sent to the mailing list or recorded in jira. I don't
>>>>>>> think
>>>>>>>>> we
>>>>>>>>>>>> have
>>>>>>>>>>>>> that yet, but it is possible according to this:
>>>>>>>>>>>>> 
>>>>>>>>>>>>> https://blogs.apache.org/infra/entry/improved_
>>>>>>>>>>>>> integration_between_apache_and <https://blogs.apache.org/
>>>>>>>>>>>>> infra/entry/improved_integration_between_apache_and>
>>>>>>>>>>>>> 
>>>>>>>>>>>>> For now, we do need to upload patches and converge using
>>> jira.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> I think Eddie has been looking at this process trying to
>>>>>>> replicate
>>>>>>>>> the
>>>>>>>>>>>>> Kafka setup, so perhaps he can give an update if I'm right.
>>>> Kafka
>>>>>>>>>> doesn't
>>>>>>>>>>>>> send every comment to the mailing list, though, but I'm not
>>> sure
>>>>>>> if
>>>>>>>>>>>> that's
>>>>>>>>>>>>> acceptable according to the ASF, I need to double-check.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> -Flavio
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On 04 Oct 2016, at 19:42, Michael Han <ha...@cloudera.com>
>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Hi,
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> Now we've moved to git, what is the policy for uploading
>>>> patches
>>>>>>>> and
>>>>>>>>>>>>> doing
>>>>>>>>>>>>>> code reviews? I am asking because I've seen recently there
>>> are
>>>>>>> git
>>>>>>>>>> pull
>>>>>>>>>>>>>> requests coming in without associated patch file uploaded to
>>>>>>> JIRA.
>>>>>>>>>> I've
>>>>>>>>>>>>>> checked
>>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
>>>>>>>>> HowToContribute
>>>>>>>>>> ,
>>>>>>>>>>>>>> looks like there is not much change regarding patch process
>>> -
>>>> so
>>>>>>>>>>>>> presumably
>>>>>>>>>>>>>> we still need to generate and upload patch file to JIRA for
>>> the
>>>>>>>>>> record,
>>>>>>>>>>>>>> while using github (maybe in addition of review board, or in
>>>> the
>>>>>>>>>> future
>>>>>>>>>>>>>> with gerrit) to do code reviews?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Wed, Sep 21, 2016 at 6:05 AM, Edward Ribeiro <
>>>>>>>>>>>>> edward.ribeiro@gmail.com>
>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Cool, just open https://issues.apache.org/
>>>>>>>>> jira/browse/ZOOKEEPER-2597
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> PS: I removed the REPO_HOME global variable.
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Wed, Sep 21, 2016 at 6:53 AM, Flavio Junqueira <
>>>>>>>> fpj@apache.org>
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> Better to have that in the form of a pull request or diff.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> REPO_HOME does seem to be unused.
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> -Flavio
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On 20 Sep 2016, at 18:57, Edward Ribeiro <
>>>>>>>>> edward.ribeiro@gmail.com
>>>>>>>>>>> 
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Hey, I have started porting the kafka-merge.py to work
>>> on ZK
>>>>>>>>> repos.
>>>>>>>>>>>> I
>>>>>>>>>>>>>>>> would
>>>>>>>>>>>>>>>>> need someone to review it and help me test it now.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> The files were uploaded below, but I will create a github
>>>>>>> repo
>>>>>>>>> yet
>>>>>>>>>>>>>>> today.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> https://www.dropbox.com/sh/od8bet2574jttm3/
>>>>>>>>>>>>>>>> AADv1DXTb8vfyVCmelFbYCEha?dl=0
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> I uploaded the kafka version script so that you can use
>>> diff
>>>>>>> or
>>>>>>>>>> Meld
>>>>>>>>>>>>> to
>>>>>>>>>>>>>>>>> spot my changes, but feel free to grasp the original file
>>>>>>> here:
>>>>>>>>>>>>>>>>> https://github.com/apache/kafka/blob/trunk/kafka-merge-
>>>> pr.py
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> PS: It's just me or REPO_HOME env variable is not used
>>>>>>> anywhere
>>>>>>>>> in
>>>>>>>>>>>> the
>>>>>>>>>>>>>>>>> merge script???
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> Cheers,
>>>>>>>>>>>>>>>>> Eddie
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick Hunt <
>>>>>>>> phunt@apache.org
>>>>>>>>>> 
>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin Reed <
>>>>>>>>> breed@apache.org>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> what you are suggesting sounds good, but i don't know
>>> how
>>>>>>> to
>>>>>>>> do
>>>>>>>>>>>> it?
>>>>>>>>>>>>>>>> since
>>>>>>>>>>>>>>>>>>> in the end we are still just accepting diffs on
>>> patches,
>>>>>>> the
>>>>>>>>> only
>>>>>>>>>>>>>>> thing
>>>>>>>>>>>>>>>>>>> that changes is that we use svn rather than git right?
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Notice the workflow Kafka uses - which includes "git
>>> apply"
>>>>>>>> and
>>>>>>>>>>>>>>>> specifying
>>>>>>>>>>>>>>>>>> the author tag when committers commit (so that the OP
>>> gets
>>>>>>>>> proper
>>>>>>>>>>>>>>>>>> attribution in the commit itself)
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/
>>>>>>>>>>>>>>>> Manual+Commit+Workflow
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> Patrick
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> i LOVE chris's idea! lets do it!
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> ben
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> On Sun, Sep 18, 2016 at 3:22 PM, Patrick Hunt <
>>>>>>>>> phunt@apache.org>
>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Ben, do you also want to update the "Applying a patch"
>>>>>>>> section
>>>>>>>>>> to
>>>>>>>>>>>>>>> make
>>>>>>>>>>>>>>>>>> it
>>>>>>>>>>>>>>>>>>>> git specific?
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> We (committers) should move to a model where authors
>>> get
>>>>>>>>> proper
>>>>>>>>>>>>>>> credit
>>>>>>>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>>>> git. Our old workflow in svn resulted in only the
>>>>>>> committer
>>>>>>>>>> being
>>>>>>>>>>>>>>>>>> listed
>>>>>>>>>>>>>>>>>>>> (except that we listed the patch author in the commit
>>>>>>>>> message).
>>>>>>>>>>>> We
>>>>>>>>>>>>>>>>>> should
>>>>>>>>>>>>>>>>>>>> move to a model where the author of the patch gets
>>> proper
>>>>>>>>> credit
>>>>>>>>>>>> in
>>>>>>>>>>>>>>>>>> git.
>>>>>>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>>>>>>> believe we will get that if we use git for patch
>>>>>>>>>>>>>>> creation/application?
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Chris brought up getting rid of CHANGES.txt recently
>>> on
>>>>>>> the
>>>>>>>>> dev
>>>>>>>>>>>>> list
>>>>>>>>>>>>>>>>>> in a
>>>>>>>>>>>>>>>>>>>> separate thread - Chris do you want to implement that
>>>>>>> change
>>>>>>>>> now
>>>>>>>>>>>>>>> that
>>>>>>>>>>>>>>>>>>> we've
>>>>>>>>>>>>>>>>>>>> moved to git?
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> Patrick
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin Reed <
>>>>>>>>>> breed@apache.org
>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 1) actually in the previous step that was just
>>> adding
>>>>>>> new
>>>>>>>>>>>> files.
>>>>>>>>>>>>>>> you
>>>>>>>>>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>>>>>>>>>> need the commit -a for the rest of the changes.
>>> that's
>>>>>>> my
>>>>>>>>>>>> normal
>>>>>>>>>>>>>>>>>>>>>> workflow.
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> I think that will be confusing for most folks. They
>>>>>>>>> typically
>>>>>>>>>>>>>>> stage
>>>>>>>>>>>>>>>>>>>>>> all the changes and then commit or don't stage and
>>> use
>>>>>>> -a.
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> do you mind fixing it with your workflow. commit -a
>>>>>>> doesn't
>>>>>>>>> get
>>>>>>>>>>>>> new
>>>>>>>>>>>>>>>>>>>>> files, which is why you need to do the add, but i'm
>>> not
>>>>>>> the
>>>>>>>>>> most
>>>>>>>>>>>>>>>>>>>>> sophisticated git user, so
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>>> 2) i figured since we are using git now that we
>>> should
>>>>>>>> use
>>>>>>>>>>>> git's
>>>>>>>>>>>>>>>>>>>>>> default.
>>>>>>>>>>>>>>>>>>>>>>> the patch should work (by default it seems to strip
>>>> the
>>>>>>>>> first
>>>>>>>>>>>>>>> path
>>>>>>>>>>>>>>>>>>>>>> element).
>>>>>>>>>>>>>>>>>>>>>>> does it not work for you?
>>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>>> It will fail precommit in it's current state.
>>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>>> fixed
>>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> --
>>>>>>>>>>>>>> Cheers
>>>>>>>>>>>>>> Michael.
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> --
>>>>>>>>>>>> Cheers
>>>>>>>>>>>> Michael.
>>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Cheers
>>>>>>>>> Michael.
>>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Cheers
>>>> Michael.
>>>> 
>>> 
>> 
>> 
>> 
>> --
>> Cheers
>> Michael.
>> 
> 
> 
> 
> -- 
> Cheers
> Michael.

Re: [VOTE] move Apache Zookeeper to git

Posted by Michael Han <ha...@cloudera.com>.

The comment bridging should be fixed now - see INFRA-12752 for more
details.

On Wed, Oct 26, 2016 at 10:03 AM, Michael Han <ha...@cloudera.com> wrote:

> >> The git PR *review* comments for ZOOKEEPER-2597 didn't show up on JIRA.
>
> The bridge was working the day Infra made the change - see the previous
> comments made by git bot on ZOOKEEPER-761. Now it seems stop working. I am
> reopening INFRA-12752 and building a case.
>
> On Wed, Oct 26, 2016 at 9:45 AM, Edward Ribeiro <ed...@gmail.com>
> wrote:
>
>> Dear community,
>>
>> The zk-merger-pr.py script has been merged into master (thanks a LOT Ben
>> Reed for reviewing/discussing/testing and commiting):
>> https://issues.apache.org/jira/browse/ZOOKEEPER-2597
>>
>> As stated in the issue and on GH, this tool is a modified version of
>> similar tools from Kafka, that is a copy of a Spark's one. It has some
>> rough edges so we will certainly benefit from further enhancements and
>> fixes. I changed the smallest possible pieces of code, just to make it
>> work
>> on a ZK repo so the credits go to the original authors.
>>
>> Some notes:
>>
>> 1. The git PR *review* comments for ZOOKEEPER-2597 didn't show up on JIRA.
>> Only the opening and closing of the issue. Can we double check this as
>> INFRA-12752 is closed, Michael Han?
>>
>> 2. I scribbled a draft on how use the tool at
>> https://docs.google.com/document/d/1i00ZXjrW2fu17vr_h7F1bUrq
>> Xg3urw4Hm7KirQDpPIU/edit
>>  (still very crude, but feel free to improve it). I would like to move
>> this
>> text to https://cwiki.apache.org/confluence/display/ZOOKEEPER/Index but
>> looks like I don't have permission to create a page there yet. Any help?
>>
>> Best regards,
>> Eddie
>>
>> On Sat, Oct 22, 2016 at 7:08 PM, Michael Han <ha...@cloudera.com> wrote:
>>
>> > FYI infra did some work in INFRA-12752 and the git PR comments can be
>> > pushed to Apache JIRA.
>> >
>> > On Sat, Oct 8, 2016 at 8:01 AM, Flavio Junqueira <fp...@apache.org>
>> wrote:
>> >
>> > > This is not supported at the moment if nothing has changed:
>> > >
>> > > https://issues.apache.org/jira/browse/INFRA-11000 <
>> > > https://issues.apache.org/jira/browse/INFRA-11000>
>> > >
>> > > -Flavio
>> > >
>> > > > On 08 Oct 2016, at 00:54, Benjamin Reed <br...@apache.org> wrote:
>> > > >
>> > > > it doesn't look like we need to setup keys. this seems to work for
>> me:
>> > > >
>> > > > https://git-wip-us.apache.org/#committers-getting-started
>> > > >
>> > > > it does seem strange that we aren't using public keys and that i'm
>> > > sticking
>> > > > a password in .netrc :P i'm wondering if other projects were able to
>> > get
>> > > > this going over ssh.
>> > > >
>> > > > i'll take a whack at cleaning up the svn and subversion references.
>> > > >
>> > > > ben
>> > > >
>> > > > On Fri, Oct 7, 2016 at 12:59 PM, Camille Fournier <
>> camille@apache.org>
>> > > > wrote:
>> > > >
>> > > >> Hey folks,
>> > > >>
>> > > >> So I'm trying to get in a patch but this has not been updated to
>> tell
>> > > >> committers how to actually get the git keys set up:
>> > > >> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
>> > > Committing+changes
>> > > >>
>> > > >> Can someone float me a link that says how to do this?
>> > > >>
>> > > >> Also a bunch of our documentation still discusses SVN and not git,
>> > which
>> > > >> means we are not done with this migration. If you were pushing for
>> > this
>> > > >> change can you please do some due diligence on the wikis and
>> correct
>> > the
>> > > >> stuff that refers to SVN?
>> > > >>
>> > > >> Thanks,
>> > > >> C
>> > > >>
>> > > >> On Wed, Oct 5, 2016 at 1:02 PM, Edward Ribeiro <
>> > > edward.ribeiro@gmail.com>
>> > > >> wrote:
>> > > >>
>> > > >>> Excuse me guys!
>> > > >>>
>> > > >>> I've written on Macbook Pro. No idea why GMail messed it up. I was
>> > only
>> > > >>> able to see the strange characters when I pasted on a gist text
>> area.
>> > > The
>> > > >>> previous message is below, but if anyone is still having trouble
>> (I
>> > > tried
>> > > >>> to remove the weird character), I left a copy at:
>> > > >>> https://gist.github.com/eribeiro/da2a6a6c9a508610d52d0755fae8352d
>> > > >>>
>> > > >>> "Hi,
>> > > >>>
>> > > >>> The patch attached on ZOOKEEPER-2597 is a straightforward
>> adaptation
>> > of
>> > > >>> Kafka's one. It takes care of merging Github PR into Apache git
>> repo
>> > > and
>> > > >> a
>> > > >>> subsequent closing of the PR on the GH side, among other things
>> > > >> (rewriting
>> > > >>> of commit messages, etc). The current status is: the script needs
>> to
>> > be
>> > > >>> reviewed/validated by a committer. It has been some time since I
>> > > uploaded
>> > > >>> the patch, so I gonna do another pass through it in the meantime.
>> > > >>>
>> > > >>> There are some workflow issues beyond the scope of ZOOKEEPER-2597
>> > that
>> > > >> need
>> > > >>> to be sorted out (IMO):
>> > > >>>
>> > > >>> 1. The normal workflow is to open a JIRA ticket before doing any
>> GH
>> > PR,
>> > > >>> that is, no JIRA-less PRs. The PR should have a title of the form
>> > > >>> "ZOOKEEPER-xxxx: Title". This will trigger the Apache JIRA-Github
>> > > >>> integration and it's opening show up in the JIRA ticket.
>> > > >>>
>> > > >>> 2. OTOH, not every Kafka PR needs a corresponding JIRA ticket.
>> There
>> > > are
>> > > >> a
>> > > >>> class of PRs with "MINOR" title that represent trivial code
>> changes
>> > and
>> > > >>> "HOT-FIX" title that fix urgent, but simple bugs. Both bypass the
>> > JIRA
>> > > >>> creation step, even tough they are still subject to review. It's
>> > worth
>> > > >>> adopting a similar approach for ZK project?
>> > > >>>
>> > > >>> 3. IIRC (didn't find any page to confirm), Cassandra project
>> > > encourages,
>> > > >>> but not demands, that contributors also upload a patch file to
>> JIRA
>> > > even
>> > > >> in
>> > > >>> the case of a GH PR (as to leave a audit trail, I guess). Or, at
>> > > least,
>> > > >> C*
>> > > >>> project leaves up to the contributors to either open a GH PR or
>> > upload
>> > > >> the
>> > > >>> patch file to JIRA.
>> > > >>>
>> > > >>>
>> > > >>> +1 about having a 'paper trail' of review comments on JIRA and/or
>> > > mailing
>> > > >>> list (I would prefer the mailing list tbh). But as Michael and
>> Flavio
>> > > >>> pointed out, I never seen GH PR review **comments** being written
>> > back
>> > > to
>> > > >>> JIRA, at least not in Kafka, Cassandra or Solr projects, that I
>> have
>> > > >>> followed more closely.
>> > > >>>
>> > > >>> Eddie"
>> > > >>>
>> > > >>>
>> > > >>> On Wed, Oct 5, 2016 at 1:35 PM, Michael Han <ha...@cloudera.com>
>> > wrote:
>> > > >>>
>> > > >>>> Eddie's mail contains lots of '=E2=80=8B'' which is unicode
>> > character
>> > > >>>> zero-width space, which might cause parsing trouble for some mail
>> > > >>> clients.
>> > > >>>>
>> > > >>>> On Wed, Oct 5, 2016 at 6:42 AM, Flavio Junqueira <fpj@apache.org
>> >
>> > > >> wrote:
>> > > >>>>
>> > > >>>>> Dude, I'm just not able to parse your e-mail, did you write that
>> > on a
>> > > >>>>> phone or something?
>> > > >>>>>
>> > > >>>>> -Flavio
>> > > >>>>>
>> > > >>>>>> On 05 Oct 2016, at 03:54, Edward Ribeiro <
>> > edward.ribeiro@gmail.com
>> > > >>>
>> > > >>>>> wrote:
>> > > >>>>>>
>> > > >>>>>> Hi,
>> > > >>>>>>
>> > > >>>>>> The patch attached on ZOOKEEPER-2597 is a
>> > > >>>>>> straightforward adaptation of
>> > > >>>>>> Kafka's one. It takes care of merging Github PR into Apache git
>> > > >> repo
>> > > >>>> and
>> > > >>>>>>  a
>> > > >>>>>> subsequent closing of the PR on the GH side
>> > > >>>>>>  among other things (rewriting of commit messages, etc)
>> > > >>>>>> . The current status is: the script needs to be
>> reviewed/validated
>> > > >>> by a
>> > > >>>>>> committer.
>> > > >>>>>> It has been some time since I uploaded the patch, so I gonna
>> do
>> > > >>>> another
>> > > >>>>>> pass through it in the meantime.
>> > > >>>>>>
>> > > >>>>>>
>> > > >>>>>> T
>> > > >>>>>> here are some workflow issues beyond the scope of
>> ZOOKEEPER-2597
>> > > >>>>>>  that need to be sorted out (IMO)
>> > > >>>>>> :
>> > > >>>>>>
>> > > >>>>>> 1. The normal workflow is to open a JIRA ticket before doing
>> any
>> > GH
>> > > >>> PR
>> > > >>>>>> , that is, no JIRA-less PRs.
>> > > >>>>>> The PR should have a title of the form "ZOOKEEPER-xxxx: Title".
>> > > >> This
>> > > >>>> will
>> > > >>>>>> trigger the Apache JIRA-Github integration and it's opening
>> show
>> > up
>> > > >>> in
>> > > >>>>> the
>> > > >>>>>> JIRA ticket.
>> > > >>>>>>
>> > > >>>>>> 2.
>> > > >>>>>> OTOH, n
>> > > >>>>>> ot every Kafka PR needs a corresponding JIRA ticket
>> > > >>>>>> . 
>> > > >>>>>> There are a class of PR
>> > > >>>>>> s
>> > > >>>>>> with "MINOR"
>> > > >>>>>>  title
>> > > >>>>>> that represent trivial code changes
>> > > >>>>>>  and "HOT-FIX" title that fix urgent, but simple bugs. Both
>> > > >>>>>> bypass the JIRA creation step
>> > > >>>>>> , even tough they are still 
>> > > >>>>>> subject to review
>> > > >>>>>> .
>> > > >>>>>> It's worth adopting a similar approach for ZK project?
>> > > >>>>>>
>> > > >>>>>> 3. IIRC
>> > > >>>>>>  (didn't find any page to confirm)
>> > > >>>>>> , Cassandra project encourages, but not demands, that
>> contributors
>> > > >>> also
>> > > >>>>>> upload a patch file to JIRA even in the case of a GH PR
>> > > >>>>>>  (as to leave a audit trail, I guess)
>> > > >>>>>> .
>> > > >>>>>> Or
>> > > >>>>>> ,
>> > > >>>>>> at
>> > > >>>>>>  
>> > > >>>>>> least
>> > > >>>>>> ,
>> > > >>>>>> C* project 
>> > > >>>>>> leave
>> > > >>>>>> s
>> > > >>>>>> up to the contributor
>> > > >>>>>> s
>> > > >>>>>> to either open a GH PR or upload the patch file
>> > > >>>>>>  to JIRA. In fact, Github allows the access to a raw patch or
>> > > >> diff,
>> > > >>>> it's
>> > > >>>>>> just a matter of adding the ".patch" or ".diff" suffix to the
>> end
>> > > >> of
>> > > >>>> the
>> > > >>>>>> Pull Request URL.
>> > > >>>>>> 
>> > > >>>>>>
>> > > >>>>>>
>> > > >>>>>> +1 about having a 'paper trail'
>> > > >>>>>>  of review comments
>> > > >>>>>>
>> > > >>>>>> o
>> > > >>>>>> n JIRA and
>> > > >>>>>> /or
>> > > >>>>>> mailing list (I
>> > > >>>>>>  would
>> > > >>>>>> prefer the mailing list tbh). But as Michael and Flavio pointed
>> > > >> out,
>> > > >>> I
>> > > >>>>>> never seen
>> > > >>>>>> GH 
>> > > >>>>>> PR review
>> > > >>>>>> **
>> > > >>>>>> comments
>> > > >>>>>> **
>> > > >>>>>> being written back to JIRA, at least not in Kafka, Cassandra
>> > > >>>>>> or
>> > > >>>>>> Solr projects
>> > > >>>>>> , that I have followed more closely.
>> > > >>>>>>
>> > > >>>>>> Eddie
>> > > >>>>>>
>> > > >>>>>>
>> > > >>>>>> On Tue, Oct 4, 2016 at 6:40 PM, Michael Han <hanm@cloudera.com
>> >
>> > > >>> wrote:
>> > > >>>>>>
>> > > >>>>>>>>> as long as the opening/closing/commenting all get sent to
>> the
>> > > >>>> mailing
>> > > >>>>>>> list or recorded in jira
>> > > >>>>>>> Yeah, this is my impression as well, that we need to keep
>> certain
>> > > >>>> paper
>> > > >>>>>>> trail regarding activities and comments on ASF side (JIRA or
>> mail
>> > > >>>> list).
>> > > >>>>>>> Infra page said:
>> > > >>>>>>>
>> > > >>>>>>>  - Any Pull Request that gets opened, closed, reopened or
>> > > >>>> **commented**
>> > > >>>>>>>  on now gets recorded on the project's mailing list
>> > > >>>>>>>  - If a project has a JIRA instance, any PRs or *comments* on
>> PRs
>> > > >>>> that
>> > > >>>>>>>  include a JIRA ticket ID will trigger an update on that
>> specific
>> > > >>>>> ticket
>> > > >>>>>>>
>> > > >>>>>>> I checked a couple Kafka and Spark JIRAs but I don't see any
>> of
>> > > >> the
>> > > >>>>>>> comments made in github PR were posted on JIRA, except the
>> > > >>> activities
>> > > >>>>> (open
>> > > >>>>>>> a PR, close a PR). Since both projects have been using github
>> for
>> > > >> a
>> > > >>>>> while I
>> > > >>>>>>> assume such practice of NOT integrating comments between
>> github
>> > > >> and
>> > > >>>> ASF
>> > > >>>>>>> JIRA is acceptable? Though I feel it would be really useful if
>> > > >>>> comments
>> > > >>>>>>> could converge in a single place as well, that will provide a
>> > > >> clear
>> > > >>>>> history
>> > > >>>>>>> for a given technical issue.
>> > > >>>>>>>
>> > > >>>>>>> On Tue, Oct 4, 2016 at 12:06 PM, Flavio Junqueira <
>> > fpj@apache.org
>> > > >>>
>> > > >>>>> wrote:
>> > > >>>>>>>
>> > > >>>>>>>> Until ZOOKEEPER-2597 <https://issues.apache.org/
>> > > >>>>>>> jira/browse/ZOOKEEPER-2597>
>> > > >>>>>>>> is fixed, we can't merge via github.
>> > > >>>>>>>>
>> > > >>>>>>>> For code reviews, we can use GH as long as the
>> > > >>>>> opening/closing/commenting
>> > > >>>>>>>> all get sent to the mailing list or recorded in jira. I don't
>> > > >> think
>> > > >>>> we
>> > > >>>>>>> have
>> > > >>>>>>>> that yet, but it is possible according to this:
>> > > >>>>>>>>
>> > > >>>>>>>> https://blogs.apache.org/infra/entry/improved_
>> > > >>>>>>>> integration_between_apache_and <https://blogs.apache.org/
>> > > >>>>>>>> infra/entry/improved_integration_between_apache_and>
>> > > >>>>>>>>
>> > > >>>>>>>> For now, we do need to upload patches and converge using
>> jira.
>> > > >>>>>>>>
>> > > >>>>>>>> I think Eddie has been looking at this process trying to
>> > > >> replicate
>> > > >>>> the
>> > > >>>>>>>> Kafka setup, so perhaps he can give an update if I'm right.
>> > Kafka
>> > > >>>>> doesn't
>> > > >>>>>>>> send every comment to the mailing list, though, but I'm not
>> sure
>> > > >> if
>> > > >>>>>>> that's
>> > > >>>>>>>> acceptable according to the ASF, I need to double-check.
>> > > >>>>>>>>
>> > > >>>>>>>> -Flavio
>> > > >>>>>>>>
>> > > >>>>>>>>> On 04 Oct 2016, at 19:42, Michael Han <ha...@cloudera.com>
>> > > >> wrote:
>> > > >>>>>>>>>
>> > > >>>>>>>>> Hi,
>> > > >>>>>>>>>
>> > > >>>>>>>>> Now we've moved to git, what is the policy for uploading
>> > patches
>> > > >>> and
>> > > >>>>>>>> doing
>> > > >>>>>>>>> code reviews? I am asking because I've seen recently there
>> are
>> > > >> git
>> > > >>>>> pull
>> > > >>>>>>>>> requests coming in without associated patch file uploaded to
>> > > >> JIRA.
>> > > >>>>> I've
>> > > >>>>>>>>> checked
>> > > >>>>>>>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
>> > > >>>> HowToContribute
>> > > >>>>> ,
>> > > >>>>>>>>> looks like there is not much change regarding patch process
>> -
>> > so
>> > > >>>>>>>> presumably
>> > > >>>>>>>>> we still need to generate and upload patch file to JIRA for
>> the
>> > > >>>>> record,
>> > > >>>>>>>>> while using github (maybe in addition of review board, or in
>> > the
>> > > >>>>> future
>> > > >>>>>>>>> with gerrit) to do code reviews?
>> > > >>>>>>>>>
>> > > >>>>>>>>>
>> > > >>>>>>>>> On Wed, Sep 21, 2016 at 6:05 AM, Edward Ribeiro <
>> > > >>>>>>>> edward.ribeiro@gmail.com>
>> > > >>>>>>>>> wrote:
>> > > >>>>>>>>>
>> > > >>>>>>>>>> Cool, just open https://issues.apache.org/
>> > > >>>> jira/browse/ZOOKEEPER-2597
>> > > >>>>>>>>>>
>> > > >>>>>>>>>> PS: I removed the REPO_HOME global variable.
>> > > >>>>>>>>>>
>> > > >>>>>>>>>> On Wed, Sep 21, 2016 at 6:53 AM, Flavio Junqueira <
>> > > >>> fpj@apache.org>
>> > > >>>>>>>> wrote:
>> > > >>>>>>>>>>
>> > > >>>>>>>>>>> Better to have that in the form of a pull request or diff.
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>> REPO_HOME does seem to be unused.
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>> -Flavio
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>>> On 20 Sep 2016, at 18:57, Edward Ribeiro <
>> > > >>>> edward.ribeiro@gmail.com
>> > > >>>>>>
>> > > >>>>>>>>>>> wrote:
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>> Hey, I have started porting the kafka-merge.py to work
>> on ZK
>> > > >>>> repos.
>> > > >>>>>>> I
>> > > >>>>>>>>>>> would
>> > > >>>>>>>>>>>> need someone to review it and help me test it now.
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>> The files were uploaded below, but I will create a github
>> > > >> repo
>> > > >>>> yet
>> > > >>>>>>>>>> today.
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>> https://www.dropbox.com/sh/od8bet2574jttm3/
>> > > >>>>>>>>>>> AADv1DXTb8vfyVCmelFbYCEha?dl=0
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>> I uploaded the kafka version script so that you can use
>> diff
>> > > >> or
>> > > >>>>> Meld
>> > > >>>>>>>> to
>> > > >>>>>>>>>>>> spot my changes, but feel free to grasp the original file
>> > > >> here:
>> > > >>>>>>>>>>>> https://github.com/apache/kafka/blob/trunk/kafka-merge-
>> > pr.py
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>> PS: It's just me or REPO_HOME env variable is not used
>> > > >> anywhere
>> > > >>>> in
>> > > >>>>>>> the
>> > > >>>>>>>>>>>> merge script???
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>> Cheers,
>> > > >>>>>>>>>>>> Eddie
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick Hunt <
>> > > >>> phunt@apache.org
>> > > >>>>>
>> > > >>>>>>>>>> wrote:
>> > > >>>>>>>>>>>>
>> > > >>>>>>>>>>>>> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin Reed <
>> > > >>>> breed@apache.org>
>> > > >>>>>>>>>>> wrote:
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>> what you are suggesting sounds good, but i don't know
>> how
>> > > >> to
>> > > >>> do
>> > > >>>>>>> it?
>> > > >>>>>>>>>>> since
>> > > >>>>>>>>>>>>>> in the end we are still just accepting diffs on
>> patches,
>> > > >> the
>> > > >>>> only
>> > > >>>>>>>>>> thing
>> > > >>>>>>>>>>>>>> that changes is that we use svn rather than git right?
>> > > >>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>> Notice the workflow Kafka uses - which includes "git
>> apply"
>> > > >>> and
>> > > >>>>>>>>>>> specifying
>> > > >>>>>>>>>>>>> the author tag when committers commit (so that the OP
>> gets
>> > > >>>> proper
>> > > >>>>>>>>>>>>> attribution in the commit itself)
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/
>> > > >>>>>>>>>>> Manual+Commit+Workflow
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>>> Patrick
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>> i LOVE chris's idea! lets do it!
>> > > >>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>> ben
>> > > >>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>> On Sun, Sep 18, 2016 at 3:22 PM, Patrick Hunt <
>> > > >>>> phunt@apache.org>
>> > > >>>>>>>>>>> wrote:
>> > > >>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>> Ben, do you also want to update the "Applying a patch"
>> > > >>> section
>> > > >>>>> to
>> > > >>>>>>>>>> make
>> > > >>>>>>>>>>>>> it
>> > > >>>>>>>>>>>>>>> git specific?
>> > > >>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>> We (committers) should move to a model where authors
>> get
>> > > >>>> proper
>> > > >>>>>>>>>> credit
>> > > >>>>>>>>>>>>> in
>> > > >>>>>>>>>>>>>>> git. Our old workflow in svn resulted in only the
>> > > >> committer
>> > > >>>>> being
>> > > >>>>>>>>>>>>> listed
>> > > >>>>>>>>>>>>>>> (except that we listed the patch author in the commit
>> > > >>>> message).
>> > > >>>>>>> We
>> > > >>>>>>>>>>>>> should
>> > > >>>>>>>>>>>>>>> move to a model where the author of the patch gets
>> proper
>> > > >>>> credit
>> > > >>>>>>> in
>> > > >>>>>>>>>>>>> git.
>> > > >>>>>>>>>>>>>> I
>> > > >>>>>>>>>>>>>>> believe we will get that if we use git for patch
>> > > >>>>>>>>>> creation/application?
>> > > >>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>> Chris brought up getting rid of CHANGES.txt recently
>> on
>> > > >> the
>> > > >>>> dev
>> > > >>>>>>>> list
>> > > >>>>>>>>>>>>> in a
>> > > >>>>>>>>>>>>>>> separate thread - Chris do you want to implement that
>> > > >> change
>> > > >>>> now
>> > > >>>>>>>>>> that
>> > > >>>>>>>>>>>>>> we've
>> > > >>>>>>>>>>>>>>> moved to git?
>> > > >>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>> Patrick
>> > > >>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin Reed <
>> > > >>>>> breed@apache.org
>> > > >>>>>>>>
>> > > >>>>>>>>>>>>> wrote:
>> > > >>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>> 1) actually in the previous step that was just
>> adding
>> > > >> new
>> > > >>>>>>> files.
>> > > >>>>>>>>>> you
>> > > >>>>>>>>>>>>>>>>> still
>> > > >>>>>>>>>>>>>>>>>> need the commit -a for the rest of the changes.
>> that's
>> > > >> my
>> > > >>>>>>> normal
>> > > >>>>>>>>>>>>>>>>> workflow.
>> > > >>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>> I think that will be confusing for most folks. They
>> > > >>>> typically
>> > > >>>>>>>>>> stage
>> > > >>>>>>>>>>>>>>>>> all the changes and then commit or don't stage and
>> use
>> > > >> -a.
>> > > >>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>> do you mind fixing it with your workflow. commit -a
>> > > >> doesn't
>> > > >>>> get
>> > > >>>>>>>> new
>> > > >>>>>>>>>>>>>>>> files, which is why you need to do the add, but i'm
>> not
>> > > >> the
>> > > >>>>> most
>> > > >>>>>>>>>>>>>>>> sophisticated git user, so
>> > > >>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>> 2) i figured since we are using git now that we
>> should
>> > > >>> use
>> > > >>>>>>> git's
>> > > >>>>>>>>>>>>>>>>> default.
>> > > >>>>>>>>>>>>>>>>>> the patch should work (by default it seems to strip
>> > the
>> > > >>>> first
>> > > >>>>>>>>>> path
>> > > >>>>>>>>>>>>>>>>> element).
>> > > >>>>>>>>>>>>>>>>>> does it not work for you?
>> > > >>>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>> It will fail precommit in it's current state.
>> > > >>>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>> fixed
>> > > >>>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>>
>> > > >>>>>>>>>>>>>
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>>
>> > > >>>>>>>>>>
>> > > >>>>>>>>>
>> > > >>>>>>>>>
>> > > >>>>>>>>>
>> > > >>>>>>>>> --
>> > > >>>>>>>>> Cheers
>> > > >>>>>>>>> Michael.
>> > > >>>>>>>>
>> > > >>>>>>>>
>> > > >>>>>>>
>> > > >>>>>>>
>> > > >>>>>>> --
>> > > >>>>>>> Cheers
>> > > >>>>>>> Michael.
>> > > >>>>>>>
>> > > >>>>>
>> > > >>>>>
>> > > >>>>
>> > > >>>>
>> > > >>>> --
>> > > >>>> Cheers
>> > > >>>> Michael.
>> > > >>>>
>> > > >>>
>> > > >>
>> > >
>> > >
>> >
>> >
>> > --
>> > Cheers
>> > Michael.
>> >
>>
>
>
>
> --
> Cheers
> Michael.
>



-- 
Cheers
Michael.

Re: [VOTE] move Apache Zookeeper to git

Posted by Michael Han <ha...@cloudera.com>.

>> The git PR *review* comments for ZOOKEEPER-2597 didn't show up on JIRA.

The bridge was working the day Infra made the change - see the previous
comments made by git bot on ZOOKEEPER-761. Now it seems stop working. I am
reopening INFRA-12752 and building a case.

On Wed, Oct 26, 2016 at 9:45 AM, Edward Ribeiro <ed...@gmail.com>
wrote:

> Dear community,
>
> The zk-merger-pr.py script has been merged into master (thanks a LOT Ben
> Reed for reviewing/discussing/testing and commiting):
> https://issues.apache.org/jira/browse/ZOOKEEPER-2597
>
> As stated in the issue and on GH, this tool is a modified version of
> similar tools from Kafka, that is a copy of a Spark's one. It has some
> rough edges so we will certainly benefit from further enhancements and
> fixes. I changed the smallest possible pieces of code, just to make it work
> on a ZK repo so the credits go to the original authors.
>
> Some notes:
>
> 1. The git PR *review* comments for ZOOKEEPER-2597 didn't show up on JIRA.
> Only the opening and closing of the issue. Can we double check this as
> INFRA-12752 is closed, Michael Han?
>
> 2. I scribbled a draft on how use the tool at
> https://docs.google.com/document/d/1i00ZXjrW2fu17vr_
> h7F1bUrqXg3urw4Hm7KirQDpPIU/edit
>  (still very crude, but feel free to improve it). I would like to move this
> text to https://cwiki.apache.org/confluence/display/ZOOKEEPER/Index but
> looks like I don't have permission to create a page there yet. Any help?
>
> Best regards,
> Eddie
>
> On Sat, Oct 22, 2016 at 7:08 PM, Michael Han <ha...@cloudera.com> wrote:
>
> > FYI infra did some work in INFRA-12752 and the git PR comments can be
> > pushed to Apache JIRA.
> >
> > On Sat, Oct 8, 2016 at 8:01 AM, Flavio Junqueira <fp...@apache.org> wrote:
> >
> > > This is not supported at the moment if nothing has changed:
> > >
> > > https://issues.apache.org/jira/browse/INFRA-11000 <
> > > https://issues.apache.org/jira/browse/INFRA-11000>
> > >
> > > -Flavio
> > >
> > > > On 08 Oct 2016, at 00:54, Benjamin Reed <br...@apache.org> wrote:
> > > >
> > > > it doesn't look like we need to setup keys. this seems to work for
> me:
> > > >
> > > > https://git-wip-us.apache.org/#committers-getting-started
> > > >
> > > > it does seem strange that we aren't using public keys and that i'm
> > > sticking
> > > > a password in .netrc :P i'm wondering if other projects were able to
> > get
> > > > this going over ssh.
> > > >
> > > > i'll take a whack at cleaning up the svn and subversion references.
> > > >
> > > > ben
> > > >
> > > > On Fri, Oct 7, 2016 at 12:59 PM, Camille Fournier <
> camille@apache.org>
> > > > wrote:
> > > >
> > > >> Hey folks,
> > > >>
> > > >> So I'm trying to get in a patch but this has not been updated to
> tell
> > > >> committers how to actually get the git keys set up:
> > > >> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> > > Committing+changes
> > > >>
> > > >> Can someone float me a link that says how to do this?
> > > >>
> > > >> Also a bunch of our documentation still discusses SVN and not git,
> > which
> > > >> means we are not done with this migration. If you were pushing for
> > this
> > > >> change can you please do some due diligence on the wikis and correct
> > the
> > > >> stuff that refers to SVN?
> > > >>
> > > >> Thanks,
> > > >> C
> > > >>
> > > >> On Wed, Oct 5, 2016 at 1:02 PM, Edward Ribeiro <
> > > edward.ribeiro@gmail.com>
> > > >> wrote:
> > > >>
> > > >>> Excuse me guys!
> > > >>>
> > > >>> I've written on Macbook Pro. No idea why GMail messed it up. I was
> > only
> > > >>> able to see the strange characters when I pasted on a gist text
> area.
> > > The
> > > >>> previous message is below, but if anyone is still having trouble (I
> > > tried
> > > >>> to remove the weird character), I left a copy at:
> > > >>> https://gist.github.com/eribeiro/da2a6a6c9a508610d52d0755fae8352d
> > > >>>
> > > >>> "Hi,
> > > >>>
> > > >>> The patch attached on ZOOKEEPER-2597 is a straightforward
> adaptation
> > of
> > > >>> Kafka's one. It takes care of merging Github PR into Apache git
> repo
> > > and
> > > >> a
> > > >>> subsequent closing of the PR on the GH side, among other things
> > > >> (rewriting
> > > >>> of commit messages, etc). The current status is: the script needs
> to
> > be
> > > >>> reviewed/validated by a committer. It has been some time since I
> > > uploaded
> > > >>> the patch, so I gonna do another pass through it in the meantime.
> > > >>>
> > > >>> There are some workflow issues beyond the scope of ZOOKEEPER-2597
> > that
> > > >> need
> > > >>> to be sorted out (IMO):
> > > >>>
> > > >>> 1. The normal workflow is to open a JIRA ticket before doing any GH
> > PR,
> > > >>> that is, no JIRA-less PRs. The PR should have a title of the form
> > > >>> "ZOOKEEPER-xxxx: Title". This will trigger the Apache JIRA-Github
> > > >>> integration and it's opening show up in the JIRA ticket.
> > > >>>
> > > >>> 2. OTOH, not every Kafka PR needs a corresponding JIRA ticket.
> There
> > > are
> > > >> a
> > > >>> class of PRs with "MINOR" title that represent trivial code changes
> > and
> > > >>> "HOT-FIX" title that fix urgent, but simple bugs. Both bypass the
> > JIRA
> > > >>> creation step, even tough they are still subject to review. It's
> > worth
> > > >>> adopting a similar approach for ZK project?
> > > >>>
> > > >>> 3. IIRC (didn't find any page to confirm), Cassandra project
> > > encourages,
> > > >>> but not demands, that contributors also upload a patch file to JIRA
> > > even
> > > >> in
> > > >>> the case of a GH PR (as to leave a audit trail, I guess). Or, at
> > > least,
> > > >> C*
> > > >>> project leaves up to the contributors to either open a GH PR or
> > upload
> > > >> the
> > > >>> patch file to JIRA.
> > > >>>
> > > >>>
> > > >>> +1 about having a 'paper trail' of review comments on JIRA and/or
> > > mailing
> > > >>> list (I would prefer the mailing list tbh). But as Michael and
> Flavio
> > > >>> pointed out, I never seen GH PR review **comments** being written
> > back
> > > to
> > > >>> JIRA, at least not in Kafka, Cassandra or Solr projects, that I
> have
> > > >>> followed more closely.
> > > >>>
> > > >>> Eddie"
> > > >>>
> > > >>>
> > > >>> On Wed, Oct 5, 2016 at 1:35 PM, Michael Han <ha...@cloudera.com>
> > wrote:
> > > >>>
> > > >>>> Eddie's mail contains lots of '=E2=80=8B'' which is unicode
> > character
> > > >>>> zero-width space, which might cause parsing trouble for some mail
> > > >>> clients.
> > > >>>>
> > > >>>> On Wed, Oct 5, 2016 at 6:42 AM, Flavio Junqueira <fp...@apache.org>
> > > >> wrote:
> > > >>>>
> > > >>>>> Dude, I'm just not able to parse your e-mail, did you write that
> > on a
> > > >>>>> phone or something?
> > > >>>>>
> > > >>>>> -Flavio
> > > >>>>>
> > > >>>>>> On 05 Oct 2016, at 03:54, Edward Ribeiro <
> > edward.ribeiro@gmail.com
> > > >>>
> > > >>>>> wrote:
> > > >>>>>>
> > > >>>>>> Hi,
> > > >>>>>>
> > > >>>>>> The patch attached on ZOOKEEPER-2597 is a
> > > >>>>>> straightforward adaptation of
> > > >>>>>> Kafka's one. It takes care of merging Github PR into Apache git
> > > >> repo
> > > >>>> and
> > > >>>>>>  a
> > > >>>>>> subsequent closing of the PR on the GH side
> > > >>>>>>  among other things (rewriting of commit messages, etc)
> > > >>>>>> . The current status is: the script needs to be
> reviewed/validated
> > > >>> by a
> > > >>>>>> committer.
> > > >>>>>> It has been some time since I uploaded the patch, so I gonna do
> > > >>>> another
> > > >>>>>> pass through it in the meantime.
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> T
> > > >>>>>> here are some workflow issues beyond the scope of ZOOKEEPER-2597
> > > >>>>>>  that need to be sorted out (IMO)
> > > >>>>>> :
> > > >>>>>>
> > > >>>>>> 1. The normal workflow is to open a JIRA ticket before doing any
> > GH
> > > >>> PR
> > > >>>>>> , that is, no JIRA-less PRs.
> > > >>>>>> The PR should have a title of the form "ZOOKEEPER-xxxx: Title".
> > > >> This
> > > >>>> will
> > > >>>>>> trigger the Apache JIRA-Github integration and it's opening show
> > up
> > > >>> in
> > > >>>>> the
> > > >>>>>> JIRA ticket.
> > > >>>>>>
> > > >>>>>> 2.
> > > >>>>>> OTOH, n
> > > >>>>>> ot every Kafka PR needs a corresponding JIRA ticket
> > > >>>>>> . 
> > > >>>>>> There are a class of PR
> > > >>>>>> s
> > > >>>>>> with "MINOR"
> > > >>>>>>  title
> > > >>>>>> that represent trivial code changes
> > > >>>>>>  and "HOT-FIX" title that fix urgent, but simple bugs. Both
> > > >>>>>> bypass the JIRA creation step
> > > >>>>>> , even tough they are still 
> > > >>>>>> subject to review
> > > >>>>>> .
> > > >>>>>> It's worth adopting a similar approach for ZK project?
> > > >>>>>>
> > > >>>>>> 3. IIRC
> > > >>>>>>  (didn't find any page to confirm)
> > > >>>>>> , Cassandra project encourages, but not demands, that
> contributors
> > > >>> also
> > > >>>>>> upload a patch file to JIRA even in the case of a GH PR
> > > >>>>>>  (as to leave a audit trail, I guess)
> > > >>>>>> .
> > > >>>>>> Or
> > > >>>>>> ,
> > > >>>>>> at
> > > >>>>>>  
> > > >>>>>> least
> > > >>>>>> ,
> > > >>>>>> C* project 
> > > >>>>>> leave
> > > >>>>>> s
> > > >>>>>> up to the contributor
> > > >>>>>> s
> > > >>>>>> to either open a GH PR or upload the patch file
> > > >>>>>>  to JIRA. In fact, Github allows the access to a raw patch or
> > > >> diff,
> > > >>>> it's
> > > >>>>>> just a matter of adding the ".patch" or ".diff" suffix to the
> end
> > > >> of
> > > >>>> the
> > > >>>>>> Pull Request URL.
> > > >>>>>> 
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> +1 about having a 'paper trail'
> > > >>>>>>  of review comments
> > > >>>>>>
> > > >>>>>> o
> > > >>>>>> n JIRA and
> > > >>>>>> /or
> > > >>>>>> mailing list (I
> > > >>>>>>  would
> > > >>>>>> prefer the mailing list tbh). But as Michael and Flavio pointed
> > > >> out,
> > > >>> I
> > > >>>>>> never seen
> > > >>>>>> GH 
> > > >>>>>> PR review
> > > >>>>>> **
> > > >>>>>> comments
> > > >>>>>> **
> > > >>>>>> being written back to JIRA, at least not in Kafka, Cassandra
> > > >>>>>> or
> > > >>>>>> Solr projects
> > > >>>>>> , that I have followed more closely.
> > > >>>>>>
> > > >>>>>> Eddie
> > > >>>>>>
> > > >>>>>>
> > > >>>>>> On Tue, Oct 4, 2016 at 6:40 PM, Michael Han <ha...@cloudera.com>
> > > >>> wrote:
> > > >>>>>>
> > > >>>>>>>>> as long as the opening/closing/commenting all get sent to the
> > > >>>> mailing
> > > >>>>>>> list or recorded in jira
> > > >>>>>>> Yeah, this is my impression as well, that we need to keep
> certain
> > > >>>> paper
> > > >>>>>>> trail regarding activities and comments on ASF side (JIRA or
> mail
> > > >>>> list).
> > > >>>>>>> Infra page said:
> > > >>>>>>>
> > > >>>>>>>  - Any Pull Request that gets opened, closed, reopened or
> > > >>>> **commented**
> > > >>>>>>>  on now gets recorded on the project's mailing list
> > > >>>>>>>  - If a project has a JIRA instance, any PRs or *comments* on
> PRs
> > > >>>> that
> > > >>>>>>>  include a JIRA ticket ID will trigger an update on that
> specific
> > > >>>>> ticket
> > > >>>>>>>
> > > >>>>>>> I checked a couple Kafka and Spark JIRAs but I don't see any of
> > > >> the
> > > >>>>>>> comments made in github PR were posted on JIRA, except the
> > > >>> activities
> > > >>>>> (open
> > > >>>>>>> a PR, close a PR). Since both projects have been using github
> for
> > > >> a
> > > >>>>> while I
> > > >>>>>>> assume such practice of NOT integrating comments between github
> > > >> and
> > > >>>> ASF
> > > >>>>>>> JIRA is acceptable? Though I feel it would be really useful if
> > > >>>> comments
> > > >>>>>>> could converge in a single place as well, that will provide a
> > > >> clear
> > > >>>>> history
> > > >>>>>>> for a given technical issue.
> > > >>>>>>>
> > > >>>>>>> On Tue, Oct 4, 2016 at 12:06 PM, Flavio Junqueira <
> > fpj@apache.org
> > > >>>
> > > >>>>> wrote:
> > > >>>>>>>
> > > >>>>>>>> Until ZOOKEEPER-2597 <https://issues.apache.org/
> > > >>>>>>> jira/browse/ZOOKEEPER-2597>
> > > >>>>>>>> is fixed, we can't merge via github.
> > > >>>>>>>>
> > > >>>>>>>> For code reviews, we can use GH as long as the
> > > >>>>> opening/closing/commenting
> > > >>>>>>>> all get sent to the mailing list or recorded in jira. I don't
> > > >> think
> > > >>>> we
> > > >>>>>>> have
> > > >>>>>>>> that yet, but it is possible according to this:
> > > >>>>>>>>
> > > >>>>>>>> https://blogs.apache.org/infra/entry/improved_
> > > >>>>>>>> integration_between_apache_and <https://blogs.apache.org/
> > > >>>>>>>> infra/entry/improved_integration_between_apache_and>
> > > >>>>>>>>
> > > >>>>>>>> For now, we do need to upload patches and converge using jira.
> > > >>>>>>>>
> > > >>>>>>>> I think Eddie has been looking at this process trying to
> > > >> replicate
> > > >>>> the
> > > >>>>>>>> Kafka setup, so perhaps he can give an update if I'm right.
> > Kafka
> > > >>>>> doesn't
> > > >>>>>>>> send every comment to the mailing list, though, but I'm not
> sure
> > > >> if
> > > >>>>>>> that's
> > > >>>>>>>> acceptable according to the ASF, I need to double-check.
> > > >>>>>>>>
> > > >>>>>>>> -Flavio
> > > >>>>>>>>
> > > >>>>>>>>> On 04 Oct 2016, at 19:42, Michael Han <ha...@cloudera.com>
> > > >> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>> Hi,
> > > >>>>>>>>>
> > > >>>>>>>>> Now we've moved to git, what is the policy for uploading
> > patches
> > > >>> and
> > > >>>>>>>> doing
> > > >>>>>>>>> code reviews? I am asking because I've seen recently there
> are
> > > >> git
> > > >>>>> pull
> > > >>>>>>>>> requests coming in without associated patch file uploaded to
> > > >> JIRA.
> > > >>>>> I've
> > > >>>>>>>>> checked
> > > >>>>>>>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> > > >>>> HowToContribute
> > > >>>>> ,
> > > >>>>>>>>> looks like there is not much change regarding patch process -
> > so
> > > >>>>>>>> presumably
> > > >>>>>>>>> we still need to generate and upload patch file to JIRA for
> the
> > > >>>>> record,
> > > >>>>>>>>> while using github (maybe in addition of review board, or in
> > the
> > > >>>>> future
> > > >>>>>>>>> with gerrit) to do code reviews?
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> On Wed, Sep 21, 2016 at 6:05 AM, Edward Ribeiro <
> > > >>>>>>>> edward.ribeiro@gmail.com>
> > > >>>>>>>>> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>>> Cool, just open https://issues.apache.org/
> > > >>>> jira/browse/ZOOKEEPER-2597
> > > >>>>>>>>>>
> > > >>>>>>>>>> PS: I removed the REPO_HOME global variable.
> > > >>>>>>>>>>
> > > >>>>>>>>>> On Wed, Sep 21, 2016 at 6:53 AM, Flavio Junqueira <
> > > >>> fpj@apache.org>
> > > >>>>>>>> wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>>> Better to have that in the form of a pull request or diff.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> REPO_HOME does seem to be unused.
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> -Flavio
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>> On 20 Sep 2016, at 18:57, Edward Ribeiro <
> > > >>>> edward.ribeiro@gmail.com
> > > >>>>>>
> > > >>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Hey, I have started porting the kafka-merge.py to work on
> ZK
> > > >>>> repos.
> > > >>>>>>> I
> > > >>>>>>>>>>> would
> > > >>>>>>>>>>>> need someone to review it and help me test it now.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> The files were uploaded below, but I will create a github
> > > >> repo
> > > >>>> yet
> > > >>>>>>>>>> today.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> https://www.dropbox.com/sh/od8bet2574jttm3/
> > > >>>>>>>>>>> AADv1DXTb8vfyVCmelFbYCEha?dl=0
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> I uploaded the kafka version script so that you can use
> diff
> > > >> or
> > > >>>>> Meld
> > > >>>>>>>> to
> > > >>>>>>>>>>>> spot my changes, but feel free to grasp the original file
> > > >> here:
> > > >>>>>>>>>>>> https://github.com/apache/kafka/blob/trunk/kafka-merge-
> > pr.py
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> PS: It's just me or REPO_HOME env variable is not used
> > > >> anywhere
> > > >>>> in
> > > >>>>>>> the
> > > >>>>>>>>>>>> merge script???
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> Cheers,
> > > >>>>>>>>>>>> Eddie
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick Hunt <
> > > >>> phunt@apache.org
> > > >>>>>
> > > >>>>>>>>>> wrote:
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin Reed <
> > > >>>> breed@apache.org>
> > > >>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> what you are suggesting sounds good, but i don't know
> how
> > > >> to
> > > >>> do
> > > >>>>>>> it?
> > > >>>>>>>>>>> since
> > > >>>>>>>>>>>>>> in the end we are still just accepting diffs on patches,
> > > >> the
> > > >>>> only
> > > >>>>>>>>>> thing
> > > >>>>>>>>>>>>>> that changes is that we use svn rather than git right?
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Notice the workflow Kafka uses - which includes "git
> apply"
> > > >>> and
> > > >>>>>>>>>>> specifying
> > > >>>>>>>>>>>>> the author tag when committers commit (so that the OP
> gets
> > > >>>> proper
> > > >>>>>>>>>>>>> attribution in the commit itself)
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/
> > > >>>>>>>>>>> Manual+Commit+Workflow
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>> Patrick
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> i LOVE chris's idea! lets do it!
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> ben
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>> On Sun, Sep 18, 2016 at 3:22 PM, Patrick Hunt <
> > > >>>> phunt@apache.org>
> > > >>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Ben, do you also want to update the "Applying a patch"
> > > >>> section
> > > >>>>> to
> > > >>>>>>>>>> make
> > > >>>>>>>>>>>>> it
> > > >>>>>>>>>>>>>>> git specific?
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> We (committers) should move to a model where authors
> get
> > > >>>> proper
> > > >>>>>>>>>> credit
> > > >>>>>>>>>>>>> in
> > > >>>>>>>>>>>>>>> git. Our old workflow in svn resulted in only the
> > > >> committer
> > > >>>>> being
> > > >>>>>>>>>>>>> listed
> > > >>>>>>>>>>>>>>> (except that we listed the patch author in the commit
> > > >>>> message).
> > > >>>>>>> We
> > > >>>>>>>>>>>>> should
> > > >>>>>>>>>>>>>>> move to a model where the author of the patch gets
> proper
> > > >>>> credit
> > > >>>>>>> in
> > > >>>>>>>>>>>>> git.
> > > >>>>>>>>>>>>>> I
> > > >>>>>>>>>>>>>>> believe we will get that if we use git for patch
> > > >>>>>>>>>> creation/application?
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Chris brought up getting rid of CHANGES.txt recently on
> > > >> the
> > > >>>> dev
> > > >>>>>>>> list
> > > >>>>>>>>>>>>> in a
> > > >>>>>>>>>>>>>>> separate thread - Chris do you want to implement that
> > > >> change
> > > >>>> now
> > > >>>>>>>>>> that
> > > >>>>>>>>>>>>>> we've
> > > >>>>>>>>>>>>>>> moved to git?
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> Patrick
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin Reed <
> > > >>>>> breed@apache.org
> > > >>>>>>>>
> > > >>>>>>>>>>>>> wrote:
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> 1) actually in the previous step that was just adding
> > > >> new
> > > >>>>>>> files.
> > > >>>>>>>>>> you
> > > >>>>>>>>>>>>>>>>> still
> > > >>>>>>>>>>>>>>>>>> need the commit -a for the rest of the changes.
> that's
> > > >> my
> > > >>>>>>> normal
> > > >>>>>>>>>>>>>>>>> workflow.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> I think that will be confusing for most folks. They
> > > >>>> typically
> > > >>>>>>>>>> stage
> > > >>>>>>>>>>>>>>>>> all the changes and then commit or don't stage and
> use
> > > >> -a.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> do you mind fixing it with your workflow. commit -a
> > > >> doesn't
> > > >>>> get
> > > >>>>>>>> new
> > > >>>>>>>>>>>>>>>> files, which is why you need to do the add, but i'm
> not
> > > >> the
> > > >>>>> most
> > > >>>>>>>>>>>>>>>> sophisticated git user, so
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>> 2) i figured since we are using git now that we
> should
> > > >>> use
> > > >>>>>>> git's
> > > >>>>>>>>>>>>>>>>> default.
> > > >>>>>>>>>>>>>>>>>> the patch should work (by default it seems to strip
> > the
> > > >>>> first
> > > >>>>>>>>>> path
> > > >>>>>>>>>>>>>>>>> element).
> > > >>>>>>>>>>>>>>>>>> does it not work for you?
> > > >>>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>> It will fail precommit in it's current state.
> > > >>>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>> fixed
> > > >>>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>>
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>> --
> > > >>>>>>>>> Cheers
> > > >>>>>>>>> Michael.
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>
> > > >>>>>>>
> > > >>>>>>> --
> > > >>>>>>> Cheers
> > > >>>>>>> Michael.
> > > >>>>>>>
> > > >>>>>
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> Cheers
> > > >>>> Michael.
> > > >>>>
> > > >>>
> > > >>
> > >
> > >
> >
> >
> > --
> > Cheers
> > Michael.
> >
>



-- 
Cheers
Michael.

Re: [VOTE] move Apache Zookeeper to git

Posted by Edward Ribeiro <ed...@gmail.com>.

Dear community,

The zk-merger-pr.py script has been merged into master (thanks a LOT Ben
Reed for reviewing/discussing/testing and commiting):
https://issues.apache.org/jira/browse/ZOOKEEPER-2597

As stated in the issue and on GH, this tool is a modified version of
similar tools from Kafka, that is a copy of a Spark's one. It has some
rough edges so we will certainly benefit from further enhancements and
fixes. I changed the smallest possible pieces of code, just to make it work
on a ZK repo so the credits go to the original authors.

Some notes:

1. The git PR *review* comments for ZOOKEEPER-2597 didn't show up on JIRA.
Only the opening and closing of the issue. Can we double check this as
INFRA-12752 is closed, Michael Han?

2. I scribbled a draft on how use the tool at
https://docs.google.com/document/d/1i00ZXjrW2fu17vr_h7F1bUrqXg3urw4Hm7KirQDpPIU/edit
 (still very crude, but feel free to improve it). I would like to move this
text to https://cwiki.apache.org/confluence/display/ZOOKEEPER/Index but
looks like I don't have permission to create a page there yet. Any help?

Best regards,
Eddie

On Sat, Oct 22, 2016 at 7:08 PM, Michael Han <ha...@cloudera.com> wrote:

> FYI infra did some work in INFRA-12752 and the git PR comments can be
> pushed to Apache JIRA.
>
> On Sat, Oct 8, 2016 at 8:01 AM, Flavio Junqueira <fp...@apache.org> wrote:
>
> > This is not supported at the moment if nothing has changed:
> >
> > https://issues.apache.org/jira/browse/INFRA-11000 <
> > https://issues.apache.org/jira/browse/INFRA-11000>
> >
> > -Flavio
> >
> > > On 08 Oct 2016, at 00:54, Benjamin Reed <br...@apache.org> wrote:
> > >
> > > it doesn't look like we need to setup keys. this seems to work for me:
> > >
> > > https://git-wip-us.apache.org/#committers-getting-started
> > >
> > > it does seem strange that we aren't using public keys and that i'm
> > sticking
> > > a password in .netrc :P i'm wondering if other projects were able to
> get
> > > this going over ssh.
> > >
> > > i'll take a whack at cleaning up the svn and subversion references.
> > >
> > > ben
> > >
> > > On Fri, Oct 7, 2016 at 12:59 PM, Camille Fournier <ca...@apache.org>
> > > wrote:
> > >
> > >> Hey folks,
> > >>
> > >> So I'm trying to get in a patch but this has not been updated to tell
> > >> committers how to actually get the git keys set up:
> > >> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> > Committing+changes
> > >>
> > >> Can someone float me a link that says how to do this?
> > >>
> > >> Also a bunch of our documentation still discusses SVN and not git,
> which
> > >> means we are not done with this migration. If you were pushing for
> this
> > >> change can you please do some due diligence on the wikis and correct
> the
> > >> stuff that refers to SVN?
> > >>
> > >> Thanks,
> > >> C
> > >>
> > >> On Wed, Oct 5, 2016 at 1:02 PM, Edward Ribeiro <
> > edward.ribeiro@gmail.com>
> > >> wrote:
> > >>
> > >>> Excuse me guys!
> > >>>
> > >>> I've written on Macbook Pro. No idea why GMail messed it up. I was
> only
> > >>> able to see the strange characters when I pasted on a gist text area.
> > The
> > >>> previous message is below, but if anyone is still having trouble (I
> > tried
> > >>> to remove the weird character), I left a copy at:
> > >>> https://gist.github.com/eribeiro/da2a6a6c9a508610d52d0755fae8352d
> > >>>
> > >>> "Hi,
> > >>>
> > >>> The patch attached on ZOOKEEPER-2597 is a straightforward adaptation
> of
> > >>> Kafka's one. It takes care of merging Github PR into Apache git repo
> > and
> > >> a
> > >>> subsequent closing of the PR on the GH side, among other things
> > >> (rewriting
> > >>> of commit messages, etc). The current status is: the script needs to
> be
> > >>> reviewed/validated by a committer. It has been some time since I
> > uploaded
> > >>> the patch, so I gonna do another pass through it in the meantime.
> > >>>
> > >>> There are some workflow issues beyond the scope of ZOOKEEPER-2597
> that
> > >> need
> > >>> to be sorted out (IMO):
> > >>>
> > >>> 1. The normal workflow is to open a JIRA ticket before doing any GH
> PR,
> > >>> that is, no JIRA-less PRs. The PR should have a title of the form
> > >>> "ZOOKEEPER-xxxx: Title". This will trigger the Apache JIRA-Github
> > >>> integration and it's opening show up in the JIRA ticket.
> > >>>
> > >>> 2. OTOH, not every Kafka PR needs a corresponding JIRA ticket. There
> > are
> > >> a
> > >>> class of PRs with "MINOR" title that represent trivial code changes
> and
> > >>> "HOT-FIX" title that fix urgent, but simple bugs. Both bypass the
> JIRA
> > >>> creation step, even tough they are still subject to review. It's
> worth
> > >>> adopting a similar approach for ZK project?
> > >>>
> > >>> 3. IIRC (didn't find any page to confirm), Cassandra project
> > encourages,
> > >>> but not demands, that contributors also upload a patch file to JIRA
> > even
> > >> in
> > >>> the case of a GH PR (as to leave a audit trail, I guess). Or, at
> > least,
> > >> C*
> > >>> project leaves up to the contributors to either open a GH PR or
> upload
> > >> the
> > >>> patch file to JIRA.
> > >>>
> > >>>
> > >>> +1 about having a 'paper trail' of review comments on JIRA and/or
> > mailing
> > >>> list (I would prefer the mailing list tbh). But as Michael and Flavio
> > >>> pointed out, I never seen GH PR review **comments** being written
> back
> > to
> > >>> JIRA, at least not in Kafka, Cassandra or Solr projects, that I have
> > >>> followed more closely.
> > >>>
> > >>> Eddie"
> > >>>
> > >>>
> > >>> On Wed, Oct 5, 2016 at 1:35 PM, Michael Han <ha...@cloudera.com>
> wrote:
> > >>>
> > >>>> Eddie's mail contains lots of '=E2=80=8B'' which is unicode
> character
> > >>>> zero-width space, which might cause parsing trouble for some mail
> > >>> clients.
> > >>>>
> > >>>> On Wed, Oct 5, 2016 at 6:42 AM, Flavio Junqueira <fp...@apache.org>
> > >> wrote:
> > >>>>
> > >>>>> Dude, I'm just not able to parse your e-mail, did you write that
> on a
> > >>>>> phone or something?
> > >>>>>
> > >>>>> -Flavio
> > >>>>>
> > >>>>>> On 05 Oct 2016, at 03:54, Edward Ribeiro <
> edward.ribeiro@gmail.com
> > >>>
> > >>>>> wrote:
> > >>>>>>
> > >>>>>> Hi,
> > >>>>>>
> > >>>>>> The patch attached on ZOOKEEPER-2597 is a
> > >>>>>> straightforward adaptation of
> > >>>>>> Kafka's one. It takes care of merging Github PR into Apache git
> > >> repo
> > >>>> and
> > >>>>>>  a
> > >>>>>> subsequent closing of the PR on the GH side
> > >>>>>>  among other things (rewriting of commit messages, etc)
> > >>>>>> . The current status is: the script needs to be reviewed/validated
> > >>> by a
> > >>>>>> committer.
> > >>>>>> It has been some time since I uploaded the patch, so I gonna do
> > >>>> another
> > >>>>>> pass through it in the meantime.
> > >>>>>>
> > >>>>>>
> > >>>>>> T
> > >>>>>> here are some workflow issues beyond the scope of ZOOKEEPER-2597
> > >>>>>>  that need to be sorted out (IMO)
> > >>>>>> :
> > >>>>>>
> > >>>>>> 1. The normal workflow is to open a JIRA ticket before doing any
> GH
> > >>> PR
> > >>>>>> , that is, no JIRA-less PRs.
> > >>>>>> The PR should have a title of the form "ZOOKEEPER-xxxx: Title".
> > >> This
> > >>>> will
> > >>>>>> trigger the Apache JIRA-Github integration and it's opening show
> up
> > >>> in
> > >>>>> the
> > >>>>>> JIRA ticket.
> > >>>>>>
> > >>>>>> 2.
> > >>>>>> OTOH, n
> > >>>>>> ot every Kafka PR needs a corresponding JIRA ticket
> > >>>>>> . 
> > >>>>>> There are a class of PR
> > >>>>>> s
> > >>>>>> with "MINOR"
> > >>>>>>  title
> > >>>>>> that represent trivial code changes
> > >>>>>>  and "HOT-FIX" title that fix urgent, but simple bugs. Both
> > >>>>>> bypass the JIRA creation step
> > >>>>>> , even tough they are still 
> > >>>>>> subject to review
> > >>>>>> .
> > >>>>>> It's worth adopting a similar approach for ZK project?
> > >>>>>>
> > >>>>>> 3. IIRC
> > >>>>>>  (didn't find any page to confirm)
> > >>>>>> , Cassandra project encourages, but not demands, that contributors
> > >>> also
> > >>>>>> upload a patch file to JIRA even in the case of a GH PR
> > >>>>>>  (as to leave a audit trail, I guess)
> > >>>>>> .
> > >>>>>> Or
> > >>>>>> ,
> > >>>>>> at
> > >>>>>>  
> > >>>>>> least
> > >>>>>> ,
> > >>>>>> C* project 
> > >>>>>> leave
> > >>>>>> s
> > >>>>>> up to the contributor
> > >>>>>> s
> > >>>>>> to either open a GH PR or upload the patch file
> > >>>>>>  to JIRA. In fact, Github allows the access to a raw patch or
> > >> diff,
> > >>>> it's
> > >>>>>> just a matter of adding the ".patch" or ".diff" suffix to the end
> > >> of
> > >>>> the
> > >>>>>> Pull Request URL.
> > >>>>>> 
> > >>>>>>
> > >>>>>>
> > >>>>>> +1 about having a 'paper trail'
> > >>>>>>  of review comments
> > >>>>>>
> > >>>>>> o
> > >>>>>> n JIRA and
> > >>>>>> /or
> > >>>>>> mailing list (I
> > >>>>>>  would
> > >>>>>> prefer the mailing list tbh). But as Michael and Flavio pointed
> > >> out,
> > >>> I
> > >>>>>> never seen
> > >>>>>> GH 
> > >>>>>> PR review
> > >>>>>> **
> > >>>>>> comments
> > >>>>>> **
> > >>>>>> being written back to JIRA, at least not in Kafka, Cassandra
> > >>>>>> or
> > >>>>>> Solr projects
> > >>>>>> , that I have followed more closely.
> > >>>>>>
> > >>>>>> Eddie
> > >>>>>>
> > >>>>>>
> > >>>>>> On Tue, Oct 4, 2016 at 6:40 PM, Michael Han <ha...@cloudera.com>
> > >>> wrote:
> > >>>>>>
> > >>>>>>>>> as long as the opening/closing/commenting all get sent to the
> > >>>> mailing
> > >>>>>>> list or recorded in jira
> > >>>>>>> Yeah, this is my impression as well, that we need to keep certain
> > >>>> paper
> > >>>>>>> trail regarding activities and comments on ASF side (JIRA or mail
> > >>>> list).
> > >>>>>>> Infra page said:
> > >>>>>>>
> > >>>>>>>  - Any Pull Request that gets opened, closed, reopened or
> > >>>> **commented**
> > >>>>>>>  on now gets recorded on the project's mailing list
> > >>>>>>>  - If a project has a JIRA instance, any PRs or *comments* on PRs
> > >>>> that
> > >>>>>>>  include a JIRA ticket ID will trigger an update on that specific
> > >>>>> ticket
> > >>>>>>>
> > >>>>>>> I checked a couple Kafka and Spark JIRAs but I don't see any of
> > >> the
> > >>>>>>> comments made in github PR were posted on JIRA, except the
> > >>> activities
> > >>>>> (open
> > >>>>>>> a PR, close a PR). Since both projects have been using github for
> > >> a
> > >>>>> while I
> > >>>>>>> assume such practice of NOT integrating comments between github
> > >> and
> > >>>> ASF
> > >>>>>>> JIRA is acceptable? Though I feel it would be really useful if
> > >>>> comments
> > >>>>>>> could converge in a single place as well, that will provide a
> > >> clear
> > >>>>> history
> > >>>>>>> for a given technical issue.
> > >>>>>>>
> > >>>>>>> On Tue, Oct 4, 2016 at 12:06 PM, Flavio Junqueira <
> fpj@apache.org
> > >>>
> > >>>>> wrote:
> > >>>>>>>
> > >>>>>>>> Until ZOOKEEPER-2597 <https://issues.apache.org/
> > >>>>>>> jira/browse/ZOOKEEPER-2597>
> > >>>>>>>> is fixed, we can't merge via github.
> > >>>>>>>>
> > >>>>>>>> For code reviews, we can use GH as long as the
> > >>>>> opening/closing/commenting
> > >>>>>>>> all get sent to the mailing list or recorded in jira. I don't
> > >> think
> > >>>> we
> > >>>>>>> have
> > >>>>>>>> that yet, but it is possible according to this:
> > >>>>>>>>
> > >>>>>>>> https://blogs.apache.org/infra/entry/improved_
> > >>>>>>>> integration_between_apache_and <https://blogs.apache.org/
> > >>>>>>>> infra/entry/improved_integration_between_apache_and>
> > >>>>>>>>
> > >>>>>>>> For now, we do need to upload patches and converge using jira.
> > >>>>>>>>
> > >>>>>>>> I think Eddie has been looking at this process trying to
> > >> replicate
> > >>>> the
> > >>>>>>>> Kafka setup, so perhaps he can give an update if I'm right.
> Kafka
> > >>>>> doesn't
> > >>>>>>>> send every comment to the mailing list, though, but I'm not sure
> > >> if
> > >>>>>>> that's
> > >>>>>>>> acceptable according to the ASF, I need to double-check.
> > >>>>>>>>
> > >>>>>>>> -Flavio
> > >>>>>>>>
> > >>>>>>>>> On 04 Oct 2016, at 19:42, Michael Han <ha...@cloudera.com>
> > >> wrote:
> > >>>>>>>>>
> > >>>>>>>>> Hi,
> > >>>>>>>>>
> > >>>>>>>>> Now we've moved to git, what is the policy for uploading
> patches
> > >>> and
> > >>>>>>>> doing
> > >>>>>>>>> code reviews? I am asking because I've seen recently there are
> > >> git
> > >>>>> pull
> > >>>>>>>>> requests coming in without associated patch file uploaded to
> > >> JIRA.
> > >>>>> I've
> > >>>>>>>>> checked
> > >>>>>>>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> > >>>> HowToContribute
> > >>>>> ,
> > >>>>>>>>> looks like there is not much change regarding patch process -
> so
> > >>>>>>>> presumably
> > >>>>>>>>> we still need to generate and upload patch file to JIRA for the
> > >>>>> record,
> > >>>>>>>>> while using github (maybe in addition of review board, or in
> the
> > >>>>> future
> > >>>>>>>>> with gerrit) to do code reviews?
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> On Wed, Sep 21, 2016 at 6:05 AM, Edward Ribeiro <
> > >>>>>>>> edward.ribeiro@gmail.com>
> > >>>>>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> Cool, just open https://issues.apache.org/
> > >>>> jira/browse/ZOOKEEPER-2597
> > >>>>>>>>>>
> > >>>>>>>>>> PS: I removed the REPO_HOME global variable.
> > >>>>>>>>>>
> > >>>>>>>>>> On Wed, Sep 21, 2016 at 6:53 AM, Flavio Junqueira <
> > >>> fpj@apache.org>
> > >>>>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>> Better to have that in the form of a pull request or diff.
> > >>>>>>>>>>>
> > >>>>>>>>>>> REPO_HOME does seem to be unused.
> > >>>>>>>>>>>
> > >>>>>>>>>>> -Flavio
> > >>>>>>>>>>>
> > >>>>>>>>>>>> On 20 Sep 2016, at 18:57, Edward Ribeiro <
> > >>>> edward.ribeiro@gmail.com
> > >>>>>>
> > >>>>>>>>>>> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Hey, I have started porting the kafka-merge.py to work on ZK
> > >>>> repos.
> > >>>>>>> I
> > >>>>>>>>>>> would
> > >>>>>>>>>>>> need someone to review it and help me test it now.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> The files were uploaded below, but I will create a github
> > >> repo
> > >>>> yet
> > >>>>>>>>>> today.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> https://www.dropbox.com/sh/od8bet2574jttm3/
> > >>>>>>>>>>> AADv1DXTb8vfyVCmelFbYCEha?dl=0
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I uploaded the kafka version script so that you can use diff
> > >> or
> > >>>>> Meld
> > >>>>>>>> to
> > >>>>>>>>>>>> spot my changes, but feel free to grasp the original file
> > >> here:
> > >>>>>>>>>>>> https://github.com/apache/kafka/blob/trunk/kafka-merge-
> pr.py
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> PS: It's just me or REPO_HOME env variable is not used
> > >> anywhere
> > >>>> in
> > >>>>>>> the
> > >>>>>>>>>>>> merge script???
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> Cheers,
> > >>>>>>>>>>>> Eddie
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick Hunt <
> > >>> phunt@apache.org
> > >>>>>
> > >>>>>>>>>> wrote:
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin Reed <
> > >>>> breed@apache.org>
> > >>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> what you are suggesting sounds good, but i don't know how
> > >> to
> > >>> do
> > >>>>>>> it?
> > >>>>>>>>>>> since
> > >>>>>>>>>>>>>> in the end we are still just accepting diffs on patches,
> > >> the
> > >>>> only
> > >>>>>>>>>> thing
> > >>>>>>>>>>>>>> that changes is that we use svn rather than git right?
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>> Notice the workflow Kafka uses - which includes "git apply"
> > >>> and
> > >>>>>>>>>>> specifying
> > >>>>>>>>>>>>> the author tag when committers commit (so that the OP gets
> > >>>> proper
> > >>>>>>>>>>>>> attribution in the commit itself)
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/
> > >>>>>>>>>>> Manual+Commit+Workflow
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>> Patrick
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>>> i LOVE chris's idea! lets do it!
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> ben
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>> On Sun, Sep 18, 2016 at 3:22 PM, Patrick Hunt <
> > >>>> phunt@apache.org>
> > >>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Ben, do you also want to update the "Applying a patch"
> > >>> section
> > >>>>> to
> > >>>>>>>>>> make
> > >>>>>>>>>>>>> it
> > >>>>>>>>>>>>>>> git specific?
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> We (committers) should move to a model where authors get
> > >>>> proper
> > >>>>>>>>>> credit
> > >>>>>>>>>>>>> in
> > >>>>>>>>>>>>>>> git. Our old workflow in svn resulted in only the
> > >> committer
> > >>>>> being
> > >>>>>>>>>>>>> listed
> > >>>>>>>>>>>>>>> (except that we listed the patch author in the commit
> > >>>> message).
> > >>>>>>> We
> > >>>>>>>>>>>>> should
> > >>>>>>>>>>>>>>> move to a model where the author of the patch gets proper
> > >>>> credit
> > >>>>>>> in
> > >>>>>>>>>>>>> git.
> > >>>>>>>>>>>>>> I
> > >>>>>>>>>>>>>>> believe we will get that if we use git for patch
> > >>>>>>>>>> creation/application?
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Chris brought up getting rid of CHANGES.txt recently on
> > >> the
> > >>>> dev
> > >>>>>>>> list
> > >>>>>>>>>>>>> in a
> > >>>>>>>>>>>>>>> separate thread - Chris do you want to implement that
> > >> change
> > >>>> now
> > >>>>>>>>>> that
> > >>>>>>>>>>>>>> we've
> > >>>>>>>>>>>>>>> moved to git?
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> Patrick
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin Reed <
> > >>>>> breed@apache.org
> > >>>>>>>>
> > >>>>>>>>>>>>> wrote:
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> 1) actually in the previous step that was just adding
> > >> new
> > >>>>>>> files.
> > >>>>>>>>>> you
> > >>>>>>>>>>>>>>>>> still
> > >>>>>>>>>>>>>>>>>> need the commit -a for the rest of the changes. that's
> > >> my
> > >>>>>>> normal
> > >>>>>>>>>>>>>>>>> workflow.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> I think that will be confusing for most folks. They
> > >>>> typically
> > >>>>>>>>>> stage
> > >>>>>>>>>>>>>>>>> all the changes and then commit or don't stage and use
> > >> -a.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> do you mind fixing it with your workflow. commit -a
> > >> doesn't
> > >>>> get
> > >>>>>>>> new
> > >>>>>>>>>>>>>>>> files, which is why you need to do the add, but i'm not
> > >> the
> > >>>>> most
> > >>>>>>>>>>>>>>>> sophisticated git user, so
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>> 2) i figured since we are using git now that we should
> > >>> use
> > >>>>>>> git's
> > >>>>>>>>>>>>>>>>> default.
> > >>>>>>>>>>>>>>>>>> the patch should work (by default it seems to strip
> the
> > >>>> first
> > >>>>>>>>>> path
> > >>>>>>>>>>>>>>>>> element).
> > >>>>>>>>>>>>>>>>>> does it not work for you?
> > >>>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>> It will fail precommit in it's current state.
> > >>>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>> fixed
> > >>>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>>
> > >>>>>>>>>>>>>>
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> --
> > >>>>>>>>> Cheers
> > >>>>>>>>> Michael.
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>> --
> > >>>>>>> Cheers
> > >>>>>>> Michael.
> > >>>>>>>
> > >>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Cheers
> > >>>> Michael.
> > >>>>
> > >>>
> > >>
> >
> >
>
>
> --
> Cheers
> Michael.
>

Re: [VOTE] move Apache Zookeeper to git

Posted by Michael Han <ha...@cloudera.com>.

FYI infra did some work in INFRA-12752 and the git PR comments can be
pushed to Apache JIRA.

On Sat, Oct 8, 2016 at 8:01 AM, Flavio Junqueira <fp...@apache.org> wrote:

> This is not supported at the moment if nothing has changed:
>
> https://issues.apache.org/jira/browse/INFRA-11000 <
> https://issues.apache.org/jira/browse/INFRA-11000>
>
> -Flavio
>
> > On 08 Oct 2016, at 00:54, Benjamin Reed <br...@apache.org> wrote:
> >
> > it doesn't look like we need to setup keys. this seems to work for me:
> >
> > https://git-wip-us.apache.org/#committers-getting-started
> >
> > it does seem strange that we aren't using public keys and that i'm
> sticking
> > a password in .netrc :P i'm wondering if other projects were able to get
> > this going over ssh.
> >
> > i'll take a whack at cleaning up the svn and subversion references.
> >
> > ben
> >
> > On Fri, Oct 7, 2016 at 12:59 PM, Camille Fournier <ca...@apache.org>
> > wrote:
> >
> >> Hey folks,
> >>
> >> So I'm trying to get in a patch but this has not been updated to tell
> >> committers how to actually get the git keys set up:
> >> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> Committing+changes
> >>
> >> Can someone float me a link that says how to do this?
> >>
> >> Also a bunch of our documentation still discusses SVN and not git, which
> >> means we are not done with this migration. If you were pushing for this
> >> change can you please do some due diligence on the wikis and correct the
> >> stuff that refers to SVN?
> >>
> >> Thanks,
> >> C
> >>
> >> On Wed, Oct 5, 2016 at 1:02 PM, Edward Ribeiro <
> edward.ribeiro@gmail.com>
> >> wrote:
> >>
> >>> Excuse me guys!
> >>>
> >>> I've written on Macbook Pro. No idea why GMail messed it up. I was only
> >>> able to see the strange characters when I pasted on a gist text area.
> The
> >>> previous message is below, but if anyone is still having trouble (I
> tried
> >>> to remove the weird character), I left a copy at:
> >>> https://gist.github.com/eribeiro/da2a6a6c9a508610d52d0755fae8352d
> >>>
> >>> "Hi,
> >>>
> >>> The patch attached on ZOOKEEPER-2597 is a straightforward adaptation of
> >>> Kafka's one. It takes care of merging Github PR into Apache git repo
> and
> >> a
> >>> subsequent closing of the PR on the GH side, among other things
> >> (rewriting
> >>> of commit messages, etc). The current status is: the script needs to be
> >>> reviewed/validated by a committer. It has been some time since I
> uploaded
> >>> the patch, so I gonna do another pass through it in the meantime.
> >>>
> >>> There are some workflow issues beyond the scope of ZOOKEEPER-2597 that
> >> need
> >>> to be sorted out (IMO):
> >>>
> >>> 1. The normal workflow is to open a JIRA ticket before doing any GH PR,
> >>> that is, no JIRA-less PRs. The PR should have a title of the form
> >>> "ZOOKEEPER-xxxx: Title". This will trigger the Apache JIRA-Github
> >>> integration and it's opening show up in the JIRA ticket.
> >>>
> >>> 2. OTOH, not every Kafka PR needs a corresponding JIRA ticket. There
> are
> >> a
> >>> class of PRs with "MINOR" title that represent trivial code changes and
> >>> "HOT-FIX" title that fix urgent, but simple bugs. Both bypass the JIRA
> >>> creation step, even tough they are still subject to review. It's worth
> >>> adopting a similar approach for ZK project?
> >>>
> >>> 3. IIRC (didn't find any page to confirm), Cassandra project
> encourages,
> >>> but not demands, that contributors also upload a patch file to JIRA
> even
> >> in
> >>> the case of a GH PR (as to leave a audit trail, I guess). Or, at
> least,
> >> C*
> >>> project leaves up to the contributors to either open a GH PR or upload
> >> the
> >>> patch file to JIRA.
> >>>
> >>>
> >>> +1 about having a 'paper trail' of review comments on JIRA and/or
> mailing
> >>> list (I would prefer the mailing list tbh). But as Michael and Flavio
> >>> pointed out, I never seen GH PR review **comments** being written back
> to
> >>> JIRA, at least not in Kafka, Cassandra or Solr projects, that I have
> >>> followed more closely.
> >>>
> >>> Eddie"
> >>>
> >>>
> >>> On Wed, Oct 5, 2016 at 1:35 PM, Michael Han <ha...@cloudera.com> wrote:
> >>>
> >>>> Eddie's mail contains lots of '=E2=80=8B'' which is unicode character
> >>>> zero-width space, which might cause parsing trouble for some mail
> >>> clients.
> >>>>
> >>>> On Wed, Oct 5, 2016 at 6:42 AM, Flavio Junqueira <fp...@apache.org>
> >> wrote:
> >>>>
> >>>>> Dude, I'm just not able to parse your e-mail, did you write that on a
> >>>>> phone or something?
> >>>>>
> >>>>> -Flavio
> >>>>>
> >>>>>> On 05 Oct 2016, at 03:54, Edward Ribeiro <edward.ribeiro@gmail.com
> >>>
> >>>>> wrote:
> >>>>>>
> >>>>>> Hi,
> >>>>>>
> >>>>>> The patch attached on ZOOKEEPER-2597 is a
> >>>>>> straightforward adaptation of
> >>>>>> Kafka's one. It takes care of merging Github PR into Apache git
> >> repo
> >>>> and
> >>>>>>  a
> >>>>>> subsequent closing of the PR on the GH side
> >>>>>>  among other things (rewriting of commit messages, etc)
> >>>>>> . The current status is: the script needs to be reviewed/validated
> >>> by a
> >>>>>> committer.
> >>>>>> It has been some time since I uploaded the patch, so I gonna do
> >>>> another
> >>>>>> pass through it in the meantime.
> >>>>>>
> >>>>>>
> >>>>>> T
> >>>>>> here are some workflow issues beyond the scope of ZOOKEEPER-2597
> >>>>>>  that need to be sorted out (IMO)
> >>>>>> :
> >>>>>>
> >>>>>> 1. The normal workflow is to open a JIRA ticket before doing any GH
> >>> PR
> >>>>>> , that is, no JIRA-less PRs.
> >>>>>> The PR should have a title of the form "ZOOKEEPER-xxxx: Title".
> >> This
> >>>> will
> >>>>>> trigger the Apache JIRA-Github integration and it's opening show up
> >>> in
> >>>>> the
> >>>>>> JIRA ticket.
> >>>>>>
> >>>>>> 2.
> >>>>>> OTOH, n
> >>>>>> ot every Kafka PR needs a corresponding JIRA ticket
> >>>>>> . 
> >>>>>> There are a class of PR
> >>>>>> s
> >>>>>> with "MINOR"
> >>>>>>  title
> >>>>>> that represent trivial code changes
> >>>>>>  and "HOT-FIX" title that fix urgent, but simple bugs. Both
> >>>>>> bypass the JIRA creation step
> >>>>>> , even tough they are still 
> >>>>>> subject to review
> >>>>>> .
> >>>>>> It's worth adopting a similar approach for ZK project?
> >>>>>>
> >>>>>> 3. IIRC
> >>>>>>  (didn't find any page to confirm)
> >>>>>> , Cassandra project encourages, but not demands, that contributors
> >>> also
> >>>>>> upload a patch file to JIRA even in the case of a GH PR
> >>>>>>  (as to leave a audit trail, I guess)
> >>>>>> .
> >>>>>> Or
> >>>>>> ,
> >>>>>> at
> >>>>>>  
> >>>>>> least
> >>>>>> ,
> >>>>>> C* project 
> >>>>>> leave
> >>>>>> s
> >>>>>> up to the contributor
> >>>>>> s
> >>>>>> to either open a GH PR or upload the patch file
> >>>>>>  to JIRA. In fact, Github allows the access to a raw patch or
> >> diff,
> >>>> it's
> >>>>>> just a matter of adding the ".patch" or ".diff" suffix to the end
> >> of
> >>>> the
> >>>>>> Pull Request URL.
> >>>>>> 
> >>>>>>
> >>>>>>
> >>>>>> +1 about having a 'paper trail'
> >>>>>>  of review comments
> >>>>>>
> >>>>>> o
> >>>>>> n JIRA and
> >>>>>> /or
> >>>>>> mailing list (I
> >>>>>>  would
> >>>>>> prefer the mailing list tbh). But as Michael and Flavio pointed
> >> out,
> >>> I
> >>>>>> never seen
> >>>>>> GH 
> >>>>>> PR review
> >>>>>> **
> >>>>>> comments
> >>>>>> **
> >>>>>> being written back to JIRA, at least not in Kafka, Cassandra
> >>>>>> or
> >>>>>> Solr projects
> >>>>>> , that I have followed more closely.
> >>>>>>
> >>>>>> Eddie
> >>>>>>
> >>>>>>
> >>>>>> On Tue, Oct 4, 2016 at 6:40 PM, Michael Han <ha...@cloudera.com>
> >>> wrote:
> >>>>>>
> >>>>>>>>> as long as the opening/closing/commenting all get sent to the
> >>>> mailing
> >>>>>>> list or recorded in jira
> >>>>>>> Yeah, this is my impression as well, that we need to keep certain
> >>>> paper
> >>>>>>> trail regarding activities and comments on ASF side (JIRA or mail
> >>>> list).
> >>>>>>> Infra page said:
> >>>>>>>
> >>>>>>>  - Any Pull Request that gets opened, closed, reopened or
> >>>> **commented**
> >>>>>>>  on now gets recorded on the project's mailing list
> >>>>>>>  - If a project has a JIRA instance, any PRs or *comments* on PRs
> >>>> that
> >>>>>>>  include a JIRA ticket ID will trigger an update on that specific
> >>>>> ticket
> >>>>>>>
> >>>>>>> I checked a couple Kafka and Spark JIRAs but I don't see any of
> >> the
> >>>>>>> comments made in github PR were posted on JIRA, except the
> >>> activities
> >>>>> (open
> >>>>>>> a PR, close a PR). Since both projects have been using github for
> >> a
> >>>>> while I
> >>>>>>> assume such practice of NOT integrating comments between github
> >> and
> >>>> ASF
> >>>>>>> JIRA is acceptable? Though I feel it would be really useful if
> >>>> comments
> >>>>>>> could converge in a single place as well, that will provide a
> >> clear
> >>>>> history
> >>>>>>> for a given technical issue.
> >>>>>>>
> >>>>>>> On Tue, Oct 4, 2016 at 12:06 PM, Flavio Junqueira <fpj@apache.org
> >>>
> >>>>> wrote:
> >>>>>>>
> >>>>>>>> Until ZOOKEEPER-2597 <https://issues.apache.org/
> >>>>>>> jira/browse/ZOOKEEPER-2597>
> >>>>>>>> is fixed, we can't merge via github.
> >>>>>>>>
> >>>>>>>> For code reviews, we can use GH as long as the
> >>>>> opening/closing/commenting
> >>>>>>>> all get sent to the mailing list or recorded in jira. I don't
> >> think
> >>>> we
> >>>>>>> have
> >>>>>>>> that yet, but it is possible according to this:
> >>>>>>>>
> >>>>>>>> https://blogs.apache.org/infra/entry/improved_
> >>>>>>>> integration_between_apache_and <https://blogs.apache.org/
> >>>>>>>> infra/entry/improved_integration_between_apache_and>
> >>>>>>>>
> >>>>>>>> For now, we do need to upload patches and converge using jira.
> >>>>>>>>
> >>>>>>>> I think Eddie has been looking at this process trying to
> >> replicate
> >>>> the
> >>>>>>>> Kafka setup, so perhaps he can give an update if I'm right. Kafka
> >>>>> doesn't
> >>>>>>>> send every comment to the mailing list, though, but I'm not sure
> >> if
> >>>>>>> that's
> >>>>>>>> acceptable according to the ASF, I need to double-check.
> >>>>>>>>
> >>>>>>>> -Flavio
> >>>>>>>>
> >>>>>>>>> On 04 Oct 2016, at 19:42, Michael Han <ha...@cloudera.com>
> >> wrote:
> >>>>>>>>>
> >>>>>>>>> Hi,
> >>>>>>>>>
> >>>>>>>>> Now we've moved to git, what is the policy for uploading patches
> >>> and
> >>>>>>>> doing
> >>>>>>>>> code reviews? I am asking because I've seen recently there are
> >> git
> >>>>> pull
> >>>>>>>>> requests coming in without associated patch file uploaded to
> >> JIRA.
> >>>>> I've
> >>>>>>>>> checked
> >>>>>>>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> >>>> HowToContribute
> >>>>> ,
> >>>>>>>>> looks like there is not much change regarding patch process - so
> >>>>>>>> presumably
> >>>>>>>>> we still need to generate and upload patch file to JIRA for the
> >>>>> record,
> >>>>>>>>> while using github (maybe in addition of review board, or in the
> >>>>> future
> >>>>>>>>> with gerrit) to do code reviews?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> On Wed, Sep 21, 2016 at 6:05 AM, Edward Ribeiro <
> >>>>>>>> edward.ribeiro@gmail.com>
> >>>>>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Cool, just open https://issues.apache.org/
> >>>> jira/browse/ZOOKEEPER-2597
> >>>>>>>>>>
> >>>>>>>>>> PS: I removed the REPO_HOME global variable.
> >>>>>>>>>>
> >>>>>>>>>> On Wed, Sep 21, 2016 at 6:53 AM, Flavio Junqueira <
> >>> fpj@apache.org>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>> Better to have that in the form of a pull request or diff.
> >>>>>>>>>>>
> >>>>>>>>>>> REPO_HOME does seem to be unused.
> >>>>>>>>>>>
> >>>>>>>>>>> -Flavio
> >>>>>>>>>>>
> >>>>>>>>>>>> On 20 Sep 2016, at 18:57, Edward Ribeiro <
> >>>> edward.ribeiro@gmail.com
> >>>>>>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>> Hey, I have started porting the kafka-merge.py to work on ZK
> >>>> repos.
> >>>>>>> I
> >>>>>>>>>>> would
> >>>>>>>>>>>> need someone to review it and help me test it now.
> >>>>>>>>>>>>
> >>>>>>>>>>>> The files were uploaded below, but I will create a github
> >> repo
> >>>> yet
> >>>>>>>>>> today.
> >>>>>>>>>>>>
> >>>>>>>>>>>> https://www.dropbox.com/sh/od8bet2574jttm3/
> >>>>>>>>>>> AADv1DXTb8vfyVCmelFbYCEha?dl=0
> >>>>>>>>>>>>
> >>>>>>>>>>>> I uploaded the kafka version script so that you can use diff
> >> or
> >>>>> Meld
> >>>>>>>> to
> >>>>>>>>>>>> spot my changes, but feel free to grasp the original file
> >> here:
> >>>>>>>>>>>> https://github.com/apache/kafka/blob/trunk/kafka-merge-pr.py
> >>>>>>>>>>>>
> >>>>>>>>>>>> PS: It's just me or REPO_HOME env variable is not used
> >> anywhere
> >>>> in
> >>>>>>> the
> >>>>>>>>>>>> merge script???
> >>>>>>>>>>>>
> >>>>>>>>>>>> Cheers,
> >>>>>>>>>>>> Eddie
> >>>>>>>>>>>>
> >>>>>>>>>>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick Hunt <
> >>> phunt@apache.org
> >>>>>
> >>>>>>>>>> wrote:
> >>>>>>>>>>>>
> >>>>>>>>>>>>> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin Reed <
> >>>> breed@apache.org>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> what you are suggesting sounds good, but i don't know how
> >> to
> >>> do
> >>>>>>> it?
> >>>>>>>>>>> since
> >>>>>>>>>>>>>> in the end we are still just accepting diffs on patches,
> >> the
> >>>> only
> >>>>>>>>>> thing
> >>>>>>>>>>>>>> that changes is that we use svn rather than git right?
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>> Notice the workflow Kafka uses - which includes "git apply"
> >>> and
> >>>>>>>>>>> specifying
> >>>>>>>>>>>>> the author tag when committers commit (so that the OP gets
> >>>> proper
> >>>>>>>>>>>>> attribution in the commit itself)
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/
> >>>>>>>>>>> Manual+Commit+Workflow
> >>>>>>>>>>>>>
> >>>>>>>>>>>>> Patrick
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>>>> i LOVE chris's idea! lets do it!
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> ben
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>> On Sun, Sep 18, 2016 at 3:22 PM, Patrick Hunt <
> >>>> phunt@apache.org>
> >>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Ben, do you also want to update the "Applying a patch"
> >>> section
> >>>>> to
> >>>>>>>>>> make
> >>>>>>>>>>>>> it
> >>>>>>>>>>>>>>> git specific?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> We (committers) should move to a model where authors get
> >>>> proper
> >>>>>>>>>> credit
> >>>>>>>>>>>>> in
> >>>>>>>>>>>>>>> git. Our old workflow in svn resulted in only the
> >> committer
> >>>>> being
> >>>>>>>>>>>>> listed
> >>>>>>>>>>>>>>> (except that we listed the patch author in the commit
> >>>> message).
> >>>>>>> We
> >>>>>>>>>>>>> should
> >>>>>>>>>>>>>>> move to a model where the author of the patch gets proper
> >>>> credit
> >>>>>>> in
> >>>>>>>>>>>>> git.
> >>>>>>>>>>>>>> I
> >>>>>>>>>>>>>>> believe we will get that if we use git for patch
> >>>>>>>>>> creation/application?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Chris brought up getting rid of CHANGES.txt recently on
> >> the
> >>>> dev
> >>>>>>>> list
> >>>>>>>>>>>>> in a
> >>>>>>>>>>>>>>> separate thread - Chris do you want to implement that
> >> change
> >>>> now
> >>>>>>>>>> that
> >>>>>>>>>>>>>> we've
> >>>>>>>>>>>>>>> moved to git?
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> Patrick
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin Reed <
> >>>>> breed@apache.org
> >>>>>>>>
> >>>>>>>>>>>>> wrote:
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> 1) actually in the previous step that was just adding
> >> new
> >>>>>>> files.
> >>>>>>>>>> you
> >>>>>>>>>>>>>>>>> still
> >>>>>>>>>>>>>>>>>> need the commit -a for the rest of the changes. that's
> >> my
> >>>>>>> normal
> >>>>>>>>>>>>>>>>> workflow.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> I think that will be confusing for most folks. They
> >>>> typically
> >>>>>>>>>> stage
> >>>>>>>>>>>>>>>>> all the changes and then commit or don't stage and use
> >> -a.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> do you mind fixing it with your workflow. commit -a
> >> doesn't
> >>>> get
> >>>>>>>> new
> >>>>>>>>>>>>>>>> files, which is why you need to do the add, but i'm not
> >> the
> >>>>> most
> >>>>>>>>>>>>>>>> sophisticated git user, so
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>> 2) i figured since we are using git now that we should
> >>> use
> >>>>>>> git's
> >>>>>>>>>>>>>>>>> default.
> >>>>>>>>>>>>>>>>>> the patch should work (by default it seems to strip the
> >>>> first
> >>>>>>>>>> path
> >>>>>>>>>>>>>>>>> element).
> >>>>>>>>>>>>>>>>>> does it not work for you?
> >>>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>> It will fail precommit in it's current state.
> >>>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>> fixed
> >>>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>>
> >>>>>>>>>>>>>>
> >>>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> --
> >>>>>>>>> Cheers
> >>>>>>>>> Michael.
> >>>>>>>>
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>> --
> >>>>>>> Cheers
> >>>>>>> Michael.
> >>>>>>>
> >>>>>
> >>>>>
> >>>>
> >>>>
> >>>> --
> >>>> Cheers
> >>>> Michael.
> >>>>
> >>>
> >>
>
>


-- 
Cheers
Michael.

Re: [VOTE] move Apache Zookeeper to git

Posted by Flavio Junqueira <fp...@apache.org>.

This is not supported at the moment if nothing has changed:

https://issues.apache.org/jira/browse/INFRA-11000 <https://issues.apache.org/jira/browse/INFRA-11000>

-Flavio

> On 08 Oct 2016, at 00:54, Benjamin Reed <br...@apache.org> wrote:
> 
> it doesn't look like we need to setup keys. this seems to work for me:
> 
> https://git-wip-us.apache.org/#committers-getting-started
> 
> it does seem strange that we aren't using public keys and that i'm sticking
> a password in .netrc :P i'm wondering if other projects were able to get
> this going over ssh.
> 
> i'll take a whack at cleaning up the svn and subversion references.
> 
> ben
> 
> On Fri, Oct 7, 2016 at 12:59 PM, Camille Fournier <ca...@apache.org>
> wrote:
> 
>> Hey folks,
>> 
>> So I'm trying to get in a patch but this has not been updated to tell
>> committers how to actually get the git keys set up:
>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/Committing+changes
>> 
>> Can someone float me a link that says how to do this?
>> 
>> Also a bunch of our documentation still discusses SVN and not git, which
>> means we are not done with this migration. If you were pushing for this
>> change can you please do some due diligence on the wikis and correct the
>> stuff that refers to SVN?
>> 
>> Thanks,
>> C
>> 
>> On Wed, Oct 5, 2016 at 1:02 PM, Edward Ribeiro <ed...@gmail.com>
>> wrote:
>> 
>>> Excuse me guys!
>>> 
>>> I've written on Macbook Pro. No idea why GMail messed it up. I was only
>>> able to see the strange characters when I pasted on a gist text area. The
>>> previous message is below, but if anyone is still having trouble (I tried
>>> to remove the weird character), I left a copy at:
>>> https://gist.github.com/eribeiro/da2a6a6c9a508610d52d0755fae8352d
>>> 
>>> "Hi,
>>> 
>>> The patch attached on ZOOKEEPER-2597 is a straightforward adaptation of
>>> Kafka's one. It takes care of merging Github PR into Apache git repo and
>> a
>>> subsequent closing of the PR on the GH side, among other things
>> (rewriting
>>> of commit messages, etc). The current status is: the script needs to be
>>> reviewed/validated by a committer. It has been some time since I uploaded
>>> the patch, so I gonna do another pass through it in the meantime.
>>> 
>>> There are some workflow issues beyond the scope of ZOOKEEPER-2597 that
>> need
>>> to be sorted out (IMO):
>>> 
>>> 1. The normal workflow is to open a JIRA ticket before doing any GH PR,
>>> that is, no JIRA-less PRs. The PR should have a title of the form
>>> "ZOOKEEPER-xxxx: Title". This will trigger the Apache JIRA-Github
>>> integration and it's opening show up in the JIRA ticket.
>>> 
>>> 2. OTOH, not every Kafka PR needs a corresponding JIRA ticket. There are
>> a
>>> class of PRs with "MINOR" title that represent trivial code changes and
>>> "HOT-FIX" title that fix urgent, but simple bugs. Both bypass the JIRA
>>> creation step, even tough they are still subject to review. It's worth
>>> adopting a similar approach for ZK project?
>>> 
>>> 3. IIRC (didn't find any page to confirm), Cassandra project encourages,
>>> but not demands, that contributors also upload a patch file to JIRA even
>> in
>>> the case of a GH PR (as to leave a audit trail, I guess). Or, at  least,
>> C*
>>> project leaves up to the contributors to either open a GH PR or upload
>> the
>>> patch file to JIRA.
>>> 
>>> 
>>> +1 about having a 'paper trail' of review comments on JIRA and/or mailing
>>> list (I would prefer the mailing list tbh). But as Michael and Flavio
>>> pointed out, I never seen GH PR review **comments** being written back to
>>> JIRA, at least not in Kafka, Cassandra or Solr projects, that I have
>>> followed more closely.
>>> 
>>> Eddie"
>>> 
>>> 
>>> On Wed, Oct 5, 2016 at 1:35 PM, Michael Han <ha...@cloudera.com> wrote:
>>> 
>>>> Eddie's mail contains lots of '=E2=80=8B'' which is unicode character
>>>> zero-width space, which might cause parsing trouble for some mail
>>> clients.
>>>> 
>>>> On Wed, Oct 5, 2016 at 6:42 AM, Flavio Junqueira <fp...@apache.org>
>> wrote:
>>>> 
>>>>> Dude, I'm just not able to parse your e-mail, did you write that on a
>>>>> phone or something?
>>>>> 
>>>>> -Flavio
>>>>> 
>>>>>> On 05 Oct 2016, at 03:54, Edward Ribeiro <edward.ribeiro@gmail.com
>>> 
>>>>> wrote:
>>>>>> 
>>>>>> Hi,
>>>>>> 
>>>>>> The patch attached on ZOOKEEPER-2597 is a
>>>>>> straightforward adaptation of
>>>>>> Kafka's one. It takes care of merging Github PR into Apache git
>> repo
>>>> and
>>>>>>  a
>>>>>> subsequent closing of the PR on the GH side
>>>>>>  among other things (rewriting of commit messages, etc)
>>>>>> . The current status is: the script needs to be reviewed/validated
>>> by a
>>>>>> committer.
>>>>>> It has been some time since I uploaded the patch, so I gonna do
>>>> another
>>>>>> pass through it in the meantime.
>>>>>> 
>>>>>> 
>>>>>> T
>>>>>> here are some workflow issues beyond the scope of ZOOKEEPER-2597
>>>>>>  that need to be sorted out (IMO)
>>>>>> :
>>>>>> 
>>>>>> 1. The normal workflow is to open a JIRA ticket before doing any GH
>>> PR
>>>>>> , that is, no JIRA-less PRs.
>>>>>> The PR should have a title of the form "ZOOKEEPER-xxxx: Title".
>> This
>>>> will
>>>>>> trigger the Apache JIRA-Github integration and it's opening show up
>>> in
>>>>> the
>>>>>> JIRA ticket.
>>>>>> 
>>>>>> 2.
>>>>>> OTOH, n
>>>>>> ot every Kafka PR needs a corresponding JIRA ticket
>>>>>> . 
>>>>>> There are a class of PR
>>>>>> s
>>>>>> with "MINOR"
>>>>>>  title
>>>>>> that represent trivial code changes
>>>>>>  and "HOT-FIX" title that fix urgent, but simple bugs. Both
>>>>>> bypass the JIRA creation step
>>>>>> , even tough they are still 
>>>>>> subject to review
>>>>>> .
>>>>>> It's worth adopting a similar approach for ZK project?
>>>>>> 
>>>>>> 3. IIRC
>>>>>>  (didn't find any page to confirm)
>>>>>> , Cassandra project encourages, but not demands, that contributors
>>> also
>>>>>> upload a patch file to JIRA even in the case of a GH PR
>>>>>>  (as to leave a audit trail, I guess)
>>>>>> .
>>>>>> Or
>>>>>> ,
>>>>>> at
>>>>>>  
>>>>>> least
>>>>>> ,
>>>>>> C* project 
>>>>>> leave
>>>>>> s
>>>>>> up to the contributor
>>>>>> s
>>>>>> to either open a GH PR or upload the patch file
>>>>>>  to JIRA. In fact, Github allows the access to a raw patch or
>> diff,
>>>> it's
>>>>>> just a matter of adding the ".patch" or ".diff" suffix to the end
>> of
>>>> the
>>>>>> Pull Request URL.
>>>>>> 
>>>>>> 
>>>>>> 
>>>>>> +1 about having a 'paper trail'
>>>>>>  of review comments
>>>>>> 
>>>>>> o
>>>>>> n JIRA and
>>>>>> /or
>>>>>> mailing list (I
>>>>>>  would
>>>>>> prefer the mailing list tbh). But as Michael and Flavio pointed
>> out,
>>> I
>>>>>> never seen
>>>>>> GH 
>>>>>> PR review
>>>>>> **
>>>>>> comments
>>>>>> **
>>>>>> being written back to JIRA, at least not in Kafka, Cassandra
>>>>>> or
>>>>>> Solr projects
>>>>>> , that I have followed more closely.
>>>>>> 
>>>>>> Eddie
>>>>>> 
>>>>>> 
>>>>>> On Tue, Oct 4, 2016 at 6:40 PM, Michael Han <ha...@cloudera.com>
>>> wrote:
>>>>>> 
>>>>>>>>> as long as the opening/closing/commenting all get sent to the
>>>> mailing
>>>>>>> list or recorded in jira
>>>>>>> Yeah, this is my impression as well, that we need to keep certain
>>>> paper
>>>>>>> trail regarding activities and comments on ASF side (JIRA or mail
>>>> list).
>>>>>>> Infra page said:
>>>>>>> 
>>>>>>>  - Any Pull Request that gets opened, closed, reopened or
>>>> **commented**
>>>>>>>  on now gets recorded on the project's mailing list
>>>>>>>  - If a project has a JIRA instance, any PRs or *comments* on PRs
>>>> that
>>>>>>>  include a JIRA ticket ID will trigger an update on that specific
>>>>> ticket
>>>>>>> 
>>>>>>> I checked a couple Kafka and Spark JIRAs but I don't see any of
>> the
>>>>>>> comments made in github PR were posted on JIRA, except the
>>> activities
>>>>> (open
>>>>>>> a PR, close a PR). Since both projects have been using github for
>> a
>>>>> while I
>>>>>>> assume such practice of NOT integrating comments between github
>> and
>>>> ASF
>>>>>>> JIRA is acceptable? Though I feel it would be really useful if
>>>> comments
>>>>>>> could converge in a single place as well, that will provide a
>> clear
>>>>> history
>>>>>>> for a given technical issue.
>>>>>>> 
>>>>>>> On Tue, Oct 4, 2016 at 12:06 PM, Flavio Junqueira <fpj@apache.org
>>> 
>>>>> wrote:
>>>>>>> 
>>>>>>>> Until ZOOKEEPER-2597 <https://issues.apache.org/
>>>>>>> jira/browse/ZOOKEEPER-2597>
>>>>>>>> is fixed, we can't merge via github.
>>>>>>>> 
>>>>>>>> For code reviews, we can use GH as long as the
>>>>> opening/closing/commenting
>>>>>>>> all get sent to the mailing list or recorded in jira. I don't
>> think
>>>> we
>>>>>>> have
>>>>>>>> that yet, but it is possible according to this:
>>>>>>>> 
>>>>>>>> https://blogs.apache.org/infra/entry/improved_
>>>>>>>> integration_between_apache_and <https://blogs.apache.org/
>>>>>>>> infra/entry/improved_integration_between_apache_and>
>>>>>>>> 
>>>>>>>> For now, we do need to upload patches and converge using jira.
>>>>>>>> 
>>>>>>>> I think Eddie has been looking at this process trying to
>> replicate
>>>> the
>>>>>>>> Kafka setup, so perhaps he can give an update if I'm right. Kafka
>>>>> doesn't
>>>>>>>> send every comment to the mailing list, though, but I'm not sure
>> if
>>>>>>> that's
>>>>>>>> acceptable according to the ASF, I need to double-check.
>>>>>>>> 
>>>>>>>> -Flavio
>>>>>>>> 
>>>>>>>>> On 04 Oct 2016, at 19:42, Michael Han <ha...@cloudera.com>
>> wrote:
>>>>>>>>> 
>>>>>>>>> Hi,
>>>>>>>>> 
>>>>>>>>> Now we've moved to git, what is the policy for uploading patches
>>> and
>>>>>>>> doing
>>>>>>>>> code reviews? I am asking because I've seen recently there are
>> git
>>>>> pull
>>>>>>>>> requests coming in without associated patch file uploaded to
>> JIRA.
>>>>> I've
>>>>>>>>> checked
>>>>>>>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
>>>> HowToContribute
>>>>> ,
>>>>>>>>> looks like there is not much change regarding patch process - so
>>>>>>>> presumably
>>>>>>>>> we still need to generate and upload patch file to JIRA for the
>>>>> record,
>>>>>>>>> while using github (maybe in addition of review board, or in the
>>>>> future
>>>>>>>>> with gerrit) to do code reviews?
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> On Wed, Sep 21, 2016 at 6:05 AM, Edward Ribeiro <
>>>>>>>> edward.ribeiro@gmail.com>
>>>>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> Cool, just open https://issues.apache.org/
>>>> jira/browse/ZOOKEEPER-2597
>>>>>>>>>> 
>>>>>>>>>> PS: I removed the REPO_HOME global variable.
>>>>>>>>>> 
>>>>>>>>>> On Wed, Sep 21, 2016 at 6:53 AM, Flavio Junqueira <
>>> fpj@apache.org>
>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>> Better to have that in the form of a pull request or diff.
>>>>>>>>>>> 
>>>>>>>>>>> REPO_HOME does seem to be unused.
>>>>>>>>>>> 
>>>>>>>>>>> -Flavio
>>>>>>>>>>> 
>>>>>>>>>>>> On 20 Sep 2016, at 18:57, Edward Ribeiro <
>>>> edward.ribeiro@gmail.com
>>>>>> 
>>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>> Hey, I have started porting the kafka-merge.py to work on ZK
>>>> repos.
>>>>>>> I
>>>>>>>>>>> would
>>>>>>>>>>>> need someone to review it and help me test it now.
>>>>>>>>>>>> 
>>>>>>>>>>>> The files were uploaded below, but I will create a github
>> repo
>>>> yet
>>>>>>>>>> today.
>>>>>>>>>>>> 
>>>>>>>>>>>> https://www.dropbox.com/sh/od8bet2574jttm3/
>>>>>>>>>>> AADv1DXTb8vfyVCmelFbYCEha?dl=0
>>>>>>>>>>>> 
>>>>>>>>>>>> I uploaded the kafka version script so that you can use diff
>> or
>>>>> Meld
>>>>>>>> to
>>>>>>>>>>>> spot my changes, but feel free to grasp the original file
>> here:
>>>>>>>>>>>> https://github.com/apache/kafka/blob/trunk/kafka-merge-pr.py
>>>>>>>>>>>> 
>>>>>>>>>>>> PS: It's just me or REPO_HOME env variable is not used
>> anywhere
>>>> in
>>>>>>> the
>>>>>>>>>>>> merge script???
>>>>>>>>>>>> 
>>>>>>>>>>>> Cheers,
>>>>>>>>>>>> Eddie
>>>>>>>>>>>> 
>>>>>>>>>>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick Hunt <
>>> phunt@apache.org
>>>>> 
>>>>>>>>>> wrote:
>>>>>>>>>>>> 
>>>>>>>>>>>>> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin Reed <
>>>> breed@apache.org>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> what you are suggesting sounds good, but i don't know how
>> to
>>> do
>>>>>>> it?
>>>>>>>>>>> since
>>>>>>>>>>>>>> in the end we are still just accepting diffs on patches,
>> the
>>>> only
>>>>>>>>>> thing
>>>>>>>>>>>>>> that changes is that we use svn rather than git right?
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> Notice the workflow Kafka uses - which includes "git apply"
>>> and
>>>>>>>>>>> specifying
>>>>>>>>>>>>> the author tag when committers commit (so that the OP gets
>>>> proper
>>>>>>>>>>>>> attribution in the commit itself)
>>>>>>>>>>>>> 
>>>>>>>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/
>>>>>>>>>>> Manual+Commit+Workflow
>>>>>>>>>>>>> 
>>>>>>>>>>>>> Patrick
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>>>>> i LOVE chris's idea! lets do it!
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> ben
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> On Sun, Sep 18, 2016 at 3:22 PM, Patrick Hunt <
>>>> phunt@apache.org>
>>>>>>>>>>> wrote:
>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Ben, do you also want to update the "Applying a patch"
>>> section
>>>>> to
>>>>>>>>>> make
>>>>>>>>>>>>> it
>>>>>>>>>>>>>>> git specific?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> We (committers) should move to a model where authors get
>>>> proper
>>>>>>>>>> credit
>>>>>>>>>>>>> in
>>>>>>>>>>>>>>> git. Our old workflow in svn resulted in only the
>> committer
>>>>> being
>>>>>>>>>>>>> listed
>>>>>>>>>>>>>>> (except that we listed the patch author in the commit
>>>> message).
>>>>>>> We
>>>>>>>>>>>>> should
>>>>>>>>>>>>>>> move to a model where the author of the patch gets proper
>>>> credit
>>>>>>> in
>>>>>>>>>>>>> git.
>>>>>>>>>>>>>> I
>>>>>>>>>>>>>>> believe we will get that if we use git for patch
>>>>>>>>>> creation/application?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Chris brought up getting rid of CHANGES.txt recently on
>> the
>>>> dev
>>>>>>>> list
>>>>>>>>>>>>> in a
>>>>>>>>>>>>>>> separate thread - Chris do you want to implement that
>> change
>>>> now
>>>>>>>>>> that
>>>>>>>>>>>>>> we've
>>>>>>>>>>>>>>> moved to git?
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> Patrick
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin Reed <
>>>>> breed@apache.org
>>>>>>>> 
>>>>>>>>>>>>> wrote:
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 1) actually in the previous step that was just adding
>> new
>>>>>>> files.
>>>>>>>>>> you
>>>>>>>>>>>>>>>>> still
>>>>>>>>>>>>>>>>>> need the commit -a for the rest of the changes. that's
>> my
>>>>>>> normal
>>>>>>>>>>>>>>>>> workflow.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> I think that will be confusing for most folks. They
>>>> typically
>>>>>>>>>> stage
>>>>>>>>>>>>>>>>> all the changes and then commit or don't stage and use
>> -a.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> do you mind fixing it with your workflow. commit -a
>> doesn't
>>>> get
>>>>>>>> new
>>>>>>>>>>>>>>>> files, which is why you need to do the add, but i'm not
>> the
>>>>> most
>>>>>>>>>>>>>>>> sophisticated git user, so
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>>> 2) i figured since we are using git now that we should
>>> use
>>>>>>> git's
>>>>>>>>>>>>>>>>> default.
>>>>>>>>>>>>>>>>>> the patch should work (by default it seems to strip the
>>>> first
>>>>>>>>>> path
>>>>>>>>>>>>>>>>> element).
>>>>>>>>>>>>>>>>>> does it not work for you?
>>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>>> It will fail precommit in it's current state.
>>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>>> fixed
>>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>>> 
>>>>>>>>>>>>>> 
>>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> --
>>>>>>>>> Cheers
>>>>>>>>> Michael.
>>>>>>>> 
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>>> --
>>>>>>> Cheers
>>>>>>> Michael.
>>>>>>> 
>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> --
>>>> Cheers
>>>> Michael.
>>>> 
>>> 
>>

Re: [VOTE] move Apache Zookeeper to git

Posted by Benjamin Reed <br...@apache.org>.

it doesn't look like we need to setup keys. this seems to work for me:

https://git-wip-us.apache.org/#committers-getting-started

it does seem strange that we aren't using public keys and that i'm sticking
a password in .netrc :P i'm wondering if other projects were able to get
this going over ssh.

i'll take a whack at cleaning up the svn and subversion references.

ben

On Fri, Oct 7, 2016 at 12:59 PM, Camille Fournier <ca...@apache.org>
wrote:

> Hey folks,
>
> So I'm trying to get in a patch but this has not been updated to tell
> committers how to actually get the git keys set up:
> https://cwiki.apache.org/confluence/display/ZOOKEEPER/Committing+changes
>
> Can someone float me a link that says how to do this?
>
> Also a bunch of our documentation still discusses SVN and not git, which
> means we are not done with this migration. If you were pushing for this
> change can you please do some due diligence on the wikis and correct the
> stuff that refers to SVN?
>
> Thanks,
> C
>
> On Wed, Oct 5, 2016 at 1:02 PM, Edward Ribeiro <ed...@gmail.com>
> wrote:
>
> > Excuse me guys!
> >
> > I've written on Macbook Pro. No idea why GMail messed it up. I was only
> > able to see the strange characters when I pasted on a gist text area. The
> > previous message is below, but if anyone is still having trouble (I tried
> > to remove the weird character), I left a copy at:
> > https://gist.github.com/eribeiro/da2a6a6c9a508610d52d0755fae8352d
> >
> > "Hi,
> >
> > The patch attached on ZOOKEEPER-2597 is a straightforward adaptation of
> > Kafka's one. It takes care of merging Github PR into Apache git repo and
> a
> > subsequent closing of the PR on the GH side, among other things
> (rewriting
> > of commit messages, etc). The current status is: the script needs to be
> > reviewed/validated by a committer. It has been some time since I uploaded
> > the patch, so I gonna do another pass through it in the meantime.
> >
> > There are some workflow issues beyond the scope of ZOOKEEPER-2597 that
> need
> > to be sorted out (IMO):
> >
> > 1. The normal workflow is to open a JIRA ticket before doing any GH PR,
> > that is, no JIRA-less PRs. The PR should have a title of the form
> > "ZOOKEEPER-xxxx: Title". This will trigger the Apache JIRA-Github
> > integration and it's opening show up in the JIRA ticket.
> >
> > 2. OTOH, not every Kafka PR needs a corresponding JIRA ticket. There are
> a
> > class of PRs with "MINOR" title that represent trivial code changes and
> > "HOT-FIX" title that fix urgent, but simple bugs. Both bypass the JIRA
> > creation step, even tough they are still subject to review. It's worth
> > adopting a similar approach for ZK project?
> >
> > 3. IIRC (didn't find any page to confirm), Cassandra project encourages,
> > but not demands, that contributors also upload a patch file to JIRA even
> in
> > the case of a GH PR (as to leave a audit trail, I guess). Or, at  least,
> C*
> > project leaves up to the contributors to either open a GH PR or upload
> the
> > patch file to JIRA.
> >
> >
> > +1 about having a 'paper trail' of review comments on JIRA and/or mailing
> > list (I would prefer the mailing list tbh). But as Michael and Flavio
> > pointed out, I never seen GH PR review **comments** being written back to
> > JIRA, at least not in Kafka, Cassandra or Solr projects, that I have
> > followed more closely.
> >
> > Eddie"
> >
> >
> > On Wed, Oct 5, 2016 at 1:35 PM, Michael Han <ha...@cloudera.com> wrote:
> >
> > > Eddie's mail contains lots of '=E2=80=8B'' which is unicode character
> > > zero-width space, which might cause parsing trouble for some mail
> > clients.
> > >
> > > On Wed, Oct 5, 2016 at 6:42 AM, Flavio Junqueira <fp...@apache.org>
> wrote:
> > >
> > > > Dude, I'm just not able to parse your e-mail, did you write that on a
> > > > phone or something?
> > > >
> > > > -Flavio
> > > >
> > > > > On 05 Oct 2016, at 03:54, Edward Ribeiro <edward.ribeiro@gmail.com
> >
> > > > wrote:
> > > > >
> > > > > Hi,
> > > > >
> > > > > The patch attached on ZOOKEEPER-2597 is a
> > > > > straightforward adaptation of
> > > > > Kafka's one. It takes care of merging Github PR into Apache git
> repo
> > > and
> > > > >  a
> > > > > subsequent closing of the PR on the GH side
> > > > >  among other things (rewriting of commit messages, etc)
> > > > > . The current status is: the script needs to be reviewed/validated
> > by a
> > > > > committer.
> > > > > It has been some time since I uploaded the patch, so I gonna do
> > > another
> > > > > pass through it in the meantime.
> > > > >
> > > > >
> > > > > T
> > > > > here are some workflow issues beyond the scope of ZOOKEEPER-2597
> > > > >  that need to be sorted out (IMO)
> > > > > :
> > > > >
> > > > > 1. The normal workflow is to open a JIRA ticket before doing any GH
> > PR
> > > > > , that is, no JIRA-less PRs.
> > > > > The PR should have a title of the form "ZOOKEEPER-xxxx: Title".
> This
> > > will
> > > > > trigger the Apache JIRA-Github integration and it's opening show up
> > in
> > > > the
> > > > > JIRA ticket.
> > > > >
> > > > > 2.
> > > > > OTOH, n
> > > > > ot every Kafka PR needs a corresponding JIRA ticket
> > > > > . 
> > > > > There are a class of PR
> > > > > s
> > > > > with "MINOR"
> > > > >  title
> > > > > that represent trivial code changes
> > > > >  and "HOT-FIX" title that fix urgent, but simple bugs. Both
> > > > > bypass the JIRA creation step
> > > > > , even tough they are still 
> > > > > subject to review
> > > > > .
> > > > > It's worth adopting a similar approach for ZK project?
> > > > >
> > > > > 3. IIRC
> > > > >  (didn't find any page to confirm)
> > > > > , Cassandra project encourages, but not demands, that contributors
> > also
> > > > > upload a patch file to JIRA even in the case of a GH PR
> > > > >  (as to leave a audit trail, I guess)
> > > > > .
> > > > > Or
> > > > > ,
> > > > > at
> > > > >  
> > > > > least
> > > > > ,
> > > > > C* project 
> > > > > leave
> > > > > s
> > > > > up to the contributor
> > > > > s
> > > > > to either open a GH PR or upload the patch file
> > > > >  to JIRA. In fact, Github allows the access to a raw patch or
> diff,
> > > it's
> > > > > just a matter of adding the ".patch" or ".diff" suffix to the end
> of
> > > the
> > > > > Pull Request URL.
> > > > > 
> > > > >
> > > > >
> > > > > +1 about having a 'paper trail'
> > > > >  of review comments
> > > > >
> > > > > o
> > > > > n JIRA and
> > > > > /or
> > > > > mailing list (I
> > > > >  would
> > > > > prefer the mailing list tbh). But as Michael and Flavio pointed
> out,
> > I
> > > > > never seen
> > > > > GH 
> > > > > PR review
> > > > > **
> > > > > comments
> > > > > **
> > > > > being written back to JIRA, at least not in Kafka, Cassandra
> > > > > or
> > > > > Solr projects
> > > > > , that I have followed more closely.
> > > > >
> > > > > Eddie
> > > > >
> > > > >
> > > > > On Tue, Oct 4, 2016 at 6:40 PM, Michael Han <ha...@cloudera.com>
> > wrote:
> > > > >
> > > > >>>> as long as the opening/closing/commenting all get sent to the
> > > mailing
> > > > >> list or recorded in jira
> > > > >> Yeah, this is my impression as well, that we need to keep certain
> > > paper
> > > > >> trail regarding activities and comments on ASF side (JIRA or mail
> > > list).
> > > > >> Infra page said:
> > > > >>
> > > > >>   - Any Pull Request that gets opened, closed, reopened or
> > > **commented**
> > > > >>   on now gets recorded on the project's mailing list
> > > > >>   - If a project has a JIRA instance, any PRs or *comments* on PRs
> > > that
> > > > >>   include a JIRA ticket ID will trigger an update on that specific
> > > > ticket
> > > > >>
> > > > >> I checked a couple Kafka and Spark JIRAs but I don't see any of
> the
> > > > >> comments made in github PR were posted on JIRA, except the
> > activities
> > > > (open
> > > > >> a PR, close a PR). Since both projects have been using github for
> a
> > > > while I
> > > > >> assume such practice of NOT integrating comments between github
> and
> > > ASF
> > > > >> JIRA is acceptable? Though I feel it would be really useful if
> > > comments
> > > > >> could converge in a single place as well, that will provide a
> clear
> > > > history
> > > > >> for a given technical issue.
> > > > >>
> > > > >> On Tue, Oct 4, 2016 at 12:06 PM, Flavio Junqueira <fpj@apache.org
> >
> > > > wrote:
> > > > >>
> > > > >>> Until ZOOKEEPER-2597 <https://issues.apache.org/
> > > > >> jira/browse/ZOOKEEPER-2597>
> > > > >>> is fixed, we can't merge via github.
> > > > >>>
> > > > >>> For code reviews, we can use GH as long as the
> > > > opening/closing/commenting
> > > > >>> all get sent to the mailing list or recorded in jira. I don't
> think
> > > we
> > > > >> have
> > > > >>> that yet, but it is possible according to this:
> > > > >>>
> > > > >>> https://blogs.apache.org/infra/entry/improved_
> > > > >>> integration_between_apache_and <https://blogs.apache.org/
> > > > >>> infra/entry/improved_integration_between_apache_and>
> > > > >>>
> > > > >>> For now, we do need to upload patches and converge using jira.
> > > > >>>
> > > > >>> I think Eddie has been looking at this process trying to
> replicate
> > > the
> > > > >>> Kafka setup, so perhaps he can give an update if I'm right. Kafka
> > > > doesn't
> > > > >>> send every comment to the mailing list, though, but I'm not sure
> if
> > > > >> that's
> > > > >>> acceptable according to the ASF, I need to double-check.
> > > > >>>
> > > > >>> -Flavio
> > > > >>>
> > > > >>>> On 04 Oct 2016, at 19:42, Michael Han <ha...@cloudera.com>
> wrote:
> > > > >>>>
> > > > >>>> Hi,
> > > > >>>>
> > > > >>>> Now we've moved to git, what is the policy for uploading patches
> > and
> > > > >>> doing
> > > > >>>> code reviews? I am asking because I've seen recently there are
> git
> > > > pull
> > > > >>>> requests coming in without associated patch file uploaded to
> JIRA.
> > > > I've
> > > > >>>> checked
> > > > >>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> > > HowToContribute
> > > > ,
> > > > >>>> looks like there is not much change regarding patch process - so
> > > > >>> presumably
> > > > >>>> we still need to generate and upload patch file to JIRA for the
> > > > record,
> > > > >>>> while using github (maybe in addition of review board, or in the
> > > > future
> > > > >>>> with gerrit) to do code reviews?
> > > > >>>>
> > > > >>>>
> > > > >>>> On Wed, Sep 21, 2016 at 6:05 AM, Edward Ribeiro <
> > > > >>> edward.ribeiro@gmail.com>
> > > > >>>> wrote:
> > > > >>>>
> > > > >>>>> Cool, just open https://issues.apache.org/
> > > jira/browse/ZOOKEEPER-2597
> > > > >>>>>
> > > > >>>>> PS: I removed the REPO_HOME global variable.
> > > > >>>>>
> > > > >>>>> On Wed, Sep 21, 2016 at 6:53 AM, Flavio Junqueira <
> > fpj@apache.org>
> > > > >>> wrote:
> > > > >>>>>
> > > > >>>>>> Better to have that in the form of a pull request or diff.
> > > > >>>>>>
> > > > >>>>>> REPO_HOME does seem to be unused.
> > > > >>>>>>
> > > > >>>>>> -Flavio
> > > > >>>>>>
> > > > >>>>>>> On 20 Sep 2016, at 18:57, Edward Ribeiro <
> > > edward.ribeiro@gmail.com
> > > > >
> > > > >>>>>> wrote:
> > > > >>>>>>>
> > > > >>>>>>> Hey, I have started porting the kafka-merge.py to work on ZK
> > > repos.
> > > > >> I
> > > > >>>>>> would
> > > > >>>>>>> need someone to review it and help me test it now.
> > > > >>>>>>>
> > > > >>>>>>> The files were uploaded below, but I will create a github
> repo
> > > yet
> > > > >>>>> today.
> > > > >>>>>>>
> > > > >>>>>>> https://www.dropbox.com/sh/od8bet2574jttm3/
> > > > >>>>>> AADv1DXTb8vfyVCmelFbYCEha?dl=0
> > > > >>>>>>>
> > > > >>>>>>> I uploaded the kafka version script so that you can use diff
> or
> > > > Meld
> > > > >>> to
> > > > >>>>>>> spot my changes, but feel free to grasp the original file
> here:
> > > > >>>>>>> https://github.com/apache/kafka/blob/trunk/kafka-merge-pr.py
> > > > >>>>>>>
> > > > >>>>>>> PS: It's just me or REPO_HOME env variable is not used
> anywhere
> > > in
> > > > >> the
> > > > >>>>>>> merge script???
> > > > >>>>>>>
> > > > >>>>>>> Cheers,
> > > > >>>>>>> Eddie
> > > > >>>>>>>
> > > > >>>>>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick Hunt <
> > phunt@apache.org
> > > >
> > > > >>>>> wrote:
> > > > >>>>>>>
> > > > >>>>>>>> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin Reed <
> > > breed@apache.org>
> > > > >>>>>> wrote:
> > > > >>>>>>>>
> > > > >>>>>>>>> what you are suggesting sounds good, but i don't know how
> to
> > do
> > > > >> it?
> > > > >>>>>> since
> > > > >>>>>>>>> in the end we are still just accepting diffs on patches,
> the
> > > only
> > > > >>>>> thing
> > > > >>>>>>>>> that changes is that we use svn rather than git right?
> > > > >>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>> Notice the workflow Kafka uses - which includes "git apply"
> > and
> > > > >>>>>> specifying
> > > > >>>>>>>> the author tag when committers commit (so that the OP gets
> > > proper
> > > > >>>>>>>> attribution in the commit itself)
> > > > >>>>>>>>
> > > > >>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/
> > > > >>>>>> Manual+Commit+Workflow
> > > > >>>>>>>>
> > > > >>>>>>>> Patrick
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>>>> i LOVE chris's idea! lets do it!
> > > > >>>>>>>>>
> > > > >>>>>>>>> ben
> > > > >>>>>>>>>
> > > > >>>>>>>>> On Sun, Sep 18, 2016 at 3:22 PM, Patrick Hunt <
> > > phunt@apache.org>
> > > > >>>>>> wrote:
> > > > >>>>>>>>>
> > > > >>>>>>>>>> Ben, do you also want to update the "Applying a patch"
> > section
> > > > to
> > > > >>>>> make
> > > > >>>>>>>> it
> > > > >>>>>>>>>> git specific?
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> We (committers) should move to a model where authors get
> > > proper
> > > > >>>>> credit
> > > > >>>>>>>> in
> > > > >>>>>>>>>> git. Our old workflow in svn resulted in only the
> committer
> > > > being
> > > > >>>>>>>> listed
> > > > >>>>>>>>>> (except that we listed the patch author in the commit
> > > message).
> > > > >> We
> > > > >>>>>>>> should
> > > > >>>>>>>>>> move to a model where the author of the patch gets proper
> > > credit
> > > > >> in
> > > > >>>>>>>> git.
> > > > >>>>>>>>> I
> > > > >>>>>>>>>> believe we will get that if we use git for patch
> > > > >>>>> creation/application?
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> Chris brought up getting rid of CHANGES.txt recently on
> the
> > > dev
> > > > >>> list
> > > > >>>>>>>> in a
> > > > >>>>>>>>>> separate thread - Chris do you want to implement that
> change
> > > now
> > > > >>>>> that
> > > > >>>>>>>>> we've
> > > > >>>>>>>>>> moved to git?
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> Patrick
> > > > >>>>>>>>>>
> > > > >>>>>>>>>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin Reed <
> > > > breed@apache.org
> > > > >>>
> > > > >>>>>>>> wrote:
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>>> 1) actually in the previous step that was just adding
> new
> > > > >> files.
> > > > >>>>> you
> > > > >>>>>>>>>>>> still
> > > > >>>>>>>>>>>>> need the commit -a for the rest of the changes. that's
> my
> > > > >> normal
> > > > >>>>>>>>>>>> workflow.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> I think that will be confusing for most folks. They
> > > typically
> > > > >>>>> stage
> > > > >>>>>>>>>>>> all the changes and then commit or don't stage and use
> -a.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> do you mind fixing it with your workflow. commit -a
> doesn't
> > > get
> > > > >>> new
> > > > >>>>>>>>>>> files, which is why you need to do the add, but i'm not
> the
> > > > most
> > > > >>>>>>>>>>> sophisticated git user, so
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>>> 2) i figured since we are using git now that we should
> > use
> > > > >> git's
> > > > >>>>>>>>>>>> default.
> > > > >>>>>>>>>>>>> the patch should work (by default it seems to strip the
> > > first
> > > > >>>>> path
> > > > >>>>>>>>>>>> element).
> > > > >>>>>>>>>>>>> does it not work for you?
> > > > >>>>>>>>>>>>>
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>> It will fail precommit in it's current state.
> > > > >>>>>>>>>>>>
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>> fixed
> > > > >>>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>>
> > > > >>>>>>>>>
> > > > >>>>>>>>
> > > > >>>>>>
> > > > >>>>>>
> > > > >>>>>
> > > > >>>>
> > > > >>>>
> > > > >>>>
> > > > >>>> --
> > > > >>>> Cheers
> > > > >>>> Michael.
> > > > >>>
> > > > >>>
> > > > >>
> > > > >>
> > > > >> --
> > > > >> Cheers
> > > > >> Michael.
> > > > >>
> > > >
> > > >
> > >
> > >
> > > --
> > > Cheers
> > > Michael.
> > >
> >
>

Re: [VOTE] move Apache Zookeeper to git

Posted by Camille Fournier <ca...@apache.org>.

Hey folks,

So I'm trying to get in a patch but this has not been updated to tell
committers how to actually get the git keys set up:
https://cwiki.apache.org/confluence/display/ZOOKEEPER/Committing+changes

Can someone float me a link that says how to do this?

Also a bunch of our documentation still discusses SVN and not git, which
means we are not done with this migration. If you were pushing for this
change can you please do some due diligence on the wikis and correct the
stuff that refers to SVN?

Thanks,
C

On Wed, Oct 5, 2016 at 1:02 PM, Edward Ribeiro <ed...@gmail.com>
wrote:

> Excuse me guys!
>
> I've written on Macbook Pro. No idea why GMail messed it up. I was only
> able to see the strange characters when I pasted on a gist text area. The
> previous message is below, but if anyone is still having trouble (I tried
> to remove the weird character), I left a copy at:
> https://gist.github.com/eribeiro/da2a6a6c9a508610d52d0755fae8352d
>
> "Hi,
>
> The patch attached on ZOOKEEPER-2597 is a straightforward adaptation of
> Kafka's one. It takes care of merging Github PR into Apache git repo and a
> subsequent closing of the PR on the GH side, among other things (rewriting
> of commit messages, etc). The current status is: the script needs to be
> reviewed/validated by a committer. It has been some time since I uploaded
> the patch, so I gonna do another pass through it in the meantime.
>
> There are some workflow issues beyond the scope of ZOOKEEPER-2597 that need
> to be sorted out (IMO):
>
> 1. The normal workflow is to open a JIRA ticket before doing any GH PR,
> that is, no JIRA-less PRs. The PR should have a title of the form
> "ZOOKEEPER-xxxx: Title". This will trigger the Apache JIRA-Github
> integration and it's opening show up in the JIRA ticket.
>
> 2. OTOH, not every Kafka PR needs a corresponding JIRA ticket. There are a
> class of PRs with "MINOR" title that represent trivial code changes and
> "HOT-FIX" title that fix urgent, but simple bugs. Both bypass the JIRA
> creation step, even tough they are still subject to review. It's worth
> adopting a similar approach for ZK project?
>
> 3. IIRC (didn't find any page to confirm), Cassandra project encourages,
> but not demands, that contributors also upload a patch file to JIRA even in
> the case of a GH PR (as to leave a audit trail, I guess). Or, at  least, C*
> project leaves up to the contributors to either open a GH PR or upload the
> patch file to JIRA.
>
>
> +1 about having a 'paper trail' of review comments on JIRA and/or mailing
> list (I would prefer the mailing list tbh). But as Michael and Flavio
> pointed out, I never seen GH PR review **comments** being written back to
> JIRA, at least not in Kafka, Cassandra or Solr projects, that I have
> followed more closely.
>
> Eddie"
>
>
> On Wed, Oct 5, 2016 at 1:35 PM, Michael Han <ha...@cloudera.com> wrote:
>
> > Eddie's mail contains lots of '=E2=80=8B'' which is unicode character
> > zero-width space, which might cause parsing trouble for some mail
> clients.
> >
> > On Wed, Oct 5, 2016 at 6:42 AM, Flavio Junqueira <fp...@apache.org> wrote:
> >
> > > Dude, I'm just not able to parse your e-mail, did you write that on a
> > > phone or something?
> > >
> > > -Flavio
> > >
> > > > On 05 Oct 2016, at 03:54, Edward Ribeiro <ed...@gmail.com>
> > > wrote:
> > > >
> > > > Hi,
> > > >
> > > > The patch attached on ZOOKEEPER-2597 is a
> > > > straightforward adaptation of
> > > > Kafka's one. It takes care of merging Github PR into Apache git repo
> > and
> > > >  a
> > > > subsequent closing of the PR on the GH side
> > > >  among other things (rewriting of commit messages, etc)
> > > > . The current status is: the script needs to be reviewed/validated
> by a
> > > > committer.
> > > > It has been some time since I uploaded the patch, so I gonna do
> > another
> > > > pass through it in the meantime.
> > > >
> > > >
> > > > T
> > > > here are some workflow issues beyond the scope of ZOOKEEPER-2597
> > > >  that need to be sorted out (IMO)
> > > > :
> > > >
> > > > 1. The normal workflow is to open a JIRA ticket before doing any GH
> PR
> > > > , that is, no JIRA-less PRs.
> > > > The PR should have a title of the form "ZOOKEEPER-xxxx: Title". This
> > will
> > > > trigger the Apache JIRA-Github integration and it's opening show up
> in
> > > the
> > > > JIRA ticket.
> > > >
> > > > 2.
> > > > OTOH, n
> > > > ot every Kafka PR needs a corresponding JIRA ticket
> > > > . 
> > > > There are a class of PR
> > > > s
> > > > with "MINOR"
> > > >  title
> > > > that represent trivial code changes
> > > >  and "HOT-FIX" title that fix urgent, but simple bugs. Both
> > > > bypass the JIRA creation step
> > > > , even tough they are still 
> > > > subject to review
> > > > .
> > > > It's worth adopting a similar approach for ZK project?
> > > >
> > > > 3. IIRC
> > > >  (didn't find any page to confirm)
> > > > , Cassandra project encourages, but not demands, that contributors
> also
> > > > upload a patch file to JIRA even in the case of a GH PR
> > > >  (as to leave a audit trail, I guess)
> > > > .
> > > > Or
> > > > ,
> > > > at
> > > >  
> > > > least
> > > > ,
> > > > C* project 
> > > > leave
> > > > s
> > > > up to the contributor
> > > > s
> > > > to either open a GH PR or upload the patch file
> > > >  to JIRA. In fact, Github allows the access to a raw patch or diff,
> > it's
> > > > just a matter of adding the ".patch" or ".diff" suffix to the end of
> > the
> > > > Pull Request URL.
> > > > 
> > > >
> > > >
> > > > +1 about having a 'paper trail'
> > > >  of review comments
> > > >
> > > > o
> > > > n JIRA and
> > > > /or
> > > > mailing list (I
> > > >  would
> > > > prefer the mailing list tbh). But as Michael and Flavio pointed out,
> I
> > > > never seen
> > > > GH 
> > > > PR review
> > > > **
> > > > comments
> > > > **
> > > > being written back to JIRA, at least not in Kafka, Cassandra
> > > > or
> > > > Solr projects
> > > > , that I have followed more closely.
> > > >
> > > > Eddie
> > > >
> > > >
> > > > On Tue, Oct 4, 2016 at 6:40 PM, Michael Han <ha...@cloudera.com>
> wrote:
> > > >
> > > >>>> as long as the opening/closing/commenting all get sent to the
> > mailing
> > > >> list or recorded in jira
> > > >> Yeah, this is my impression as well, that we need to keep certain
> > paper
> > > >> trail regarding activities and comments on ASF side (JIRA or mail
> > list).
> > > >> Infra page said:
> > > >>
> > > >>   - Any Pull Request that gets opened, closed, reopened or
> > **commented**
> > > >>   on now gets recorded on the project's mailing list
> > > >>   - If a project has a JIRA instance, any PRs or *comments* on PRs
> > that
> > > >>   include a JIRA ticket ID will trigger an update on that specific
> > > ticket
> > > >>
> > > >> I checked a couple Kafka and Spark JIRAs but I don't see any of the
> > > >> comments made in github PR were posted on JIRA, except the
> activities
> > > (open
> > > >> a PR, close a PR). Since both projects have been using github for a
> > > while I
> > > >> assume such practice of NOT integrating comments between github and
> > ASF
> > > >> JIRA is acceptable? Though I feel it would be really useful if
> > comments
> > > >> could converge in a single place as well, that will provide a clear
> > > history
> > > >> for a given technical issue.
> > > >>
> > > >> On Tue, Oct 4, 2016 at 12:06 PM, Flavio Junqueira <fp...@apache.org>
> > > wrote:
> > > >>
> > > >>> Until ZOOKEEPER-2597 <https://issues.apache.org/
> > > >> jira/browse/ZOOKEEPER-2597>
> > > >>> is fixed, we can't merge via github.
> > > >>>
> > > >>> For code reviews, we can use GH as long as the
> > > opening/closing/commenting
> > > >>> all get sent to the mailing list or recorded in jira. I don't think
> > we
> > > >> have
> > > >>> that yet, but it is possible according to this:
> > > >>>
> > > >>> https://blogs.apache.org/infra/entry/improved_
> > > >>> integration_between_apache_and <https://blogs.apache.org/
> > > >>> infra/entry/improved_integration_between_apache_and>
> > > >>>
> > > >>> For now, we do need to upload patches and converge using jira.
> > > >>>
> > > >>> I think Eddie has been looking at this process trying to replicate
> > the
> > > >>> Kafka setup, so perhaps he can give an update if I'm right. Kafka
> > > doesn't
> > > >>> send every comment to the mailing list, though, but I'm not sure if
> > > >> that's
> > > >>> acceptable according to the ASF, I need to double-check.
> > > >>>
> > > >>> -Flavio
> > > >>>
> > > >>>> On 04 Oct 2016, at 19:42, Michael Han <ha...@cloudera.com> wrote:
> > > >>>>
> > > >>>> Hi,
> > > >>>>
> > > >>>> Now we've moved to git, what is the policy for uploading patches
> and
> > > >>> doing
> > > >>>> code reviews? I am asking because I've seen recently there are git
> > > pull
> > > >>>> requests coming in without associated patch file uploaded to JIRA.
> > > I've
> > > >>>> checked
> > > >>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> > HowToContribute
> > > ,
> > > >>>> looks like there is not much change regarding patch process - so
> > > >>> presumably
> > > >>>> we still need to generate and upload patch file to JIRA for the
> > > record,
> > > >>>> while using github (maybe in addition of review board, or in the
> > > future
> > > >>>> with gerrit) to do code reviews?
> > > >>>>
> > > >>>>
> > > >>>> On Wed, Sep 21, 2016 at 6:05 AM, Edward Ribeiro <
> > > >>> edward.ribeiro@gmail.com>
> > > >>>> wrote:
> > > >>>>
> > > >>>>> Cool, just open https://issues.apache.org/
> > jira/browse/ZOOKEEPER-2597
> > > >>>>>
> > > >>>>> PS: I removed the REPO_HOME global variable.
> > > >>>>>
> > > >>>>> On Wed, Sep 21, 2016 at 6:53 AM, Flavio Junqueira <
> fpj@apache.org>
> > > >>> wrote:
> > > >>>>>
> > > >>>>>> Better to have that in the form of a pull request or diff.
> > > >>>>>>
> > > >>>>>> REPO_HOME does seem to be unused.
> > > >>>>>>
> > > >>>>>> -Flavio
> > > >>>>>>
> > > >>>>>>> On 20 Sep 2016, at 18:57, Edward Ribeiro <
> > edward.ribeiro@gmail.com
> > > >
> > > >>>>>> wrote:
> > > >>>>>>>
> > > >>>>>>> Hey, I have started porting the kafka-merge.py to work on ZK
> > repos.
> > > >> I
> > > >>>>>> would
> > > >>>>>>> need someone to review it and help me test it now.
> > > >>>>>>>
> > > >>>>>>> The files were uploaded below, but I will create a github repo
> > yet
> > > >>>>> today.
> > > >>>>>>>
> > > >>>>>>> https://www.dropbox.com/sh/od8bet2574jttm3/
> > > >>>>>> AADv1DXTb8vfyVCmelFbYCEha?dl=0
> > > >>>>>>>
> > > >>>>>>> I uploaded the kafka version script so that you can use diff or
> > > Meld
> > > >>> to
> > > >>>>>>> spot my changes, but feel free to grasp the original file here:
> > > >>>>>>> https://github.com/apache/kafka/blob/trunk/kafka-merge-pr.py
> > > >>>>>>>
> > > >>>>>>> PS: It's just me or REPO_HOME env variable is not used anywhere
> > in
> > > >> the
> > > >>>>>>> merge script???
> > > >>>>>>>
> > > >>>>>>> Cheers,
> > > >>>>>>> Eddie
> > > >>>>>>>
> > > >>>>>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick Hunt <
> phunt@apache.org
> > >
> > > >>>>> wrote:
> > > >>>>>>>
> > > >>>>>>>> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin Reed <
> > breed@apache.org>
> > > >>>>>> wrote:
> > > >>>>>>>>
> > > >>>>>>>>> what you are suggesting sounds good, but i don't know how to
> do
> > > >> it?
> > > >>>>>> since
> > > >>>>>>>>> in the end we are still just accepting diffs on patches, the
> > only
> > > >>>>> thing
> > > >>>>>>>>> that changes is that we use svn rather than git right?
> > > >>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>> Notice the workflow Kafka uses - which includes "git apply"
> and
> > > >>>>>> specifying
> > > >>>>>>>> the author tag when committers commit (so that the OP gets
> > proper
> > > >>>>>>>> attribution in the commit itself)
> > > >>>>>>>>
> > > >>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/
> > > >>>>>> Manual+Commit+Workflow
> > > >>>>>>>>
> > > >>>>>>>> Patrick
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>
> > > >>>>>>>>> i LOVE chris's idea! lets do it!
> > > >>>>>>>>>
> > > >>>>>>>>> ben
> > > >>>>>>>>>
> > > >>>>>>>>> On Sun, Sep 18, 2016 at 3:22 PM, Patrick Hunt <
> > phunt@apache.org>
> > > >>>>>> wrote:
> > > >>>>>>>>>
> > > >>>>>>>>>> Ben, do you also want to update the "Applying a patch"
> section
> > > to
> > > >>>>> make
> > > >>>>>>>> it
> > > >>>>>>>>>> git specific?
> > > >>>>>>>>>>
> > > >>>>>>>>>> We (committers) should move to a model where authors get
> > proper
> > > >>>>> credit
> > > >>>>>>>> in
> > > >>>>>>>>>> git. Our old workflow in svn resulted in only the committer
> > > being
> > > >>>>>>>> listed
> > > >>>>>>>>>> (except that we listed the patch author in the commit
> > message).
> > > >> We
> > > >>>>>>>> should
> > > >>>>>>>>>> move to a model where the author of the patch gets proper
> > credit
> > > >> in
> > > >>>>>>>> git.
> > > >>>>>>>>> I
> > > >>>>>>>>>> believe we will get that if we use git for patch
> > > >>>>> creation/application?
> > > >>>>>>>>>>
> > > >>>>>>>>>> Chris brought up getting rid of CHANGES.txt recently on the
> > dev
> > > >>> list
> > > >>>>>>>> in a
> > > >>>>>>>>>> separate thread - Chris do you want to implement that change
> > now
> > > >>>>> that
> > > >>>>>>>>> we've
> > > >>>>>>>>>> moved to git?
> > > >>>>>>>>>>
> > > >>>>>>>>>> Patrick
> > > >>>>>>>>>>
> > > >>>>>>>>>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin Reed <
> > > breed@apache.org
> > > >>>
> > > >>>>>>>> wrote:
> > > >>>>>>>>>>
> > > >>>>>>>>>>>> 1) actually in the previous step that was just adding new
> > > >> files.
> > > >>>>> you
> > > >>>>>>>>>>>> still
> > > >>>>>>>>>>>>> need the commit -a for the rest of the changes. that's my
> > > >> normal
> > > >>>>>>>>>>>> workflow.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> I think that will be confusing for most folks. They
> > typically
> > > >>>>> stage
> > > >>>>>>>>>>>> all the changes and then commit or don't stage and use -a.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> do you mind fixing it with your workflow. commit -a doesn't
> > get
> > > >>> new
> > > >>>>>>>>>>> files, which is why you need to do the add, but i'm not the
> > > most
> > > >>>>>>>>>>> sophisticated git user, so
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>>> 2) i figured since we are using git now that we should
> use
> > > >> git's
> > > >>>>>>>>>>>> default.
> > > >>>>>>>>>>>>> the patch should work (by default it seems to strip the
> > first
> > > >>>>> path
> > > >>>>>>>>>>>> element).
> > > >>>>>>>>>>>>> does it not work for you?
> > > >>>>>>>>>>>>>
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>> It will fail precommit in it's current state.
> > > >>>>>>>>>>>>
> > > >>>>>>>>>>>
> > > >>>>>>>>>>> fixed
> > > >>>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>>
> > > >>>>>>>>>
> > > >>>>>>>>
> > > >>>>>>
> > > >>>>>>
> > > >>>>>
> > > >>>>
> > > >>>>
> > > >>>>
> > > >>>> --
> > > >>>> Cheers
> > > >>>> Michael.
> > > >>>
> > > >>>
> > > >>
> > > >>
> > > >> --
> > > >> Cheers
> > > >> Michael.
> > > >>
> > >
> > >
> >
> >
> > --
> > Cheers
> > Michael.
> >
>

Re: [VOTE] move Apache Zookeeper to git

Posted by Edward Ribeiro <ed...@gmail.com>.

Excuse me guys!

I've written on Macbook Pro. No idea why GMail messed it up. I was only
able to see the strange characters when I pasted on a gist text area. The
previous message is below, but if anyone is still having trouble (I tried
to remove the weird character), I left a copy at:
https://gist.github.com/eribeiro/da2a6a6c9a508610d52d0755fae8352d

"Hi,

The patch attached on ZOOKEEPER-2597 is a straightforward adaptation of
Kafka's one. It takes care of merging Github PR into Apache git repo and a
subsequent closing of the PR on the GH side, among other things (rewriting
of commit messages, etc). The current status is: the script needs to be
reviewed/validated by a committer. It has been some time since I uploaded
the patch, so I gonna do another pass through it in the meantime.

There are some workflow issues beyond the scope of ZOOKEEPER-2597 that need
to be sorted out (IMO):

1. The normal workflow is to open a JIRA ticket before doing any GH PR,
that is, no JIRA-less PRs. The PR should have a title of the form
"ZOOKEEPER-xxxx: Title". This will trigger the Apache JIRA-Github
integration and it's opening show up in the JIRA ticket.

2. OTOH, not every Kafka PR needs a corresponding JIRA ticket. There are a
class of PRs with "MINOR" title that represent trivial code changes and
"HOT-FIX" title that fix urgent, but simple bugs. Both bypass the JIRA
creation step, even tough they are still subject to review. It's worth
adopting a similar approach for ZK project?

3. IIRC (didn't find any page to confirm), Cassandra project encourages,
but not demands, that contributors also upload a patch file to JIRA even in
the case of a GH PR (as to leave a audit trail, I guess). Or, at  least, C*
project leaves up to the contributors to either open a GH PR or upload the
patch file to JIRA.


+1 about having a 'paper trail' of review comments on JIRA and/or mailing
list (I would prefer the mailing list tbh). But as Michael and Flavio
pointed out, I never seen GH PR review **comments** being written back to
JIRA, at least not in Kafka, Cassandra or Solr projects, that I have
followed more closely.

Eddie"


On Wed, Oct 5, 2016 at 1:35 PM, Michael Han <ha...@cloudera.com> wrote:

> Eddie's mail contains lots of '=E2=80=8B'' which is unicode character
> zero-width space, which might cause parsing trouble for some mail clients.
>
> On Wed, Oct 5, 2016 at 6:42 AM, Flavio Junqueira <fp...@apache.org> wrote:
>
> > Dude, I'm just not able to parse your e-mail, did you write that on a
> > phone or something?
> >
> > -Flavio
> >
> > > On 05 Oct 2016, at 03:54, Edward Ribeiro <ed...@gmail.com>
> > wrote:
> > >
> > > Hi,
> > >
> > > The patch attached on ZOOKEEPER-2597 is a
> > > straightforward adaptation of
> > > Kafka's one. It takes care of merging Github PR into Apache git repo
> and
> > >  a
> > > subsequent closing of the PR on the GH side
> > >  among other things (rewriting of commit messages, etc)
> > > . The current status is: the script needs to be reviewed/validated by a
> > > committer.
> > > It has been some time since I uploaded the patch, so I gonna do
> another
> > > pass through it in the meantime.
> > >
> > >
> > > T
> > > here are some workflow issues beyond the scope of ZOOKEEPER-2597
> > >  that need to be sorted out (IMO)
> > > :
> > >
> > > 1. The normal workflow is to open a JIRA ticket before doing any GH PR
> > > , that is, no JIRA-less PRs.
> > > The PR should have a title of the form "ZOOKEEPER-xxxx: Title". This
> will
> > > trigger the Apache JIRA-Github integration and it's opening show up in
> > the
> > > JIRA ticket.
> > >
> > > 2.
> > > OTOH, n
> > > ot every Kafka PR needs a corresponding JIRA ticket
> > > . 
> > > There are a class of PR
> > > s
> > > with "MINOR"
> > >  title
> > > that represent trivial code changes
> > >  and "HOT-FIX" title that fix urgent, but simple bugs. Both
> > > bypass the JIRA creation step
> > > , even tough they are still 
> > > subject to review
> > > .
> > > It's worth adopting a similar approach for ZK project?
> > >
> > > 3. IIRC
> > >  (didn't find any page to confirm)
> > > , Cassandra project encourages, but not demands, that contributors also
> > > upload a patch file to JIRA even in the case of a GH PR
> > >  (as to leave a audit trail, I guess)
> > > .
> > > Or
> > > ,
> > > at
> > >  
> > > least
> > > ,
> > > C* project 
> > > leave
> > > s
> > > up to the contributor
> > > s
> > > to either open a GH PR or upload the patch file
> > >  to JIRA. In fact, Github allows the access to a raw patch or diff,
> it's
> > > just a matter of adding the ".patch" or ".diff" suffix to the end of
> the
> > > Pull Request URL.
> > > 
> > >
> > >
> > > +1 about having a 'paper trail'
> > >  of review comments
> > >
> > > o
> > > n JIRA and
> > > /or
> > > mailing list (I
> > >  would
> > > prefer the mailing list tbh). But as Michael and Flavio pointed out, I
> > > never seen
> > > GH 
> > > PR review
> > > **
> > > comments
> > > **
> > > being written back to JIRA, at least not in Kafka, Cassandra
> > > or
> > > Solr projects
> > > , that I have followed more closely.
> > >
> > > Eddie
> > >
> > >
> > > On Tue, Oct 4, 2016 at 6:40 PM, Michael Han <ha...@cloudera.com> wrote:
> > >
> > >>>> as long as the opening/closing/commenting all get sent to the
> mailing
> > >> list or recorded in jira
> > >> Yeah, this is my impression as well, that we need to keep certain
> paper
> > >> trail regarding activities and comments on ASF side (JIRA or mail
> list).
> > >> Infra page said:
> > >>
> > >>   - Any Pull Request that gets opened, closed, reopened or
> **commented**
> > >>   on now gets recorded on the project's mailing list
> > >>   - If a project has a JIRA instance, any PRs or *comments* on PRs
> that
> > >>   include a JIRA ticket ID will trigger an update on that specific
> > ticket
> > >>
> > >> I checked a couple Kafka and Spark JIRAs but I don't see any of the
> > >> comments made in github PR were posted on JIRA, except the activities
> > (open
> > >> a PR, close a PR). Since both projects have been using github for a
> > while I
> > >> assume such practice of NOT integrating comments between github and
> ASF
> > >> JIRA is acceptable? Though I feel it would be really useful if
> comments
> > >> could converge in a single place as well, that will provide a clear
> > history
> > >> for a given technical issue.
> > >>
> > >> On Tue, Oct 4, 2016 at 12:06 PM, Flavio Junqueira <fp...@apache.org>
> > wrote:
> > >>
> > >>> Until ZOOKEEPER-2597 <https://issues.apache.org/
> > >> jira/browse/ZOOKEEPER-2597>
> > >>> is fixed, we can't merge via github.
> > >>>
> > >>> For code reviews, we can use GH as long as the
> > opening/closing/commenting
> > >>> all get sent to the mailing list or recorded in jira. I don't think
> we
> > >> have
> > >>> that yet, but it is possible according to this:
> > >>>
> > >>> https://blogs.apache.org/infra/entry/improved_
> > >>> integration_between_apache_and <https://blogs.apache.org/
> > >>> infra/entry/improved_integration_between_apache_and>
> > >>>
> > >>> For now, we do need to upload patches and converge using jira.
> > >>>
> > >>> I think Eddie has been looking at this process trying to replicate
> the
> > >>> Kafka setup, so perhaps he can give an update if I'm right. Kafka
> > doesn't
> > >>> send every comment to the mailing list, though, but I'm not sure if
> > >> that's
> > >>> acceptable according to the ASF, I need to double-check.
> > >>>
> > >>> -Flavio
> > >>>
> > >>>> On 04 Oct 2016, at 19:42, Michael Han <ha...@cloudera.com> wrote:
> > >>>>
> > >>>> Hi,
> > >>>>
> > >>>> Now we've moved to git, what is the policy for uploading patches and
> > >>> doing
> > >>>> code reviews? I am asking because I've seen recently there are git
> > pull
> > >>>> requests coming in without associated patch file uploaded to JIRA.
> > I've
> > >>>> checked
> > >>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> HowToContribute
> > ,
> > >>>> looks like there is not much change regarding patch process - so
> > >>> presumably
> > >>>> we still need to generate and upload patch file to JIRA for the
> > record,
> > >>>> while using github (maybe in addition of review board, or in the
> > future
> > >>>> with gerrit) to do code reviews?
> > >>>>
> > >>>>
> > >>>> On Wed, Sep 21, 2016 at 6:05 AM, Edward Ribeiro <
> > >>> edward.ribeiro@gmail.com>
> > >>>> wrote:
> > >>>>
> > >>>>> Cool, just open https://issues.apache.org/
> jira/browse/ZOOKEEPER-2597
> > >>>>>
> > >>>>> PS: I removed the REPO_HOME global variable.
> > >>>>>
> > >>>>> On Wed, Sep 21, 2016 at 6:53 AM, Flavio Junqueira <fp...@apache.org>
> > >>> wrote:
> > >>>>>
> > >>>>>> Better to have that in the form of a pull request or diff.
> > >>>>>>
> > >>>>>> REPO_HOME does seem to be unused.
> > >>>>>>
> > >>>>>> -Flavio
> > >>>>>>
> > >>>>>>> On 20 Sep 2016, at 18:57, Edward Ribeiro <
> edward.ribeiro@gmail.com
> > >
> > >>>>>> wrote:
> > >>>>>>>
> > >>>>>>> Hey, I have started porting the kafka-merge.py to work on ZK
> repos.
> > >> I
> > >>>>>> would
> > >>>>>>> need someone to review it and help me test it now.
> > >>>>>>>
> > >>>>>>> The files were uploaded below, but I will create a github repo
> yet
> > >>>>> today.
> > >>>>>>>
> > >>>>>>> https://www.dropbox.com/sh/od8bet2574jttm3/
> > >>>>>> AADv1DXTb8vfyVCmelFbYCEha?dl=0
> > >>>>>>>
> > >>>>>>> I uploaded the kafka version script so that you can use diff or
> > Meld
> > >>> to
> > >>>>>>> spot my changes, but feel free to grasp the original file here:
> > >>>>>>> https://github.com/apache/kafka/blob/trunk/kafka-merge-pr.py
> > >>>>>>>
> > >>>>>>> PS: It's just me or REPO_HOME env variable is not used anywhere
> in
> > >> the
> > >>>>>>> merge script???
> > >>>>>>>
> > >>>>>>> Cheers,
> > >>>>>>> Eddie
> > >>>>>>>
> > >>>>>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick Hunt <phunt@apache.org
> >
> > >>>>> wrote:
> > >>>>>>>
> > >>>>>>>> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin Reed <
> breed@apache.org>
> > >>>>>> wrote:
> > >>>>>>>>
> > >>>>>>>>> what you are suggesting sounds good, but i don't know how to do
> > >> it?
> > >>>>>> since
> > >>>>>>>>> in the end we are still just accepting diffs on patches, the
> only
> > >>>>> thing
> > >>>>>>>>> that changes is that we use svn rather than git right?
> > >>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>> Notice the workflow Kafka uses - which includes "git apply" and
> > >>>>>> specifying
> > >>>>>>>> the author tag when committers commit (so that the OP gets
> proper
> > >>>>>>>> attribution in the commit itself)
> > >>>>>>>>
> > >>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/
> > >>>>>> Manual+Commit+Workflow
> > >>>>>>>>
> > >>>>>>>> Patrick
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>> i LOVE chris's idea! lets do it!
> > >>>>>>>>>
> > >>>>>>>>> ben
> > >>>>>>>>>
> > >>>>>>>>> On Sun, Sep 18, 2016 at 3:22 PM, Patrick Hunt <
> phunt@apache.org>
> > >>>>>> wrote:
> > >>>>>>>>>
> > >>>>>>>>>> Ben, do you also want to update the "Applying a patch" section
> > to
> > >>>>> make
> > >>>>>>>> it
> > >>>>>>>>>> git specific?
> > >>>>>>>>>>
> > >>>>>>>>>> We (committers) should move to a model where authors get
> proper
> > >>>>> credit
> > >>>>>>>> in
> > >>>>>>>>>> git. Our old workflow in svn resulted in only the committer
> > being
> > >>>>>>>> listed
> > >>>>>>>>>> (except that we listed the patch author in the commit
> message).
> > >> We
> > >>>>>>>> should
> > >>>>>>>>>> move to a model where the author of the patch gets proper
> credit
> > >> in
> > >>>>>>>> git.
> > >>>>>>>>> I
> > >>>>>>>>>> believe we will get that if we use git for patch
> > >>>>> creation/application?
> > >>>>>>>>>>
> > >>>>>>>>>> Chris brought up getting rid of CHANGES.txt recently on the
> dev
> > >>> list
> > >>>>>>>> in a
> > >>>>>>>>>> separate thread - Chris do you want to implement that change
> now
> > >>>>> that
> > >>>>>>>>> we've
> > >>>>>>>>>> moved to git?
> > >>>>>>>>>>
> > >>>>>>>>>> Patrick
> > >>>>>>>>>>
> > >>>>>>>>>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin Reed <
> > breed@apache.org
> > >>>
> > >>>>>>>> wrote:
> > >>>>>>>>>>
> > >>>>>>>>>>>> 1) actually in the previous step that was just adding new
> > >> files.
> > >>>>> you
> > >>>>>>>>>>>> still
> > >>>>>>>>>>>>> need the commit -a for the rest of the changes. that's my
> > >> normal
> > >>>>>>>>>>>> workflow.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> I think that will be confusing for most folks. They
> typically
> > >>>>> stage
> > >>>>>>>>>>>> all the changes and then commit or don't stage and use -a.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> do you mind fixing it with your workflow. commit -a doesn't
> get
> > >>> new
> > >>>>>>>>>>> files, which is why you need to do the add, but i'm not the
> > most
> > >>>>>>>>>>> sophisticated git user, so
> > >>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>>> 2) i figured since we are using git now that we should use
> > >> git's
> > >>>>>>>>>>>> default.
> > >>>>>>>>>>>>> the patch should work (by default it seems to strip the
> first
> > >>>>> path
> > >>>>>>>>>>>> element).
> > >>>>>>>>>>>>> does it not work for you?
> > >>>>>>>>>>>>>
> > >>>>>>>>>>>>
> > >>>>>>>>>>>> It will fail precommit in it's current state.
> > >>>>>>>>>>>>
> > >>>>>>>>>>>
> > >>>>>>>>>>> fixed
> > >>>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>
> > >>>>>>
> > >>>>>
> > >>>>
> > >>>>
> > >>>>
> > >>>> --
> > >>>> Cheers
> > >>>> Michael.
> > >>>
> > >>>
> > >>
> > >>
> > >> --
> > >> Cheers
> > >> Michael.
> > >>
> >
> >
>
>
> --
> Cheers
> Michael.
>

Re: [VOTE] move Apache Zookeeper to git

Posted by Michael Han <ha...@cloudera.com>.

Eddie's mail contains lots of '=E2=80=8B'' which is unicode character
zero-width space, which might cause parsing trouble for some mail clients.

On Wed, Oct 5, 2016 at 6:42 AM, Flavio Junqueira <fp...@apache.org> wrote:

> Dude, I'm just not able to parse your e-mail, did you write that on a
> phone or something?
>
> -Flavio
>
> > On 05 Oct 2016, at 03:54, Edward Ribeiro <ed...@gmail.com>
> wrote:
> >
> > Hi,
> >
> > The patch attached on ZOOKEEPER-2597 is a
> > straightforward adaptation of
> > Kafka's one. It takes care of merging Github PR into Apache git repo and
> >  a
> > subsequent closing of the PR on the GH side
> >  among other things (rewriting of commit messages, etc)
> > . The current status is: the script needs to be reviewed/validated by a
> > committer.
> > It has been some time since I uploaded the patch, so I gonna do another
> > pass through it in the meantime.
> >
> >
> > T
> > here are some workflow issues beyond the scope of ZOOKEEPER-2597
> >  that need to be sorted out (IMO)
> > :
> >
> > 1. The normal workflow is to open a JIRA ticket before doing any GH PR
> > , that is, no JIRA-less PRs.
> > The PR should have a title of the form "ZOOKEEPER-xxxx: Title". This will
> > trigger the Apache JIRA-Github integration and it's opening show up in
> the
> > JIRA ticket.
> >
> > 2.
> > OTOH, n
> > ot every Kafka PR needs a corresponding JIRA ticket
> > . 
> > There are a class of PR
> > s
> > with "MINOR"
> >  title
> > that represent trivial code changes
> >  and "HOT-FIX" title that fix urgent, but simple bugs. Both
> > bypass the JIRA creation step
> > , even tough they are still 
> > subject to review
> > .
> > It's worth adopting a similar approach for ZK project?
> >
> > 3. IIRC
> >  (didn't find any page to confirm)
> > , Cassandra project encourages, but not demands, that contributors also
> > upload a patch file to JIRA even in the case of a GH PR
> >  (as to leave a audit trail, I guess)
> > .
> > Or
> > ,
> > at
> >  
> > least
> > ,
> > C* project 
> > leave
> > s
> > up to the contributor
> > s
> > to either open a GH PR or upload the patch file
> >  to JIRA. In fact, Github allows the access to a raw patch or diff, it's
> > just a matter of adding the ".patch" or ".diff" suffix to the end of the
> > Pull Request URL.
> > 
> >
> >
> > +1 about having a 'paper trail'
> >  of review comments
> >
> > o
> > n JIRA and
> > /or
> > mailing list (I
> >  would
> > prefer the mailing list tbh). But as Michael and Flavio pointed out, I
> > never seen
> > GH 
> > PR review
> > **
> > comments
> > **
> > being written back to JIRA, at least not in Kafka, Cassandra
> > or
> > Solr projects
> > , that I have followed more closely.
> >
> > Eddie
> >
> >
> > On Tue, Oct 4, 2016 at 6:40 PM, Michael Han <ha...@cloudera.com> wrote:
> >
> >>>> as long as the opening/closing/commenting all get sent to the mailing
> >> list or recorded in jira
> >> Yeah, this is my impression as well, that we need to keep certain paper
> >> trail regarding activities and comments on ASF side (JIRA or mail list).
> >> Infra page said:
> >>
> >>   - Any Pull Request that gets opened, closed, reopened or **commented**
> >>   on now gets recorded on the project's mailing list
> >>   - If a project has a JIRA instance, any PRs or *comments* on PRs that
> >>   include a JIRA ticket ID will trigger an update on that specific
> ticket
> >>
> >> I checked a couple Kafka and Spark JIRAs but I don't see any of the
> >> comments made in github PR were posted on JIRA, except the activities
> (open
> >> a PR, close a PR). Since both projects have been using github for a
> while I
> >> assume such practice of NOT integrating comments between github and ASF
> >> JIRA is acceptable? Though I feel it would be really useful if comments
> >> could converge in a single place as well, that will provide a clear
> history
> >> for a given technical issue.
> >>
> >> On Tue, Oct 4, 2016 at 12:06 PM, Flavio Junqueira <fp...@apache.org>
> wrote:
> >>
> >>> Until ZOOKEEPER-2597 <https://issues.apache.org/
> >> jira/browse/ZOOKEEPER-2597>
> >>> is fixed, we can't merge via github.
> >>>
> >>> For code reviews, we can use GH as long as the
> opening/closing/commenting
> >>> all get sent to the mailing list or recorded in jira. I don't think we
> >> have
> >>> that yet, but it is possible according to this:
> >>>
> >>> https://blogs.apache.org/infra/entry/improved_
> >>> integration_between_apache_and <https://blogs.apache.org/
> >>> infra/entry/improved_integration_between_apache_and>
> >>>
> >>> For now, we do need to upload patches and converge using jira.
> >>>
> >>> I think Eddie has been looking at this process trying to replicate the
> >>> Kafka setup, so perhaps he can give an update if I'm right. Kafka
> doesn't
> >>> send every comment to the mailing list, though, but I'm not sure if
> >> that's
> >>> acceptable according to the ASF, I need to double-check.
> >>>
> >>> -Flavio
> >>>
> >>>> On 04 Oct 2016, at 19:42, Michael Han <ha...@cloudera.com> wrote:
> >>>>
> >>>> Hi,
> >>>>
> >>>> Now we've moved to git, what is the policy for uploading patches and
> >>> doing
> >>>> code reviews? I am asking because I've seen recently there are git
> pull
> >>>> requests coming in without associated patch file uploaded to JIRA.
> I've
> >>>> checked
> >>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute
> ,
> >>>> looks like there is not much change regarding patch process - so
> >>> presumably
> >>>> we still need to generate and upload patch file to JIRA for the
> record,
> >>>> while using github (maybe in addition of review board, or in the
> future
> >>>> with gerrit) to do code reviews?
> >>>>
> >>>>
> >>>> On Wed, Sep 21, 2016 at 6:05 AM, Edward Ribeiro <
> >>> edward.ribeiro@gmail.com>
> >>>> wrote:
> >>>>
> >>>>> Cool, just open https://issues.apache.org/jira/browse/ZOOKEEPER-2597
> >>>>>
> >>>>> PS: I removed the REPO_HOME global variable.
> >>>>>
> >>>>> On Wed, Sep 21, 2016 at 6:53 AM, Flavio Junqueira <fp...@apache.org>
> >>> wrote:
> >>>>>
> >>>>>> Better to have that in the form of a pull request or diff.
> >>>>>>
> >>>>>> REPO_HOME does seem to be unused.
> >>>>>>
> >>>>>> -Flavio
> >>>>>>
> >>>>>>> On 20 Sep 2016, at 18:57, Edward Ribeiro <edward.ribeiro@gmail.com
> >
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> Hey, I have started porting the kafka-merge.py to work on ZK repos.
> >> I
> >>>>>> would
> >>>>>>> need someone to review it and help me test it now.
> >>>>>>>
> >>>>>>> The files were uploaded below, but I will create a github repo yet
> >>>>> today.
> >>>>>>>
> >>>>>>> https://www.dropbox.com/sh/od8bet2574jttm3/
> >>>>>> AADv1DXTb8vfyVCmelFbYCEha?dl=0
> >>>>>>>
> >>>>>>> I uploaded the kafka version script so that you can use diff or
> Meld
> >>> to
> >>>>>>> spot my changes, but feel free to grasp the original file here:
> >>>>>>> https://github.com/apache/kafka/blob/trunk/kafka-merge-pr.py
> >>>>>>>
> >>>>>>> PS: It's just me or REPO_HOME env variable is not used anywhere in
> >> the
> >>>>>>> merge script???
> >>>>>>>
> >>>>>>> Cheers,
> >>>>>>> Eddie
> >>>>>>>
> >>>>>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick Hunt <ph...@apache.org>
> >>>>> wrote:
> >>>>>>>
> >>>>>>>> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin Reed <br...@apache.org>
> >>>>>> wrote:
> >>>>>>>>
> >>>>>>>>> what you are suggesting sounds good, but i don't know how to do
> >> it?
> >>>>>> since
> >>>>>>>>> in the end we are still just accepting diffs on patches, the only
> >>>>> thing
> >>>>>>>>> that changes is that we use svn rather than git right?
> >>>>>>>>>
> >>>>>>>>>
> >>>>>>>> Notice the workflow Kafka uses - which includes "git apply" and
> >>>>>> specifying
> >>>>>>>> the author tag when committers commit (so that the OP gets proper
> >>>>>>>> attribution in the commit itself)
> >>>>>>>>
> >>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/
> >>>>>> Manual+Commit+Workflow
> >>>>>>>>
> >>>>>>>> Patrick
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>> i LOVE chris's idea! lets do it!
> >>>>>>>>>
> >>>>>>>>> ben
> >>>>>>>>>
> >>>>>>>>> On Sun, Sep 18, 2016 at 3:22 PM, Patrick Hunt <ph...@apache.org>
> >>>>>> wrote:
> >>>>>>>>>
> >>>>>>>>>> Ben, do you also want to update the "Applying a patch" section
> to
> >>>>> make
> >>>>>>>> it
> >>>>>>>>>> git specific?
> >>>>>>>>>>
> >>>>>>>>>> We (committers) should move to a model where authors get proper
> >>>>> credit
> >>>>>>>> in
> >>>>>>>>>> git. Our old workflow in svn resulted in only the committer
> being
> >>>>>>>> listed
> >>>>>>>>>> (except that we listed the patch author in the commit message).
> >> We
> >>>>>>>> should
> >>>>>>>>>> move to a model where the author of the patch gets proper credit
> >> in
> >>>>>>>> git.
> >>>>>>>>> I
> >>>>>>>>>> believe we will get that if we use git for patch
> >>>>> creation/application?
> >>>>>>>>>>
> >>>>>>>>>> Chris brought up getting rid of CHANGES.txt recently on the dev
> >>> list
> >>>>>>>> in a
> >>>>>>>>>> separate thread - Chris do you want to implement that change now
> >>>>> that
> >>>>>>>>> we've
> >>>>>>>>>> moved to git?
> >>>>>>>>>>
> >>>>>>>>>> Patrick
> >>>>>>>>>>
> >>>>>>>>>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin Reed <
> breed@apache.org
> >>>
> >>>>>>>> wrote:
> >>>>>>>>>>
> >>>>>>>>>>>> 1) actually in the previous step that was just adding new
> >> files.
> >>>>> you
> >>>>>>>>>>>> still
> >>>>>>>>>>>>> need the commit -a for the rest of the changes. that's my
> >> normal
> >>>>>>>>>>>> workflow.
> >>>>>>>>>>>>
> >>>>>>>>>>>> I think that will be confusing for most folks. They typically
> >>>>> stage
> >>>>>>>>>>>> all the changes and then commit or don't stage and use -a.
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> do you mind fixing it with your workflow. commit -a doesn't get
> >>> new
> >>>>>>>>>>> files, which is why you need to do the add, but i'm not the
> most
> >>>>>>>>>>> sophisticated git user, so
> >>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>>> 2) i figured since we are using git now that we should use
> >> git's
> >>>>>>>>>>>> default.
> >>>>>>>>>>>>> the patch should work (by default it seems to strip the first
> >>>>> path
> >>>>>>>>>>>> element).
> >>>>>>>>>>>>> does it not work for you?
> >>>>>>>>>>>>>
> >>>>>>>>>>>>
> >>>>>>>>>>>> It will fail precommit in it's current state.
> >>>>>>>>>>>>
> >>>>>>>>>>>
> >>>>>>>>>>> fixed
> >>>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>
> >>>>>>
> >>>>>>
> >>>>>
> >>>>
> >>>>
> >>>>
> >>>> --
> >>>> Cheers
> >>>> Michael.
> >>>
> >>>
> >>
> >>
> >> --
> >> Cheers
> >> Michael.
> >>
>
>


-- 
Cheers
Michael.

Re: [VOTE] move Apache Zookeeper to git

Posted by Flavio Junqueira <fp...@apache.org>.

Dude, I'm just not able to parse your e-mail, did you write that on a phone or something?

-Flavio

> On 05 Oct 2016, at 03:54, Edward Ribeiro <ed...@gmail.com> wrote:
> 
> Hi,
> 
> The patch attached on ZOOKEEPER-2597 is a
> straightforward adaptation of
> Kafka's one. It takes care of merging Github PR into Apache git repo and
>  a
> subsequent closing of the PR on the GH side
>  among other things (rewriting of commit messages, etc)
> . The current status is: the script needs to be reviewed/validated by a
> committer.
> It has been some time since I uploaded the patch, so I gonna do another
> pass through it in the meantime.
> 
> 
> T
> here are some workflow issues beyond the scope of ZOOKEEPER-2597
>  that need to be sorted out (IMO)
> :
> 
> 1. The normal workflow is to open a JIRA ticket before doing any GH PR
> , that is, no JIRA-less PRs.
> The PR should have a title of the form "ZOOKEEPER-xxxx: Title". This will
> trigger the Apache JIRA-Github integration and it's opening show up in the
> JIRA ticket.
> 
> 2.
> OTOH, n
> ot every Kafka PR needs a corresponding JIRA ticket
> . 
> There are a class of PR
> s
> with "MINOR"
>  title
> that represent trivial code changes
>  and "HOT-FIX" title that fix urgent, but simple bugs. Both
> bypass the JIRA creation step
> , even tough they are still 
> subject to review
> .
> It's worth adopting a similar approach for ZK project?
> 
> 3. IIRC
>  (didn't find any page to confirm)
> , Cassandra project encourages, but not demands, that contributors also
> upload a patch file to JIRA even in the case of a GH PR
>  (as to leave a audit trail, I guess)
> .
> Or
> ,
> at
>  
> least
> ,
> C* project 
> leave
> s
> up to the contributor
> s
> to either open a GH PR or upload the patch file
>  to JIRA. In fact, Github allows the access to a raw patch or diff, it's
> just a matter of adding the ".patch" or ".diff" suffix to the end of the
> Pull Request URL.
> 
> 
> 
> +1 about having a 'paper trail'
>  of review comments
> 
> o
> n JIRA and
> /or
> mailing list (I
>  would
> prefer the mailing list tbh). But as Michael and Flavio pointed out, I
> never seen
> GH 
> PR review
> **
> comments
> **
> being written back to JIRA, at least not in Kafka, Cassandra
> or
> Solr projects
> , that I have followed more closely.
> 
> Eddie
> 
> 
> On Tue, Oct 4, 2016 at 6:40 PM, Michael Han <ha...@cloudera.com> wrote:
> 
>>>> as long as the opening/closing/commenting all get sent to the mailing
>> list or recorded in jira
>> Yeah, this is my impression as well, that we need to keep certain paper
>> trail regarding activities and comments on ASF side (JIRA or mail list).
>> Infra page said:
>> 
>>   - Any Pull Request that gets opened, closed, reopened or **commented**
>>   on now gets recorded on the project's mailing list
>>   - If a project has a JIRA instance, any PRs or *comments* on PRs that
>>   include a JIRA ticket ID will trigger an update on that specific ticket
>> 
>> I checked a couple Kafka and Spark JIRAs but I don't see any of the
>> comments made in github PR were posted on JIRA, except the activities (open
>> a PR, close a PR). Since both projects have been using github for a while I
>> assume such practice of NOT integrating comments between github and ASF
>> JIRA is acceptable? Though I feel it would be really useful if comments
>> could converge in a single place as well, that will provide a clear history
>> for a given technical issue.
>> 
>> On Tue, Oct 4, 2016 at 12:06 PM, Flavio Junqueira <fp...@apache.org> wrote:
>> 
>>> Until ZOOKEEPER-2597 <https://issues.apache.org/
>> jira/browse/ZOOKEEPER-2597>
>>> is fixed, we can't merge via github.
>>> 
>>> For code reviews, we can use GH as long as the opening/closing/commenting
>>> all get sent to the mailing list or recorded in jira. I don't think we
>> have
>>> that yet, but it is possible according to this:
>>> 
>>> https://blogs.apache.org/infra/entry/improved_
>>> integration_between_apache_and <https://blogs.apache.org/
>>> infra/entry/improved_integration_between_apache_and>
>>> 
>>> For now, we do need to upload patches and converge using jira.
>>> 
>>> I think Eddie has been looking at this process trying to replicate the
>>> Kafka setup, so perhaps he can give an update if I'm right. Kafka doesn't
>>> send every comment to the mailing list, though, but I'm not sure if
>> that's
>>> acceptable according to the ASF, I need to double-check.
>>> 
>>> -Flavio
>>> 
>>>> On 04 Oct 2016, at 19:42, Michael Han <ha...@cloudera.com> wrote:
>>>> 
>>>> Hi,
>>>> 
>>>> Now we've moved to git, what is the policy for uploading patches and
>>> doing
>>>> code reviews? I am asking because I've seen recently there are git pull
>>>> requests coming in without associated patch file uploaded to JIRA. I've
>>>> checked
>>>> https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute,
>>>> looks like there is not much change regarding patch process - so
>>> presumably
>>>> we still need to generate and upload patch file to JIRA for the record,
>>>> while using github (maybe in addition of review board, or in the future
>>>> with gerrit) to do code reviews?
>>>> 
>>>> 
>>>> On Wed, Sep 21, 2016 at 6:05 AM, Edward Ribeiro <
>>> edward.ribeiro@gmail.com>
>>>> wrote:
>>>> 
>>>>> Cool, just open https://issues.apache.org/jira/browse/ZOOKEEPER-2597
>>>>> 
>>>>> PS: I removed the REPO_HOME global variable.
>>>>> 
>>>>> On Wed, Sep 21, 2016 at 6:53 AM, Flavio Junqueira <fp...@apache.org>
>>> wrote:
>>>>> 
>>>>>> Better to have that in the form of a pull request or diff.
>>>>>> 
>>>>>> REPO_HOME does seem to be unused.
>>>>>> 
>>>>>> -Flavio
>>>>>> 
>>>>>>> On 20 Sep 2016, at 18:57, Edward Ribeiro <ed...@gmail.com>
>>>>>> wrote:
>>>>>>> 
>>>>>>> Hey, I have started porting the kafka-merge.py to work on ZK repos.
>> I
>>>>>> would
>>>>>>> need someone to review it and help me test it now.
>>>>>>> 
>>>>>>> The files were uploaded below, but I will create a github repo yet
>>>>> today.
>>>>>>> 
>>>>>>> https://www.dropbox.com/sh/od8bet2574jttm3/
>>>>>> AADv1DXTb8vfyVCmelFbYCEha?dl=0
>>>>>>> 
>>>>>>> I uploaded the kafka version script so that you can use diff or Meld
>>> to
>>>>>>> spot my changes, but feel free to grasp the original file here:
>>>>>>> https://github.com/apache/kafka/blob/trunk/kafka-merge-pr.py
>>>>>>> 
>>>>>>> PS: It's just me or REPO_HOME env variable is not used anywhere in
>> the
>>>>>>> merge script???
>>>>>>> 
>>>>>>> Cheers,
>>>>>>> Eddie
>>>>>>> 
>>>>>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick Hunt <ph...@apache.org>
>>>>> wrote:
>>>>>>> 
>>>>>>>> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin Reed <br...@apache.org>
>>>>>> wrote:
>>>>>>>> 
>>>>>>>>> what you are suggesting sounds good, but i don't know how to do
>> it?
>>>>>> since
>>>>>>>>> in the end we are still just accepting diffs on patches, the only
>>>>> thing
>>>>>>>>> that changes is that we use svn rather than git right?
>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> Notice the workflow Kafka uses - which includes "git apply" and
>>>>>> specifying
>>>>>>>> the author tag when committers commit (so that the OP gets proper
>>>>>>>> attribution in the commit itself)
>>>>>>>> 
>>>>>>>> https://cwiki.apache.org/confluence/display/KAFKA/
>>>>>> Manual+Commit+Workflow
>>>>>>>> 
>>>>>>>> Patrick
>>>>>>>> 
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> i LOVE chris's idea! lets do it!
>>>>>>>>> 
>>>>>>>>> ben
>>>>>>>>> 
>>>>>>>>> On Sun, Sep 18, 2016 at 3:22 PM, Patrick Hunt <ph...@apache.org>
>>>>>> wrote:
>>>>>>>>> 
>>>>>>>>>> Ben, do you also want to update the "Applying a patch" section to
>>>>> make
>>>>>>>> it
>>>>>>>>>> git specific?
>>>>>>>>>> 
>>>>>>>>>> We (committers) should move to a model where authors get proper
>>>>> credit
>>>>>>>> in
>>>>>>>>>> git. Our old workflow in svn resulted in only the committer being
>>>>>>>> listed
>>>>>>>>>> (except that we listed the patch author in the commit message).
>> We
>>>>>>>> should
>>>>>>>>>> move to a model where the author of the patch gets proper credit
>> in
>>>>>>>> git.
>>>>>>>>> I
>>>>>>>>>> believe we will get that if we use git for patch
>>>>> creation/application?
>>>>>>>>>> 
>>>>>>>>>> Chris brought up getting rid of CHANGES.txt recently on the dev
>>> list
>>>>>>>> in a
>>>>>>>>>> separate thread - Chris do you want to implement that change now
>>>>> that
>>>>>>>>> we've
>>>>>>>>>> moved to git?
>>>>>>>>>> 
>>>>>>>>>> Patrick
>>>>>>>>>> 
>>>>>>>>>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin Reed <breed@apache.org
>>> 
>>>>>>>> wrote:
>>>>>>>>>> 
>>>>>>>>>>>> 1) actually in the previous step that was just adding new
>> files.
>>>>> you
>>>>>>>>>>>> still
>>>>>>>>>>>>> need the commit -a for the rest of the changes. that's my
>> normal
>>>>>>>>>>>> workflow.
>>>>>>>>>>>> 
>>>>>>>>>>>> I think that will be confusing for most folks. They typically
>>>>> stage
>>>>>>>>>>>> all the changes and then commit or don't stage and use -a.
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> do you mind fixing it with your workflow. commit -a doesn't get
>>> new
>>>>>>>>>>> files, which is why you need to do the add, but i'm not the most
>>>>>>>>>>> sophisticated git user, so
>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>>> 2) i figured since we are using git now that we should use
>> git's
>>>>>>>>>>>> default.
>>>>>>>>>>>>> the patch should work (by default it seems to strip the first
>>>>> path
>>>>>>>>>>>> element).
>>>>>>>>>>>>> does it not work for you?
>>>>>>>>>>>>> 
>>>>>>>>>>>> 
>>>>>>>>>>>> It will fail precommit in it's current state.
>>>>>>>>>>>> 
>>>>>>>>>>> 
>>>>>>>>>>> fixed
>>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>> 
>>>>>> 
>>>>>> 
>>>>> 
>>>> 
>>>> 
>>>> 
>>>> --
>>>> Cheers
>>>> Michael.
>>> 
>>> 
>> 
>> 
>> --
>> Cheers
>> Michael.
>>

Re: [VOTE] move Apache Zookeeper to git

Posted by Edward Ribeiro <ed...@gmail.com>.

Hi,

The patch attached on ZOOKEEPER-2597 is a
straightforward adaptation of
 Kafka's one. It takes care of merging Github PR into Apache git repo and
 a
subsequent closing of the PR on the GH side
 among other things (rewriting of commit messages, etc)
. The current status is: the script needs to be reviewed/validated by a
committer.
It has been some time since I uploaded the patch, so I gonna do another
pass through it in the meantime.


T
here are some workflow issues beyond the scope of ZOOKEEPER-2597
 that need to be sorted out (IMO)
:

1. The normal workflow is to open a JIRA ticket before doing any GH PR
, that is, no JIRA-less PRs.
The PR should have a title of the form "ZOOKEEPER-xxxx: Title". This will
trigger the Apache JIRA-Github integration and it's opening show up in the
JIRA ticket.

2.
OTOH, n
ot every Kafka PR needs a corresponding JIRA ticket
. 
There are a class of PR
s
with "MINOR"
 title
that represent trivial code changes
 and "HOT-FIX" title that fix urgent, but simple bugs. Both
 bypass the JIRA creation step
, even tough they are still 
subject to review
.
It's worth adopting a similar approach for ZK project?

3. IIRC
 (didn't find any page to confirm)
, Cassandra project encourages, but not demands, that contributors also
upload a patch file to JIRA even in the case of a GH PR
 (as to leave a audit trail, I guess)
.
Or
,
at
 
least
,
C* project 
leave
s
 up to the contributor
s
to either open a GH PR or upload the patch file
 to JIRA. In fact, Github allows the access to a raw patch or diff, it's
just a matter of adding the ".patch" or ".diff" suffix to the end of the
Pull Request URL.



+1 about having a 'paper trail'
 of review comments

o
n JIRA and
/or
mailing list (I
 would
prefer the mailing list tbh). But as Michael and Flavio pointed out, I
never seen
GH 
PR review
**
comments
**
being written back to JIRA, at least not in Kafka, Cassandra
or
 Solr projects
, that I have followed more closely.

Eddie


On Tue, Oct 4, 2016 at 6:40 PM, Michael Han <ha...@cloudera.com> wrote:

> >> as long as the opening/closing/commenting all get sent to the mailing
> list or recorded in jira
> Yeah, this is my impression as well, that we need to keep certain paper
> trail regarding activities and comments on ASF side (JIRA or mail list).
> Infra page said:
>
>    - Any Pull Request that gets opened, closed, reopened or **commented**
>    on now gets recorded on the project's mailing list
>    - If a project has a JIRA instance, any PRs or *comments* on PRs that
>    include a JIRA ticket ID will trigger an update on that specific ticket
>
> I checked a couple Kafka and Spark JIRAs but I don't see any of the
> comments made in github PR were posted on JIRA, except the activities (open
> a PR, close a PR). Since both projects have been using github for a while I
> assume such practice of NOT integrating comments between github and ASF
> JIRA is acceptable? Though I feel it would be really useful if comments
> could converge in a single place as well, that will provide a clear history
> for a given technical issue.
>
> On Tue, Oct 4, 2016 at 12:06 PM, Flavio Junqueira <fp...@apache.org> wrote:
>
> > Until ZOOKEEPER-2597 <https://issues.apache.org/
> jira/browse/ZOOKEEPER-2597>
> > is fixed, we can't merge via github.
> >
> > For code reviews, we can use GH as long as the opening/closing/commenting
> > all get sent to the mailing list or recorded in jira. I don't think we
> have
> > that yet, but it is possible according to this:
> >
> > https://blogs.apache.org/infra/entry/improved_
> > integration_between_apache_and <https://blogs.apache.org/
> > infra/entry/improved_integration_between_apache_and>
> >
> > For now, we do need to upload patches and converge using jira.
> >
> > I think Eddie has been looking at this process trying to replicate the
> > Kafka setup, so perhaps he can give an update if I'm right. Kafka doesn't
> > send every comment to the mailing list, though, but I'm not sure if
> that's
> > acceptable according to the ASF, I need to double-check.
> >
> > -Flavio
> >
> > > On 04 Oct 2016, at 19:42, Michael Han <ha...@cloudera.com> wrote:
> > >
> > > Hi,
> > >
> > > Now we've moved to git, what is the policy for uploading patches and
> > doing
> > > code reviews? I am asking because I've seen recently there are git pull
> > > requests coming in without associated patch file uploaded to JIRA. I've
> > > checked
> > > https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute,
> > > looks like there is not much change regarding patch process - so
> > presumably
> > > we still need to generate and upload patch file to JIRA for the record,
> > > while using github (maybe in addition of review board, or in the future
> > > with gerrit) to do code reviews?
> > >
> > >
> > > On Wed, Sep 21, 2016 at 6:05 AM, Edward Ribeiro <
> > edward.ribeiro@gmail.com>
> > > wrote:
> > >
> > >> Cool, just open https://issues.apache.org/jira/browse/ZOOKEEPER-2597
> > >>
> > >> PS: I removed the REPO_HOME global variable.
> > >>
> > >> On Wed, Sep 21, 2016 at 6:53 AM, Flavio Junqueira <fp...@apache.org>
> > wrote:
> > >>
> > >>> Better to have that in the form of a pull request or diff.
> > >>>
> > >>> REPO_HOME does seem to be unused.
> > >>>
> > >>> -Flavio
> > >>>
> > >>>> On 20 Sep 2016, at 18:57, Edward Ribeiro <ed...@gmail.com>
> > >>> wrote:
> > >>>>
> > >>>> Hey, I have started porting the kafka-merge.py to work on ZK repos.
> I
> > >>> would
> > >>>> need someone to review it and help me test it now.
> > >>>>
> > >>>> The files were uploaded below, but I will create a github repo yet
> > >> today.
> > >>>>
> > >>>> https://www.dropbox.com/sh/od8bet2574jttm3/
> > >>> AADv1DXTb8vfyVCmelFbYCEha?dl=0
> > >>>>
> > >>>> I uploaded the kafka version script so that you can use diff or Meld
> > to
> > >>>> spot my changes, but feel free to grasp the original file here:
> > >>>> https://github.com/apache/kafka/blob/trunk/kafka-merge-pr.py
> > >>>>
> > >>>> PS: It's just me or REPO_HOME env variable is not used anywhere in
> the
> > >>>> merge script???
> > >>>>
> > >>>> Cheers,
> > >>>> Eddie
> > >>>>
> > >>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick Hunt <ph...@apache.org>
> > >> wrote:
> > >>>>
> > >>>>> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin Reed <br...@apache.org>
> > >>> wrote:
> > >>>>>
> > >>>>>> what you are suggesting sounds good, but i don't know how to do
> it?
> > >>> since
> > >>>>>> in the end we are still just accepting diffs on patches, the only
> > >> thing
> > >>>>>> that changes is that we use svn rather than git right?
> > >>>>>>
> > >>>>>>
> > >>>>> Notice the workflow Kafka uses - which includes "git apply" and
> > >>> specifying
> > >>>>> the author tag when committers commit (so that the OP gets proper
> > >>>>> attribution in the commit itself)
> > >>>>>
> > >>>>> https://cwiki.apache.org/confluence/display/KAFKA/
> > >>> Manual+Commit+Workflow
> > >>>>>
> > >>>>> Patrick
> > >>>>>
> > >>>>>
> > >>>>>
> > >>>>>> i LOVE chris's idea! lets do it!
> > >>>>>>
> > >>>>>> ben
> > >>>>>>
> > >>>>>> On Sun, Sep 18, 2016 at 3:22 PM, Patrick Hunt <ph...@apache.org>
> > >>> wrote:
> > >>>>>>
> > >>>>>>> Ben, do you also want to update the "Applying a patch" section to
> > >> make
> > >>>>> it
> > >>>>>>> git specific?
> > >>>>>>>
> > >>>>>>> We (committers) should move to a model where authors get proper
> > >> credit
> > >>>>> in
> > >>>>>>> git. Our old workflow in svn resulted in only the committer being
> > >>>>> listed
> > >>>>>>> (except that we listed the patch author in the commit message).
> We
> > >>>>> should
> > >>>>>>> move to a model where the author of the patch gets proper credit
> in
> > >>>>> git.
> > >>>>>> I
> > >>>>>>> believe we will get that if we use git for patch
> > >> creation/application?
> > >>>>>>>
> > >>>>>>> Chris brought up getting rid of CHANGES.txt recently on the dev
> > list
> > >>>>> in a
> > >>>>>>> separate thread - Chris do you want to implement that change now
> > >> that
> > >>>>>> we've
> > >>>>>>> moved to git?
> > >>>>>>>
> > >>>>>>> Patrick
> > >>>>>>>
> > >>>>>>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin Reed <breed@apache.org
> >
> > >>>>> wrote:
> > >>>>>>>
> > >>>>>>>>> 1) actually in the previous step that was just adding new
> files.
> > >> you
> > >>>>>>>>> still
> > >>>>>>>>>> need the commit -a for the rest of the changes. that's my
> normal
> > >>>>>>>>> workflow.
> > >>>>>>>>>
> > >>>>>>>>> I think that will be confusing for most folks. They typically
> > >> stage
> > >>>>>>>>> all the changes and then commit or don't stage and use -a.
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>> do you mind fixing it with your workflow. commit -a doesn't get
> > new
> > >>>>>>>> files, which is why you need to do the add, but i'm not the most
> > >>>>>>>> sophisticated git user, so
> > >>>>>>>>
> > >>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>>> 2) i figured since we are using git now that we should use
> git's
> > >>>>>>>>> default.
> > >>>>>>>>>> the patch should work (by default it seems to strip the first
> > >> path
> > >>>>>>>>> element).
> > >>>>>>>>>> does it not work for you?
> > >>>>>>>>>>
> > >>>>>>>>>
> > >>>>>>>>> It will fail precommit in it's current state.
> > >>>>>>>>>
> > >>>>>>>>
> > >>>>>>>> fixed
> > >>>>>>>>
> > >>>>>>>
> > >>>>>>>
> > >>>>>>
> > >>>>>
> > >>>
> > >>>
> > >>
> > >
> > >
> > >
> > > --
> > > Cheers
> > > Michael.
> >
> >
>
>
> --
> Cheers
> Michael.
>

Re: [VOTE] move Apache Zookeeper to git

Posted by Michael Han <ha...@cloudera.com>.

>> as long as the opening/closing/commenting all get sent to the mailing
list or recorded in jira
Yeah, this is my impression as well, that we need to keep certain paper
trail regarding activities and comments on ASF side (JIRA or mail list).
Infra page said:

   - Any Pull Request that gets opened, closed, reopened or **commented**
   on now gets recorded on the project's mailing list
   - If a project has a JIRA instance, any PRs or *comments* on PRs that
   include a JIRA ticket ID will trigger an update on that specific ticket

I checked a couple Kafka and Spark JIRAs but I don't see any of the
comments made in github PR were posted on JIRA, except the activities (open
a PR, close a PR). Since both projects have been using github for a while I
assume such practice of NOT integrating comments between github and ASF
JIRA is acceptable? Though I feel it would be really useful if comments
could converge in a single place as well, that will provide a clear history
for a given technical issue.

On Tue, Oct 4, 2016 at 12:06 PM, Flavio Junqueira <fp...@apache.org> wrote:

> Until ZOOKEEPER-2597 <https://issues.apache.org/jira/browse/ZOOKEEPER-2597>
> is fixed, we can't merge via github.
>
> For code reviews, we can use GH as long as the opening/closing/commenting
> all get sent to the mailing list or recorded in jira. I don't think we have
> that yet, but it is possible according to this:
>
> https://blogs.apache.org/infra/entry/improved_
> integration_between_apache_and <https://blogs.apache.org/
> infra/entry/improved_integration_between_apache_and>
>
> For now, we do need to upload patches and converge using jira.
>
> I think Eddie has been looking at this process trying to replicate the
> Kafka setup, so perhaps he can give an update if I'm right. Kafka doesn't
> send every comment to the mailing list, though, but I'm not sure if that's
> acceptable according to the ASF, I need to double-check.
>
> -Flavio
>
> > On 04 Oct 2016, at 19:42, Michael Han <ha...@cloudera.com> wrote:
> >
> > Hi,
> >
> > Now we've moved to git, what is the policy for uploading patches and
> doing
> > code reviews? I am asking because I've seen recently there are git pull
> > requests coming in without associated patch file uploaded to JIRA. I've
> > checked
> > https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute,
> > looks like there is not much change regarding patch process - so
> presumably
> > we still need to generate and upload patch file to JIRA for the record,
> > while using github (maybe in addition of review board, or in the future
> > with gerrit) to do code reviews?
> >
> >
> > On Wed, Sep 21, 2016 at 6:05 AM, Edward Ribeiro <
> edward.ribeiro@gmail.com>
> > wrote:
> >
> >> Cool, just open https://issues.apache.org/jira/browse/ZOOKEEPER-2597
> >>
> >> PS: I removed the REPO_HOME global variable.
> >>
> >> On Wed, Sep 21, 2016 at 6:53 AM, Flavio Junqueira <fp...@apache.org>
> wrote:
> >>
> >>> Better to have that in the form of a pull request or diff.
> >>>
> >>> REPO_HOME does seem to be unused.
> >>>
> >>> -Flavio
> >>>
> >>>> On 20 Sep 2016, at 18:57, Edward Ribeiro <ed...@gmail.com>
> >>> wrote:
> >>>>
> >>>> Hey, I have started porting the kafka-merge.py to work on ZK repos. I
> >>> would
> >>>> need someone to review it and help me test it now.
> >>>>
> >>>> The files were uploaded below, but I will create a github repo yet
> >> today.
> >>>>
> >>>> https://www.dropbox.com/sh/od8bet2574jttm3/
> >>> AADv1DXTb8vfyVCmelFbYCEha?dl=0
> >>>>
> >>>> I uploaded the kafka version script so that you can use diff or Meld
> to
> >>>> spot my changes, but feel free to grasp the original file here:
> >>>> https://github.com/apache/kafka/blob/trunk/kafka-merge-pr.py
> >>>>
> >>>> PS: It's just me or REPO_HOME env variable is not used anywhere in the
> >>>> merge script???
> >>>>
> >>>> Cheers,
> >>>> Eddie
> >>>>
> >>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick Hunt <ph...@apache.org>
> >> wrote:
> >>>>
> >>>>> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin Reed <br...@apache.org>
> >>> wrote:
> >>>>>
> >>>>>> what you are suggesting sounds good, but i don't know how to do it?
> >>> since
> >>>>>> in the end we are still just accepting diffs on patches, the only
> >> thing
> >>>>>> that changes is that we use svn rather than git right?
> >>>>>>
> >>>>>>
> >>>>> Notice the workflow Kafka uses - which includes "git apply" and
> >>> specifying
> >>>>> the author tag when committers commit (so that the OP gets proper
> >>>>> attribution in the commit itself)
> >>>>>
> >>>>> https://cwiki.apache.org/confluence/display/KAFKA/
> >>> Manual+Commit+Workflow
> >>>>>
> >>>>> Patrick
> >>>>>
> >>>>>
> >>>>>
> >>>>>> i LOVE chris's idea! lets do it!
> >>>>>>
> >>>>>> ben
> >>>>>>
> >>>>>> On Sun, Sep 18, 2016 at 3:22 PM, Patrick Hunt <ph...@apache.org>
> >>> wrote:
> >>>>>>
> >>>>>>> Ben, do you also want to update the "Applying a patch" section to
> >> make
> >>>>> it
> >>>>>>> git specific?
> >>>>>>>
> >>>>>>> We (committers) should move to a model where authors get proper
> >> credit
> >>>>> in
> >>>>>>> git. Our old workflow in svn resulted in only the committer being
> >>>>> listed
> >>>>>>> (except that we listed the patch author in the commit message). We
> >>>>> should
> >>>>>>> move to a model where the author of the patch gets proper credit in
> >>>>> git.
> >>>>>> I
> >>>>>>> believe we will get that if we use git for patch
> >> creation/application?
> >>>>>>>
> >>>>>>> Chris brought up getting rid of CHANGES.txt recently on the dev
> list
> >>>>> in a
> >>>>>>> separate thread - Chris do you want to implement that change now
> >> that
> >>>>>> we've
> >>>>>>> moved to git?
> >>>>>>>
> >>>>>>> Patrick
> >>>>>>>
> >>>>>>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin Reed <br...@apache.org>
> >>>>> wrote:
> >>>>>>>
> >>>>>>>>> 1) actually in the previous step that was just adding new files.
> >> you
> >>>>>>>>> still
> >>>>>>>>>> need the commit -a for the rest of the changes. that's my normal
> >>>>>>>>> workflow.
> >>>>>>>>>
> >>>>>>>>> I think that will be confusing for most folks. They typically
> >> stage
> >>>>>>>>> all the changes and then commit or don't stage and use -a.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> do you mind fixing it with your workflow. commit -a doesn't get
> new
> >>>>>>>> files, which is why you need to do the add, but i'm not the most
> >>>>>>>> sophisticated git user, so
> >>>>>>>>
> >>>>>>>>
> >>>>>>>>>
> >>>>>>>>>> 2) i figured since we are using git now that we should use git's
> >>>>>>>>> default.
> >>>>>>>>>> the patch should work (by default it seems to strip the first
> >> path
> >>>>>>>>> element).
> >>>>>>>>>> does it not work for you?
> >>>>>>>>>>
> >>>>>>>>>
> >>>>>>>>> It will fail precommit in it's current state.
> >>>>>>>>>
> >>>>>>>>
> >>>>>>>> fixed
> >>>>>>>>
> >>>>>>>
> >>>>>>>
> >>>>>>
> >>>>>
> >>>
> >>>
> >>
> >
> >
> >
> > --
> > Cheers
> > Michael.
>
>


-- 
Cheers
Michael.

Re: [VOTE] move Apache Zookeeper to git

Posted by Flavio Junqueira <fp...@apache.org>.

Until ZOOKEEPER-2597 <https://issues.apache.org/jira/browse/ZOOKEEPER-2597> is fixed, we can't merge via github.

For code reviews, we can use GH as long as the opening/closing/commenting all get sent to the mailing list or recorded in jira. I don't think we have that yet, but it is possible according to this:

https://blogs.apache.org/infra/entry/improved_integration_between_apache_and <https://blogs.apache.org/infra/entry/improved_integration_between_apache_and>

For now, we do need to upload patches and converge using jira.

I think Eddie has been looking at this process trying to replicate the Kafka setup, so perhaps he can give an update if I'm right. Kafka doesn't send every comment to the mailing list, though, but I'm not sure if that's acceptable according to the ASF, I need to double-check.

-Flavio

> On 04 Oct 2016, at 19:42, Michael Han <ha...@cloudera.com> wrote:
> 
> Hi,
> 
> Now we've moved to git, what is the policy for uploading patches and doing
> code reviews? I am asking because I've seen recently there are git pull
> requests coming in without associated patch file uploaded to JIRA. I've
> checked
> https://cwiki.apache.org/confluence/display/ZOOKEEPER/HowToContribute,
> looks like there is not much change regarding patch process - so presumably
> we still need to generate and upload patch file to JIRA for the record,
> while using github (maybe in addition of review board, or in the future
> with gerrit) to do code reviews?
> 
> 
> On Wed, Sep 21, 2016 at 6:05 AM, Edward Ribeiro <ed...@gmail.com>
> wrote:
> 
>> Cool, just open https://issues.apache.org/jira/browse/ZOOKEEPER-2597
>> 
>> PS: I removed the REPO_HOME global variable.
>> 
>> On Wed, Sep 21, 2016 at 6:53 AM, Flavio Junqueira <fp...@apache.org> wrote:
>> 
>>> Better to have that in the form of a pull request or diff.
>>> 
>>> REPO_HOME does seem to be unused.
>>> 
>>> -Flavio
>>> 
>>>> On 20 Sep 2016, at 18:57, Edward Ribeiro <ed...@gmail.com>
>>> wrote:
>>>> 
>>>> Hey, I have started porting the kafka-merge.py to work on ZK repos. I
>>> would
>>>> need someone to review it and help me test it now.
>>>> 
>>>> The files were uploaded below, but I will create a github repo yet
>> today.
>>>> 
>>>> https://www.dropbox.com/sh/od8bet2574jttm3/
>>> AADv1DXTb8vfyVCmelFbYCEha?dl=0
>>>> 
>>>> I uploaded the kafka version script so that you can use diff or Meld to
>>>> spot my changes, but feel free to grasp the original file here:
>>>> https://github.com/apache/kafka/blob/trunk/kafka-merge-pr.py
>>>> 
>>>> PS: It's just me or REPO_HOME env variable is not used anywhere in the
>>>> merge script???
>>>> 
>>>> Cheers,
>>>> Eddie
>>>> 
>>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick Hunt <ph...@apache.org>
>> wrote:
>>>> 
>>>>> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin Reed <br...@apache.org>
>>> wrote:
>>>>> 
>>>>>> what you are suggesting sounds good, but i don't know how to do it?
>>> since
>>>>>> in the end we are still just accepting diffs on patches, the only
>> thing
>>>>>> that changes is that we use svn rather than git right?
>>>>>> 
>>>>>> 
>>>>> Notice the workflow Kafka uses - which includes "git apply" and
>>> specifying
>>>>> the author tag when committers commit (so that the OP gets proper
>>>>> attribution in the commit itself)
>>>>> 
>>>>> https://cwiki.apache.org/confluence/display/KAFKA/
>>> Manual+Commit+Workflow
>>>>> 
>>>>> Patrick
>>>>> 
>>>>> 
>>>>> 
>>>>>> i LOVE chris's idea! lets do it!
>>>>>> 
>>>>>> ben
>>>>>> 
>>>>>> On Sun, Sep 18, 2016 at 3:22 PM, Patrick Hunt <ph...@apache.org>
>>> wrote:
>>>>>> 
>>>>>>> Ben, do you also want to update the "Applying a patch" section to
>> make
>>>>> it
>>>>>>> git specific?
>>>>>>> 
>>>>>>> We (committers) should move to a model where authors get proper
>> credit
>>>>> in
>>>>>>> git. Our old workflow in svn resulted in only the committer being
>>>>> listed
>>>>>>> (except that we listed the patch author in the commit message). We
>>>>> should
>>>>>>> move to a model where the author of the patch gets proper credit in
>>>>> git.
>>>>>> I
>>>>>>> believe we will get that if we use git for patch
>> creation/application?
>>>>>>> 
>>>>>>> Chris brought up getting rid of CHANGES.txt recently on the dev list
>>>>> in a
>>>>>>> separate thread - Chris do you want to implement that change now
>> that
>>>>>> we've
>>>>>>> moved to git?
>>>>>>> 
>>>>>>> Patrick
>>>>>>> 
>>>>>>> On Wed, Sep 14, 2016 at 9:01 PM, Benjamin Reed <br...@apache.org>
>>>>> wrote:
>>>>>>> 
>>>>>>>>> 1) actually in the previous step that was just adding new files.
>> you
>>>>>>>>> still
>>>>>>>>>> need the commit -a for the rest of the changes. that's my normal
>>>>>>>>> workflow.
>>>>>>>>> 
>>>>>>>>> I think that will be confusing for most folks. They typically
>> stage
>>>>>>>>> all the changes and then commit or don't stage and use -a.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> do you mind fixing it with your workflow. commit -a doesn't get new
>>>>>>>> files, which is why you need to do the add, but i'm not the most
>>>>>>>> sophisticated git user, so
>>>>>>>> 
>>>>>>>> 
>>>>>>>>> 
>>>>>>>>>> 2) i figured since we are using git now that we should use git's
>>>>>>>>> default.
>>>>>>>>>> the patch should work (by default it seems to strip the first
>> path
>>>>>>>>> element).
>>>>>>>>>> does it not work for you?
>>>>>>>>>> 
>>>>>>>>> 
>>>>>>>>> It will fail precommit in it's current state.
>>>>>>>>> 
>>>>>>>> 
>>>>>>>> fixed
>>>>>>>> 
>>>>>>> 
>>>>>>> 
>>>>>> 
>>>>> 
>>> 
>>> 
>> 
> 
> 
> 
> -- 
> Cheers
> Michael.