Mailing-List: contact dev-help@zookeeper.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@zookeeper.apache.org
MIME-Version: 1.0
In-Reply-To: <CANLc_9K+e0QbN8MTr2-PrOAHhtb9AkhEOY8fvk2Dw-nJQWEc4Q@mail.gmail.com>
References: <CAKR25ETSNoDckyknXOujn1joG6OJUEf5-L+B7hB5ASQ1U4PARQ@mail.gmail.com>
 <45012F9B-5FFC-4856-8992-7560540997FF@jordanzimmerman.com>
 <CAC==nPTUSppoQ_8i-mpOyB8sDcbAfW=zNa39MAzyHq0jkgWETQ@mail.gmail.com>
 <AA13C8BF-F71B-47C5-92B0-34D5E37014BF@apache.org> <CAHvriTgr5r851H05CWaDSv5EHWBmghsZDQTw=xqPzdiy=yQVuQ@mail.gmail.com>
 <CA+i0x1+35Nxeph9oMFz_v1Hns6+4M8D3USAXN4wDc_m1RZyGgw@mail.gmail.com>
 <CAKR25ER3ZSEuLUnGVv80MDRfWXwiFwJNij2sNyiYWpFSStBP6g@mail.gmail.com>
 <CANLc_9LqDz7gu1kEcn4sUr3MyRW3fATGKaoEaMp2a_OV=acbbQ@mail.gmail.com>
 <CANLc_9JaPX4GU9ZkVLH43dKsygpiH4UpzVgRinnk8yJ572d0ZA@mail.gmail.com>
 <C8DE4DEF-AD68-48F5-823A-43D06C0C771D@apache.org> <CAC==nPTAzR4U6kKTuo5vpTjwRaJ+zq3GKfRqAYyx-itfnLBsbw@mail.gmail.com>
 <EA85F8C2-97EB-4302-8B46-A3D5C7EFC8FE@hortonworks.com> <CANLc_9L2EvCnHEDsFGPN3esUFJJ1-ou9R52DGKpqVqVO2iZABw@mail.gmail.com>
 <CAKR25ETzkJ1bMCo6WF9MpLu3wZ30=ygTHjoj2YBtveC7VTvBew@mail.gmail.com>
 <CANLc_9+LvhEwuqNO+w3RmfSLKQvgecKZGdmX0kmn559GNsmEWw@mail.gmail.com>
 <C3883064-4613-4D40-9EE1-6F0051BC59E4@apache.org> <CANLc_9Kkvo136tjFLPee9eLvcxn4hSV=V5Basuij6VhZKaDboQ@mail.gmail.com>
 <CANLc_9LZ9J2pPB-fuqgYFz-YDN_eqikGLmPhJfsF0EUMF94NYQ@mail.gmail.com>
 <CAMUR=WjD-zGcgLnB2_+o9oVT7ugzvxPk1uMKip9RRmdjLdU-1A@mail.gmail.com>
 <CANLc_9+BWXukw4U7PbJYmMOWPtj-Sq9FupAFd-f8sJhOXfZbkg@mail.gmail.com>
 <CAMUR=Wi8crre=Kz84puuT6LRxV=UVL9bXLF52si8Br8JPZ8zCg@mail.gmail.com>
 <CANLc_9JaY6868ALG30ZWrjFfHojCaG1=8dz80tg0Y+xm+Nx-nQ@mail.gmail.com>
 <CAKR25EQJnA28RwuCprvGqfiedGXr8t3WNktjUkoCYQryd3HpgQ@mail.gmail.com>
 <CANLc_9+6zvtJn0fUd+dHnMJ9uAwUr1v5g08PrzfJxjL-g4R4YQ@mail.gmail.com>
 <CAKR25ETQ3eRsegw9=rsR5t7Ev2aegT=trdSNdG6s7xK2QKG3Ng@mail.gmail.com>
 <CANLc_9+viAArY+9OYwa9k+MBfjoD6hx7AjPKFuuk==gpvk7hrg@mail.gmail.com>
 <CAKR25ERcz6NLbmNA9UPLgouC5TtObTh=X525-1AE8M5Zzdm9_w@mail.gmail.com>
 <CANLc_9JfJCCT_OxY5103_KYmJD_JZsj1MD3uLaZB9PTzOJ+NMQ@mail.gmail.com>
 <CAKR25ESZxvus8DMEm6As6V9LWdeDiLxi7LGM17_JxzAF9PJwkQ@mail.gmail.com>
 <CANLc_9KpyrhHAi31cEVHdeSBxS1ikFGFgbc7RBHgpPQ68DoVjg@mail.gmail.com>
 <CAC==nPTERLB8J3MB7fLx_-BRgOXC4fhHpqLUurfaciqb=zZ4ew@mail.gmail.com>
 <817190F2-450F-479C-875B-A9151B9D09F4@apache.org> <CAC==nPSqkZ4-zdWMMXsbRsMDF12sTmv_Dsfv3pn==Y1YSz+NKw@mail.gmail.com>
 <CA+i0x1+JCTQ-+cb3jMTVYU+p3kuS+Oz4ZTCiDhHmQ-VAsouUKg@mail.gmail.com>
 <89B24A86-37E9-47FB-8B17-6A25B3F8A7B0@apache.org> <CA+i0x1LcTjXt+WgmEYMswt3GuU1wHLHWqjoofMf1ByW11vtXjA@mail.gmail.com>
 <CAC==nPSURZR+s6TgdSJq+Kj6gvyEpgyzFNPWU3oHO5WcDNThGA@mail.gmail.com>
 <E713EC57-B2FC-4489-95D9-D4700B5266A5@apache.org> <CA+i0x1LganEp6vSvdTu4oF-OwkN+2RjFrV=QcyESGzjTONs7gA@mail.gmail.com>
 <CAC==nPSJVP6T3PgC7J2Uk8WqYCj7a0PRNB=nCx42OFADCcB2vg@mail.gmail.com>
 <CABWqe2ZLkfO8axLGVJBOUJwvKzeCSYUtuU05XKB_ETmS0VpWNA@mail.gmail.com>
 <CAKR25ESQRAYUzrfU6g9_x6HuVc7KknSgJiciTfOf41eRymcHJg@mail.gmail.com>
 <4C941A0A-5D03-4EAD-ABA9-8A1DEA22843B@apache.org> <CA+i0x1LNkL+-NUeYqu1oAS0Wc9-vFLgCY-NpwPm4Tjp1cPAA=g@mail.gmail.com>
 <CAC==nPRtz1ZpY1e_H6JjuSCh7tRqGdoYu_WqfRkOk-MsqDgwHQ@mail.gmail.com>
 <CA+i0x1KDrFiKnOSLkbTcYT=9fqMpE48rCQ7NTLewBOZ-u7LVqw@mail.gmail.com>
 <CA+i0x1JOvdgfOKVSmbUr9C0T3b5TWCb0ccb6fd=48tkoF+uqOQ@mail.gmail.com>
 <AE0F7468-715B-41D8-820C-844FCBA513C0@apache.org> <CAC==nPTpcVVKOUHR1b69mvy9HvK2M1pgKNnYmpy+ihaLeNer3w@mail.gmail.com>
 <CANLc_9KLKd2EOcf5zYG22-DXY6fTBD018gpGJQZuX6RKRSyj0Q@mail.gmail.com>
 <CAC==nPRa9vN-F5YxVb35egCV+uOVndgSqjq0GQT-znjNv_6sZQ@mail.gmail.com>
 <CAC==nPQ969aeixmJxM6K_u1LDj5TOH0W6rUXL4uNWwzKkEu+bg@mail.gmail.com>
 <CANLc_9LsQwDeF1Sq-0OTPndfETDwDcrVKVYOLS=Ub6SuWbjgiA@mail.gmail.com>
 <CAC==nPQ=r9OquQbV9LyQ0eafbfo6JX_s-bcCfNQ=aoTKQV80pA@mail.gmail.com> <CANLc_9K+e0QbN8MTr2-PrOAHhtb9AkhEOY8fvk2Dw-nJQWEc4Q@mail.gmail.com>
