zookeeper-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Han <h...@cloudera.com>
Subject Re: [VOTE] move Apache Zookeeper to git
Date Wed, 26 Oct 2016 17:53:07 GMT
The comment bridging should be fixed now - see INFRA-12752 for 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 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.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, 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 <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 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 <
>> 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 wikis 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/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 <hanm@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 <fpj@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.ribeiro@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 <hanm@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
<
>> > 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_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 <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 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.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 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 <
>> > > >>> 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 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 <
>> > > >>>> 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 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 <
>> > > >>>>> breed@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.

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message