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