Home | About | Sematext search-lucene.com search-hadoop.com
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB
 Search Hadoop and all its subprojects:

Switch to Plain View
Kafka >> mail # dev >> git workflow


+
Jay Kreps 2013-01-02, 21:45
+
Jun Rao 2013-01-03, 16:18
+
Joe Stein 2013-01-05, 04:35
+
Jay Kreps 2013-01-05, 05:30
+
Joe Stein 2013-01-05, 05:41
+
David Arthur 2013-01-05, 17:38
+
Joe Stein 2013-01-05, 18:43
+
Joe Stein 2013-01-05, 19:02
+
Joe Stein 2013-01-06, 05:36
+
Derek Chen-Becker 2013-01-07, 05:52
+
David Arthur 2013-01-07, 14:45
+
Derek Chen-Becker 2013-01-07, 15:06
+
Jay Kreps 2013-01-07, 16:07
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/commenting, as mentioned, are very nice, and it would be a
shame to not be able to use them.

Derek
On Mon, Jan 7, 2013 at 9:06 AM, Jay Kreps <[EMAIL PROTECTED]> wrote:

> 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
> request? Github has lots of tools for seeing diffs, commenting on code, etc
> so this would be fantastic. Is that considered bad form? We could just have
> the JIRA point to the github url...
>
> -Jay
>
>
> On Mon, Jan 7, 2013 at 7:05 AM, Derek Chen-Becker <[EMAIL PROTECTED]>
> wrote:
>
> > 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" <[EMAIL PROTECTED]> wrote:
> >
> > > 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 everyone because
> the
> > >> diff format was unable to convey things like "delete this binary file
> > and
> > >> add this other one".
> > >>
> > >> Derek
> > >>
> > >>
> > >> On Sat, Jan 5, 2013 at 10:35 PM, Joe Stein <[EMAIL PROTECTED]>
> wrote:
> > >>
> > >>  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 think there are
> > pros
> > >>> and cons to this.
> > >>>
> > >>> If folks make good commit messages then this is great however I
> prefer
> > >>> the
> > >>> git diff patch myself from contribs because then I can commit with a
> > >>> message for the JIRA ticket and the reviewer
> > >>>
> > >>> thoughts on git diff vs git format-patch ?
> > >>>
> > >>> I updated the wiki to deal with the error i encountered since it
> > already
> > >>> references format-patch I but think we should have some consensus for
> > >>> contributors and how they should proceed and how we should too.
> > >>>
> > >>> On Sat, Jan 5, 2013 at 2:02 PM, Joe Stein <[EMAIL PROTECTED]>
> wrote:
> > >>>
> > >>>  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 incubation URL was wrong on the README so I walked
> > through
> > >>>> the contributor steps and everything worked just perfectly
> > >>>>
> > >>>> the only thing I did notice is that the commit message I put in "as
> a
> > >>>> contributor" was part of the patch and everything so I think we
> should
> > >>>>
> > >>> call
> > >>>
> > >>>> out some guidelines for making commit messages, like always put the
> > >>>> KAFKA-XYZ in the message so when we review and push everything goes
> in
> > >>>>
> > >>> how
> > >>>
> > >>>> we expected if we made the change and committed ourselves.

*Derek Chen-Becker*
*Precog Lead Infrastructure Engineer*
[EMAIL PROTECTED]
303-752-1700

 
+
David Arthur 2013-01-02, 22:17
+
Jay Kreps 2013-01-03, 00:03
+
David Arthur 2013-01-03, 00:26
NEW: Monitor These Apps!
elasticsearch, apache solr, apache hbase, hadoop, redis, casssandra, amazon cloudwatch, mysql, memcached, apache kafka, apache zookeeper, apache storm, ubuntu, centOS, red hat, debian, puppet labs, java, senseiDB