I think we forgot to commit the new BrokerState file.
On Tue, May 6, 2014 at 4:36 PM, wrote:
> Repository: kafka
> Updated Branches:
> refs/heads/trunk 44c39c4ea -> 9b6bf4078
>
>
> kafka-1384; Log Broker state; patched by Timothy Chen; reviewed by Joel
> Koshy and Jun Rao
>
>
> Project: http:
That is the right url. What is the error you see?
There is no access control in the current version of Kafka, but there are
ideas being discussed on the mailing list and a wiki in progress
https://cwiki.apache.org/confluence/display/KAFKA/Security
Thanks,
Neha
On Sep 12, 2013 7:21 AM, "Martin Men
If it's mandated by Apache rules, I understand, but I do think that
GitHub/git provide improved workflow over SVN + patch. Apache appears to be
mirroring to GitHub anyway:
https://github.com/apache/kafka
You even have a pull request (5 months old) already. Things like pull
request review/commenti
The reason we take diffs is because traditionally the mandatory Apache
toolchain is svn+jira+patch/diff. When we were on github of course we used
that.
I'm actually not sure of the Apache rules here. Can we just directly accept
github pull requests? I.e. you fork the apache mirror and send a pull
It makes it easier for a non-committer to contribute via email, but with
publicly available repos (a la GitHub) it's just as easy to merge from a
remote (and doesn't require contorting through hoops for certain scenarios).
On Jan 7, 2013 7:45 AM, "David Arthur" wrote:
> Diff/patch makes it easy f
Diff/patch makes it easy for non-committer to contribute.
On 1/7/13 12:52 AM, Derek Chen-Becker wrote:
Although I haven't contributed much here yet, I did want to ask: why
diff/patch and not pull/merge? I know my work on getting the SBT build
working with a modern SBT was quite a headache for ev
Although I haven't contributed much here yet, I did want to ask: why
diff/patch and not pull/merge? I know my work on getting the SBT build
working with a modern SBT was quite a headache for everyone because the
diff format was unable to convey things like "delete this binary file and
add this othe
ok with some more research today it seems the difference and issues I was
having was from the patch being made with
git diff vs git format-patch
with git diff (which is how the patch I was reviewing was made) you apply
doing "patch -p1 < patch"
no commits messages are preserved with git diff. I
Ok, I figured out the problem. The problem was with the patch format so I
will take care of that ... the patch is minor enough I will take the code
changes and whip up a new patch and let Maxime know (assuming that patch is
good) about how to make a Kafka patch moving forward).
I noticed the incu
that did not work either
I can't even get the patch to apply from the latest trunk because of this
message of patch without email
so the patch is here
https://issues.apache.org/jira/secure/attachment/12563266/KAFKA-133.patch
I go through the steps on the git workflow
git clone https://git-wip-u
You can amend the previous commit (as long as you havent pushed) with an
author like "git --amend --author='...'"
On Saturday, January 5, 2013, Joe Stein wrote:
> I am getting the no email after doing
>
> git am --signoff < xyz.patch
>
> so nothing gets in to commit to set the author :(
>
> On Sa
I am getting the no email after doing
git am --signoff < xyz.patch
so nothing gets in to commit to set the author :(
On Sat, Jan 5, 2013 at 12:30 AM, Jay Kreps wrote:
> I have but I don't really know why. This format worked for me:
> git commit --author='Bertrand Russell '
>
>
> On Fri, Jan
I have but I don't really know why. This format worked for me:
git commit --author='Bertrand Russell '
On Fri, Jan 4, 2013 at 8:35 PM, Joe Stein wrote:
> I started following this so far really helpful thanks!!
>
> Running into some issues reviewing someone's patch getting "Patch does not
> ha
I started following this so far really helpful thanks!!
Running into some issues reviewing someone's patch getting "Patch does not
have a valid e-mail address." googling to figure out what is wrong figure I
mention here if anyone bumped into this yet
thnx
On Thu, Jan 3, 2013 at 11:17 AM, Jun Rao
Thanks for documenting this. Could you also add how to resolve conflicts
during rebase?
Jun
On Wed, Jan 2, 2013 at 1:45 PM, Jay Kreps wrote:
> I don't know about other people but I find git kind of confusing. I thought
> it would be useful to try to document the normal workflow for different us
On 1/2/13 7:03 PM, Jay Kreps wrote:
David,
So are there any changes you think we should make to the instructions? I
think what I wrote matches what you are describing.
I think what you've got in the wiki is great (didn't read it before
sending my message earlier - oops)
The git patch support d
David,
So are there any changes you think we should make to the instructions? I
think what I wrote matches what you are describing.
The git patch support does seem better since I think it maintains
authorship and allows you to transmit multiple commits as a single file (if
needed).
-Jay
On Wed
Here is what I've been doing
* Clone Kafka locally (git clone git://github.com/apache/kafka.git)
* Create feature branch off of trunk (git branch KAFKA-657)
* Do work on the feature branch
* Rebase from trunk (git rebase trunk). This minimizes or eliminates any
conflicts when people try to apply
If it's not working, you can add a comment at this jira
https://issues.apache.org/jira/browse/INFRA-5587
We also have a separate jira to move from svn to git:
https://issues.apache.org/jira/browse/INFRA-5111
Thanks,
Jun
On Mon, Dec 3, 2012 at 9:10 AM, Jay Kreps wrote:
> I don't think our git
Yes, we are working on it. We will notify everyone once the git repo is ready.
Thanks,
Neha
On Thu, Nov 29, 2012 at 7:25 AM, David Arthur wrote:
> Has there ever been discussion of moving to Git?
>
> -David
Not sure what infra prefers, new ticket makes sense to me.
By move the svn location, you mean move git as part of graduation, right?
On 11/28/2012 01:28 AM, Jun Rao wrote:
> Chris,
>
> I plan to submit an infra ticket for the post graduation items. One of the
> subtasks will be to move our svn r
21 matches
Mail list logo
