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.ribe...@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.ribe...@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 <f...@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 <h...@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 <h...@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.ribe...@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 <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/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 < >> 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. >> > > >>>> >> > > >>> >> > > >> >> > > >> >> > > >> >> > > >> -- >> > > >> Cheers >> > > >> Michael. >> > > >> >> > > > >> > > > >> > > > >> > > > -- >> > > > Cheers >> > > > Michael. >> > > >> > > >> > >> >
