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.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/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 <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/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 <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. > > > > >
