Thanks, Eddie. This is great. > On 26 Oct 2016, at 17:45, Edward Ribeiro <edward.ribe...@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 <h...@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 <f...@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 <cami...@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.ribe...@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 <h...@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 <f...@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.ribe...@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 <h...@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 < >> f...@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 <h...@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.ribe...@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 < >>>>>> f...@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.ribe...@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. >>>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> Cheers >>>>>>> Michael. >>>>>>> >>>>>> >>>>> >>> >>> >> >> >> -- >> Cheers >> Michael. >>
