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