From: Edward Ribeiro <edward.ribeiro@gmail.com>
Date: Tue, 6 Dec 2016 12:17:21 -0200
Message-ID: <CAC==nPTH2Bz+YgE2VUtkg_CTaK94zNrug=mXEfkeeq4k22a_FA@mail.gmail.com>
Subject: Re: [VOTE] move Apache Zookeeper to git
To: DevZooKeeper <dev@zookeeper.apache.org>
Content-Type: multipart/alternative; boundary=001a114d78ba18b3e10542fe1067
archived-at: Tue, 06 Dec 2016 14:17:43 -0000

--001a114d78ba18b3e10542fe1067
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

Oh, Patrick (and Flavio, and Ben Reed),

I asked some questions to one ASF committer that has been using the
Github-JIRA-Apache combo for a while now. According to him, committers
*cannot* manually close 3rd party PRs. :( He said this is a combination of
Github limitations and INFRA policies, his explanations below:

Question:  1) Do committers have to contact ASF INFRA to be able to close
PR on Github mirror? Some people created bogus PR that we would like to
close, but they don't have this option now. Can INFRA give committers the
auth to close those 3rd party PRs?

Answer: "You either have to ask INFRA, ask the author or close via a dummy
commit. In our project, we first ask the author and occasionally we ask
INFRA to close a bunch of them or a particularly bad one (someone had
created a PR for merging trunk to a stable branch, for example. That would
cause a PR build every time something was merged to trunk).

