You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@crunch.apache.org by Gabriel Reid <ga...@gmail.com> on 2014/01/16 10:05:09 UTC
Editing the Crunch User Guide
Hi Josh (and others),
I was wondering if you had any preferences on how we go about handling
changes to the User Guide (and website content in general). Is there a
preference to go with a review-then-commit workflow, or
commit-then-review (or something else)?
I'm assuming that at this point that there won't be any huge major
additions to it, but I figure it wouldn't be bad to have a general
agreement on how we want to handle editing it. FWIW, up until now the
(very minor) changes I've made have just been going straight in
without any review.
- Gabriel
Re: Editing the Crunch User Guide
Posted by Josh Wills <jw...@cloudera.com>.
On Thu, Jan 16, 2014 at 1:42 PM, Gabriel Reid <ga...@gmail.com>wrote:
> On Thu, Jan 16, 2014 at 10:09 PM, Josh Wills <jw...@cloudera.com> wrote:
> > On Thu, Jan 16, 2014 at 12:40 PM, Gabriel Reid <gabriel.reid@gmail.com
> >wrote:
> > I think it's worthwhile to add small sections
> > incrementally-- one on unit testing, one on Scrunch, and some more code
> > examples in places (like for the HBase section). My thought was that
> > posting a giant markdown file for the new user guide wasn't a good use of
> > my/everyone else's time, but posting diffs first should cut down on
> > conflicts. Did you have sections you were planning to add, too?
> >
>
> Ok, sounds good.
>
> The main thing that I was thinking of adding in the short term was
> some explanation around holding onto references (i.e.
> PType#getDetachedValue), as well as potentially adding some stuff on
> unit testing and/or integration testing (although if you're working on
> that already I'll happily leave it over to you!)
>
+1 to the getDetachedValue stuff-- that's important. I'll get a
unit/integration testing draft posted as a patch by Sunday.
>
>
> >
> >>
> >>
> >> On Thu, Jan 16, 2014 at 7:12 PM, Josh Wills <jw...@cloudera.com>
> wrote:
> >> > I'm still good with commit-then-review for the website, although we
> have
> >> > slowly moved towards more reviews of code over time as the project has
> >> > grown.
> >> >
> >> >
> >> > On Thu, Jan 16, 2014 at 1:05 AM, Gabriel Reid <gabriel.reid@gmail.com
> >> >wrote:
> >> >
> >> >> Hi Josh (and others),
> >> >>
> >> >> I was wondering if you had any preferences on how we go about
> handling
> >> >> changes to the User Guide (and website content in general). Is there
> a
> >> >> preference to go with a review-then-commit workflow, or
> >> >> commit-then-review (or something else)?
> >> >>
> >> >> I'm assuming that at this point that there won't be any huge major
> >> >> additions to it, but I figure it wouldn't be bad to have a general
> >> >> agreement on how we want to handle editing it. FWIW, up until now the
> >> >> (very minor) changes I've made have just been going straight in
> >> >> without any review.
> >> >>
> >> >> - Gabriel
> >> >>
> >> >
> >> >
> >> >
> >> > --
> >> > Director of Data Science
> >> > Cloudera <http://www.cloudera.com>
> >> > Twitter: @josh_wills <http://twitter.com/josh_wills>
> >>
> >
> >
> >
> > --
> > Director of Data Science
> > Cloudera <http://www.cloudera.com>
> > Twitter: @josh_wills <http://twitter.com/josh_wills>
>
--
Director of Data Science
Cloudera <http://www.cloudera.com>
Twitter: @josh_wills <http://twitter.com/josh_wills>
Re: Editing the Crunch User Guide
Posted by Gabriel Reid <ga...@gmail.com>.
On Thu, Jan 16, 2014 at 10:09 PM, Josh Wills <jw...@cloudera.com> wrote:
> On Thu, Jan 16, 2014 at 12:40 PM, Gabriel Reid <ga...@gmail.com>wrote:
> I think it's worthwhile to add small sections
> incrementally-- one on unit testing, one on Scrunch, and some more code
> examples in places (like for the HBase section). My thought was that
> posting a giant markdown file for the new user guide wasn't a good use of
> my/everyone else's time, but posting diffs first should cut down on
> conflicts. Did you have sections you were planning to add, too?
>
Ok, sounds good.
The main thing that I was thinking of adding in the short term was
some explanation around holding onto references (i.e.
PType#getDetachedValue), as well as potentially adding some stuff on
unit testing and/or integration testing (although if you're working on
that already I'll happily leave it over to you!)
>
>>
>>
>> On Thu, Jan 16, 2014 at 7:12 PM, Josh Wills <jw...@cloudera.com> wrote:
>> > I'm still good with commit-then-review for the website, although we have
>> > slowly moved towards more reviews of code over time as the project has
>> > grown.
>> >
>> >
>> > On Thu, Jan 16, 2014 at 1:05 AM, Gabriel Reid <gabriel.reid@gmail.com
>> >wrote:
>> >
>> >> Hi Josh (and others),
>> >>
>> >> I was wondering if you had any preferences on how we go about handling
>> >> changes to the User Guide (and website content in general). Is there a
>> >> preference to go with a review-then-commit workflow, or
>> >> commit-then-review (or something else)?
>> >>
>> >> I'm assuming that at this point that there won't be any huge major
>> >> additions to it, but I figure it wouldn't be bad to have a general
>> >> agreement on how we want to handle editing it. FWIW, up until now the
>> >> (very minor) changes I've made have just been going straight in
>> >> without any review.
>> >>
>> >> - Gabriel
>> >>
>> >
>> >
>> >
>> > --
>> > Director of Data Science
>> > Cloudera <http://www.cloudera.com>
>> > Twitter: @josh_wills <http://twitter.com/josh_wills>
>>
>
>
>
> --
> Director of Data Science
> Cloudera <http://www.cloudera.com>
> Twitter: @josh_wills <http://twitter.com/josh_wills>
Re: Editing the Crunch User Guide
Posted by Josh Wills <jw...@cloudera.com>.
On Thu, Jan 16, 2014 at 12:40 PM, Gabriel Reid <ga...@gmail.com>wrote:
> Ok, maybe we should go with the same kind of thing as with the core
> code - post a patch for big changes, and just go for it if it's just a
> little spelling or punctuation fix or similar. My main concern is/was
> not getting into major merge conflicts if there are two people doing
> writing a section at the same time, which seems very unlikely given
> the excellent state that the guide is already in.
>
No, that's a fair point. I think it's worthwhile to add small sections
incrementally-- one on unit testing, one on Scrunch, and some more code
examples in places (like for the HBase section). My thought was that
posting a giant markdown file for the new user guide wasn't a good use of
my/everyone else's time, but posting diffs first should cut down on
conflicts. Did you have sections you were planning to add, too?
>
>
> On Thu, Jan 16, 2014 at 7:12 PM, Josh Wills <jw...@cloudera.com> wrote:
> > I'm still good with commit-then-review for the website, although we have
> > slowly moved towards more reviews of code over time as the project has
> > grown.
> >
> >
> > On Thu, Jan 16, 2014 at 1:05 AM, Gabriel Reid <gabriel.reid@gmail.com
> >wrote:
> >
> >> Hi Josh (and others),
> >>
> >> I was wondering if you had any preferences on how we go about handling
> >> changes to the User Guide (and website content in general). Is there a
> >> preference to go with a review-then-commit workflow, or
> >> commit-then-review (or something else)?
> >>
> >> I'm assuming that at this point that there won't be any huge major
> >> additions to it, but I figure it wouldn't be bad to have a general
> >> agreement on how we want to handle editing it. FWIW, up until now the
> >> (very minor) changes I've made have just been going straight in
> >> without any review.
> >>
> >> - Gabriel
> >>
> >
> >
> >
> > --
> > Director of Data Science
> > Cloudera <http://www.cloudera.com>
> > Twitter: @josh_wills <http://twitter.com/josh_wills>
>
--
Director of Data Science
Cloudera <http://www.cloudera.com>
Twitter: @josh_wills <http://twitter.com/josh_wills>
Re: Editing the Crunch User Guide
Posted by Gabriel Reid <ga...@gmail.com>.
Ok, maybe we should go with the same kind of thing as with the core
code - post a patch for big changes, and just go for it if it's just a
little spelling or punctuation fix or similar. My main concern is/was
not getting into major merge conflicts if there are two people doing
writing a section at the same time, which seems very unlikely given
the excellent state that the guide is already in.
On Thu, Jan 16, 2014 at 7:12 PM, Josh Wills <jw...@cloudera.com> wrote:
> I'm still good with commit-then-review for the website, although we have
> slowly moved towards more reviews of code over time as the project has
> grown.
>
>
> On Thu, Jan 16, 2014 at 1:05 AM, Gabriel Reid <ga...@gmail.com>wrote:
>
>> Hi Josh (and others),
>>
>> I was wondering if you had any preferences on how we go about handling
>> changes to the User Guide (and website content in general). Is there a
>> preference to go with a review-then-commit workflow, or
>> commit-then-review (or something else)?
>>
>> I'm assuming that at this point that there won't be any huge major
>> additions to it, but I figure it wouldn't be bad to have a general
>> agreement on how we want to handle editing it. FWIW, up until now the
>> (very minor) changes I've made have just been going straight in
>> without any review.
>>
>> - Gabriel
>>
>
>
>
> --
> Director of Data Science
> Cloudera <http://www.cloudera.com>
> Twitter: @josh_wills <http://twitter.com/josh_wills>
Re: Editing the Crunch User Guide
Posted by Josh Wills <jw...@cloudera.com>.
I'm still good with commit-then-review for the website, although we have
slowly moved towards more reviews of code over time as the project has
grown.
On Thu, Jan 16, 2014 at 1:05 AM, Gabriel Reid <ga...@gmail.com>wrote:
> Hi Josh (and others),
>
> I was wondering if you had any preferences on how we go about handling
> changes to the User Guide (and website content in general). Is there a
> preference to go with a review-then-commit workflow, or
> commit-then-review (or something else)?
>
> I'm assuming that at this point that there won't be any huge major
> additions to it, but I figure it wouldn't be bad to have a general
> agreement on how we want to handle editing it. FWIW, up until now the
> (very minor) changes I've made have just been going straight in
> without any review.
>
> - Gabriel
>
--
Director of Data Science
Cloudera <http://www.cloudera.com>
Twitter: @josh_wills <http://twitter.com/josh_wills>