Doc: CG 3.3 separate commits and patches subsections

Doc: CG 3.3 separate commits and patches subsections

[pwm, 2016-02-12 04:12:03]

Please review.  Having separate subsections for Commits and Patches will make it
easier to quickly navigate to one or the other from the table of contents.  And
since they are in fact two different things, separate subsections makes
conceptual sense, perhaps especially for those learning git.

Thanks,
-Paul

[benko.pal, 2016-02-12 12:49:06]

On 2016/02/12 04:12:03, pwm wrote:
> Please review.  Having separate subsections for Commits and Patches will make
it
> easier to quickly navigate to one or the other from the table of contents. 
And
> since they are in fact two different things, separate subsections makes
> conceptual sense, perhaps especially for those learning git.
> 
> Thanks,
> -Paul

do we really need to talk about patches at all in the preferred (i.e.
Rietveld-based) workflow?
(do we really need any more about non preferred ways than "ask on devel"?)

p

[pwm, 2016-02-12 14:01:59]

On 2016/02/12 12:49:06, benko.pal wrote:
> 
> do we really need to talk about patches at all in the preferred (i.e.
> Rietveld-based) workflow?
> (do we really need any more about non preferred ways than "ask on devel"?)

Good question... maybe, maybe not, but I think that deserves a separate
issue/review and maybe a discussion on the dev list.

(Currently anyone contributing who does not have push access (like myself) has
to create patches as described in the "Making Patches" section, after a review
is over, and email them to James or someone with push access who can push them. 
So that section currently documents part of our standard workflow, and just
removing it is not so simple.  I think revising the wording would help, and/or
maybe changing the order of the sections so that the git-cl/Rietveld section
comes first.  But I think that deserves its own issue/review, if not a dev list
discussion.)

[pkx166h, 2016-02-12 14:31:14]

I haven't looked at the proposed changes yet. But with regard to getting into
dicussions about removing things, it is better to just re-organize first. Then
push that. Then have the 'remove' patch later - at least generally. 

It will depend on the type of change of course, but if leaving something in and
just moving it (first) leaves us in no worse a place than before that is usually
the best policy.

It is easier to review as well even if it is a bit more work for the dev doing
the patch.

[benko.pal, 2016-02-12 15:26:00]

On 2016/02/12 14:01:59, pwm wrote:
> On 2016/02/12 12:49:06, benko.pal wrote:
> > 
> > do we really need to talk about patches at all in the preferred (i.e.
> > Rietveld-based) workflow?
> > (do we really need any more about non preferred ways than "ask on devel"?)
> 
> Good question... maybe, maybe not, but I think that deserves a separate
> issue/review and maybe a discussion on the dev list.
> 
> (Currently anyone contributing who does not have push access (like myself) has
> to create patches as described in the "Making Patches" section, after a review
> is over, and email them to James or someone with push access who can push
them.

indeed, I forgot that.

> So that section currently documents part of our standard workflow, and just
> removing it is not so simple.  I think revising the wording would help, and/or
> maybe changing the order of the sections so that the git-cl/Rietveld section
> comes first.  But I think that deserves its own issue/review, if not a dev
list
> discussion.)

fine with me.

p

[pkx166h, 2016-02-20 10:52:19]

author	Paul Morris <paulwmorris@gmail.com>	
	Thu, 11 Feb 2016 20:04:02 +0000 (15:04 -0500)
committer	James Lowe <pkx166h@gmail.com>	
	Sat, 20 Feb 2016 10:17:40 +0000 (10:17 +0000)
commit	74689812a15505b42dca3a93536838a13c7eeb3c