Basically, if you have write access to the PRs, you also have write access
to the GitHub repository. And INFRA believes it's essential for the GitHub
repo to be read only. The writes flow from the Apache git repo. The Apache
git repo has more safeguards (although protected branches in GitHub could
help here, not sure if the Apache INFRA team has considered them)."

Question: At Kafka, all the PR goes through GH? Or do you committers
usually apply patches directly to Apache git repo?

Answer: "We now always use GitHub, we don't use patches any more"
Edward

On Mon, Dec 5, 2016 at 9:07 PM, Patrick Hunt <phunt@apache.org> wrote:

> No problem Edward. Did you get any insight on what to do with the PR?
>
> Patrick
>
> On Thu, Nov 24, 2016 at 10:52 AM, Edward Ribeiro <edward.ribeiro@gmail.co=
m
> >
> wrote:
>
> > Hi, Patrick,
> >
> > Thanks for merging this change. :)
> >
> > Sincerely, I don't know why it didn't close the PR automatically. Nor w=
hy
> > you can close it in the GH mirror. In any case, I manually closed it.
> >
> > I will ping folks from other Apache projects using similar tool to
> inquire
> > why it didn't close the PR and why it gave this 'write access' error
> > message.
> >
> > Edward
> >
> >
> >
> > On Fri, Nov 18, 2016 at 8:13 PM, Patrick Hunt <phunt@apache.org> wrote:
> >
> >> Thanks Edward, this should be very helpful for folks. I committed,
> >> however I notice the PR is still open. I followed the steps here:
> >> https://cwiki.apache.org/confluence/display/ZOOKEEPER/
> Committing+changes
> >> however I don't see a way to close the PR? https://github.com/apache/
> >> zookeeper/pull/103 says I don't have "write access".
> >>
> >> Patrick
> >>
> >> On Thu, Nov 10, 2016 at 10:23 AM, Edward Ribeiro <
> >> edward.ribeiro@gmail.com> wrote:
> >>
> >>> 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.ribeiro@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" <phunt@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=3Dmypassword" wh=
ich
> I
> >>> feel
> >>> >> very uncomfortable doing.
> >>> >>
> >>> >> Patrick
> >>> >>
> >>> >> On Wed, Oct 26, 2016 at 11:12 AM, Edward Ribeiro <
> >>> >> edward.ribeiro@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/confl
> >>> uence/display/ZOOKEEPER/
> >>> >> > Index
> >>> >> >
> >>> >> > On Wed, Oct 26, 2016 at 3:59 PM, Flavio Junqueira <fpj@apache.or=
g
> >
> >>> >> wrote:
> >>> >> >
> >>> >> > > What about QA, are we still missing a github pre-commit queue?
> >>> >> > >
> >>> >> > > -Flavio
> >>> >> > >
> >>> >> > > > On 26 Oct 2016, at 18:53, Michael Han <hanm@cloudera.com>
> >>> wrote:
> >>> >> > > >
> >>> >> > > > The comment bridging should be fixed now - see INFRA-12752 f=
or
> >>> more
> >>> >> > > > details.
> >>> >> > > >
> >>> >> > > > On Wed, Oct 26, 2016 at 10:03 AM, Michael Han <
> >>> hanm@cloudera.com>
> >>> >> > wrote:
> >>> >> > > >
> >>> >> > > >>>> The git PR *review* comments for ZOOKEEPER-2597 didn't sh=
ow
> >>> 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 sto=
p
> >>> >> working.
> >>> >> > I
> >>> >> > > am
> >>> >> > > >> reopening INFRA-12752 and building a case.
> >>> >> > > >>
> >>> >> > > >> On Wed, Oct 26, 2016 at 9:45 AM, Edward Ribeiro <
> >>> >> > > edward.ribeiro@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, jus=
t
> 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 <
> >>> hanm@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 <
> >>> fpj@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 <
> breed@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 a=
nd
> >>> 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 <
> >>> >> > > >>> camille@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 wik=
is
> >>> and
> >>> >> > > >>> correct
> >>> >> > > >>>> the
> >>> >> > > >>>>>>> stuff that refers to SVN?
> >>> >> > > >>>>>>>
> >>> >> > > >>>>>>> Thanks,
> >>> >> > > >>>>>>> C
> >>> >> > > >>>>>>>
> >>> >> > > >>>>>>> On Wed, Oct 5, 2016 at 1:02 PM, Edward Ribeiro <
> >>> >> > > >>>>> edward.ribeiro@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/eribei
> >>> ro/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 t=
he
> >>> >> > 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 befor=
e
> >>> 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 JIR=
A
> >>> >> ticket.
> >>> >> > > >>> There
> >>> >> > > >>>>> are
> >>> >> > > >>>>>>> a
> >>> >> > > >>>>>>>> class of PRs with "MINOR" title that represent trivia=
l
> >>> code
> >>> >> > > >>> changes
> >>> >> > > >>>> and
> >>> >> > > >>>>>>>> "HOT-FIX" title that fix urgent, but simple bugs. Bot=
h
> >>> 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 patc=
h
> >>> 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 <
> >>> >> hanm@cloudera.com>
> >>> >> > > >>>> wrote:
> >>> >> > > >>>>>>>>
> >>> >> > > >>>>>>>>> Eddie's mail contains lots of '=3DE2=3D80=3D8B'' whi=
ch 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 <
> >>> >> > fpj@apache.org
> >>> >> > > >>>>
> >>> >> > > >>>>>>> wrote:
> >>> >> > > >>>>>>>>>
> >>> >> > > >>>>>>>>>> Dude, I'm just not able to parse your e-mail, did y=
ou
> >>> write
> >>> >> > that
> >>> >> > > >>>> on a
> >>> >> > > >>>>>>>>>> phone or something?
> >>> >> > > >>>>>>>>>>
> >>> >> > > >>>>>>>>>> -Flavio
> >>> >> > > >>>>>>>>>>
> >>> >> > > >>>>>>>>>>> On 05 Oct 2016, at 03:54, Edward Ribeiro <
> >>> >> > > >>>> edward.ribeiro@gmail.com
> >>> >> > > >>>>>>>>
> >>> >> > > >>>>>>>>>> wrote:
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>> Hi,
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>> The patch attached on ZOOKEEPER-2597 is a
> >>> >> > > >>>>>>>>>>> =E2=80=8Bstraightforward adaptation of
> >>> >> > > >>>>>>>>>>> Kafka's one. It takes care of merging Github PR in=
to
> >>> >> Apache
> >>> >> > git
> >>> >> > > >>>>>>> repo
> >>> >> > > >>>>>>>>> and
> >>> >> > > >>>>>>>>>>> =E2=80=8B a=E2=80=8B
> >>> >> > > >>>>>>>>>>> subsequent closing of the PR on the GH side
> >>> >> > > >>>>>>>>>>> =E2=80=8B among other things (rewriting of commit =
messages,
> >>> etc)=E2=80=8B
> >>> >> > > >>>>>>>>>>> . The current status is: the script needs to be
> >>> >> > > >>> reviewed/validated
> >>> >> > > >>>>>>>> by a
> >>> >> > > >>>>>>>>>>> committer.
> >>> >> > > >>>>>>>>>>> =E2=80=8BIt has been some time since I uploaded th=
e patch,
> so
> >>> I
> >>> >> gonna
> >>> >> > > >>> do
> >>> >> > > >>>>>>>>> another
> >>> >> > > >>>>>>>>>>> pass through it in the meantime.=E2=80=8B
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>> =E2=80=8BT
> >>> >> > > >>>>>>>>>>> here are some workflow issues beyond the scope of
> >>> >> > > >>> ZOOKEEPER-2597
> >>> >> > > >>>>>>>>>>> =E2=80=8B that need to be sorted out (IMO)=E2=80=
=8B
> >>> >> > > >>>>>>>>>>> :
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>> 1. The normal workflow is to open a JIRA ticket
> before
> >>> >> doing
> >>> >> > > >>> any
> >>> >> > > >>>> GH
> >>> >> > > >>>>>>>> PR
> >>> >> > > >>>>>>>>>>> =E2=80=8B, that is, no JIRA-less PRs.=E2=80=8B
> >>> >> > > >>>>>>>>>>> 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.
> >>> >> > > >>>>>>>>>>> =E2=80=8BOTOH, =E2=80=8Bn
> >>> >> > > >>>>>>>>>>> ot every Kafka PR needs a corresponding JIRA ticke=
t
> >>> >> > > >>>>>>>>>>> =E2=80=8B. =E2=80=8B
> >>> >> > > >>>>>>>>>>> There are a class of PR
> >>> >> > > >>>>>>>>>>> =E2=80=8Bs=E2=80=8B
> >>> >> > > >>>>>>>>>>> with "MINOR"
> >>> >> > > >>>>>>>>>>> =E2=80=8B title=E2=80=8B
> >>> >> > > >>>>>>>>>>> that represent trivial code changes
> >>> >> > > >>>>>>>>>>> =E2=80=8B and "HOT-FIX" title that fix urgent, but=
 simple
> >>> bugs.
> >>> >> Both=E2=80=8B
> >>> >> > > >>>>>>>>>>> bypass the JIRA creation step
> >>> >> > > >>>>>>>>>>> =E2=80=8B, even tough they are still =E2=80=8B
> >>> >> > > >>>>>>>>>>> subject to review
> >>> >> > > >>>>>>>>>>> =E2=80=8B.=E2=80=8B
> >>> >> > > >>>>>>>>>>> It's worth adopting a similar approach for ZK
> project?
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>> 3. IIRC
> >>> >> > > >>>>>>>>>>> =E2=80=8B (didn't find any page to confirm)=E2=80=
=8B
> >>> >> > > >>>>>>>>>>> , Cassandra project encourages, but not demands,
> that
> >>> >> > > >>> contributors
> >>> >> > > >>>>>>>> also
> >>> >> > > >>>>>>>>>>> upload a patch file to JIRA even in the case of a =
GH
> >>> PR
> >>> >> > > >>>>>>>>>>> =E2=80=8B (as to leave a audit trail, I guess)=E2=
=80=8B
> >>> >> > > >>>>>>>>>>> =E2=80=8B.=E2=80=8B
> >>> >> > > >>>>>>>>>>> Or
> >>> >> > > >>>>>>>>>>> =E2=80=8B,=E2=80=8B
> >>> >> > > >>>>>>>>>>> at
> >>> >> > > >>>>>>>>>>> =E2=80=8B =E2=80=8B
> >>> >> > > >>>>>>>>>>> least
> >>> >> > > >>>>>>>>>>> =E2=80=8B,=E2=80=8B
> >>> >> > > >>>>>>>>>>> =E2=80=8BC* project =E2=80=8B
> >>> >> > > >>>>>>>>>>> leave
> >>> >> > > >>>>>>>>>>> =E2=80=8Bs=E2=80=8B
> >>> >> > > >>>>>>>>>>> up to the contributor
> >>> >> > > >>>>>>>>>>> =E2=80=8Bs=E2=80=8B
> >>> >> > > >>>>>>>>>>> to either open a GH PR or upload the patch file
> >>> >> > > >>>>>>>>>>> =E2=80=8B to JIRA. In fact, Github allows the acce=
ss 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.
> >>> >> > > >>>>>>>>>>> =E2=80=8B
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>> +1 about having a 'paper trail'
> >>> >> > > >>>>>>>>>>> =E2=80=8B of review comments=E2=80=8B
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>> =E2=80=8Bo=E2=80=8B
> >>> >> > > >>>>>>>>>>> n JIRA and
> >>> >> > > >>>>>>>>>>> =E2=80=8B/or=E2=80=8B
> >>> >> > > >>>>>>>>>>> mailing list (I
> >>> >> > > >>>>>>>>>>> =E2=80=8B would=E2=80=8B
> >>> >> > > >>>>>>>>>>> prefer the mailing list tbh). But as Michael and
> >>> Flavio
> >>> >> > pointed
> >>> >> > > >>>>>>> out,
> >>> >> > > >>>>>>>> I
> >>> >> > > >>>>>>>>>>> never seen
> >>> >> > > >>>>>>>>>>> =E2=80=8BGH =E2=80=8B
> >>> >> > > >>>>>>>>>>> PR review
> >>> >> > > >>>>>>>>>>> =E2=80=8B**=E2=80=8B
> >>> >> > > >>>>>>>>>>> comments
> >>> >> > > >>>>>>>>>>> =E2=80=8B**=E2=80=8B
> >>> >> > > >>>>>>>>>>> being written back to JIRA, at least not in Kafka,
> >>> >> Cassandra
> >>> >> > > >>>>>>>>>>> =E2=80=8Bor=E2=80=8B
> >>> >> > > >>>>>>>>>>> Solr projects
> >>> >> > > >>>>>>>>>>> =E2=80=8B, that I have followed more closely.=E2=
=80=8B
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>> Eddie
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>> On Tue, Oct 4, 2016 at 6:40 PM, Michael Han <
> >>> >> > hanm@cloudera.com
> >>> >> > > >>>>
> >>> >> > > >>>>>>>> wrote:
> >>> >> > > >>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>> as long as the opening/closing/commenting all g=
et
> >>> 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 si=
de
> >>> >> (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 lis=
t
> >>> >> > > >>>>>>>>>>>> - If a project has a JIRA instance, any PRs or
> >>> >> *comments* on
> >>> >> > > >>> PRs
> >>> >> > > >>>>>>>>> that
> >>> >> > > >>>>>>>>>>>> include a JIRA ticket ID will trigger an update o=
n
> >>> 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 wi=
ll
> >>> >> provide
> >>> >> > a
> >>> >> > > >>>>>>> clear
> >>> >> > > >>>>>>>>>> history
> >>> >> > > >>>>>>>>>>>> for a given technical issue.
> >>> >> > > >>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>> On Tue, Oct 4, 2016 at 12:06 PM, Flavio Junqueira=
 <
> >>> >> > > >>>> fpj@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_integrati
> >>> on_between_apache_and>
> >>> >> > > >>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>> For now, we do need to upload patches and conver=
ge
> >>> 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 <
> >>> >> hanm@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 fil=
e
> >>> >> uploaded
> >>> >> > to
> >>> >> > > >>>>>>> JIRA.
> >>> >> > > >>>>>>>>>> I've
> >>> >> > > >>>>>>>>>>>>>> checked
> >>> >> > > >>>>>>>>>>>>>> https://cwiki.apache.org/confl
> >>> uence/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.ribeiro@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
> >>> <
> >>> >> > > >>>>>>>> fpj@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.ribeiro@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 i=
t
> >>> now.
> >>> >> > > >>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>> The files were uploaded below, but I will
> >>> create a
> >>> >> > github
> >>> >> > > >>>>>>> repo
> >>> >> > > >>>>>>>>> yet
> >>> >> > > >>>>>>>>>>>>>>> today.
> >>> >> > > >>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>> https://www.dropbox.com/sh/od8bet2574jttm3/
> >>> >> > > >>>>>>>>>>>>>>>> AADv1DXTb8vfyVCmelFbYCEha?dl=3D0
> >>> >> > > >>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>> 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 i=
s
> >>> not
> >>> >> used
> >>> >> > > >>>>>>> anywhere
> >>> >> > > >>>>>>>>> in
> >>> >> > > >>>>>>>>>>>> the
> >>> >> > > >>>>>>>>>>>>>>>>> merge script???
> >>> >> > > >>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>> Cheers,
> >>> >> > > >>>>>>>>>>>>>>>>> Eddie
> >>> >> > > >>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>> On Tue, Sep 20, 2016 at 12:19 PM, Patrick
> Hunt <
> >>> >> > > >>>>>>>> phunt@apache.org
> >>> >> > > >>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>> wrote:
> >>> >> > > >>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>> On Mon, Sep 19, 2016 at 4:11 PM, Benjamin
> Reed
> >>> <
> >>> >> > > >>>>>>>>> breed@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 dif=
fs
> >>> on
> >>> >> > > >>> patches,
> >>> >> > > >>>>>>> the
> >>> >> > > >>>>>>>>> only
> >>> >> > > >>>>>>>>>>>>>>> thing
> >>> >> > > >>>>>>>>>>>>>>>>>>> that changes is that we use svn rather tha=
n
> >>> 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/confl
> >>> uence/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
> >>> <
> >>> >> > > >>>>>>>>> phunt@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 i=
n
> >>> 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 fo=
r
> >>> patch
> >>> >> > > >>>>>>>>>>>>>>> creation/application?
> >>> >> > > >>>>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>>> Chris brought up getting rid of CHANGES.t=
xt
> >>> >> 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 <
> >>> >> > > >>>>>>>>>> breed@apache.org
> >>> >> > > >>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>> wrote:
> >>> >> > > >>>>>>>>>>>>>>>>>>>>
> >>> >> > > >>>>>>>>>>>>>>>>>>>>>> 1) actually in the previous step that w=
as
> >>> 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 no=
w
> >>> 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.
> >>> >> > >
> >>> >> > >
> >>> >> >
> >>> >>
> >>> >
> >>>
> >>
> >>
> >
>

--001a114d78ba18b3e10542fe1067--