Open Stack

Yes, lots of communication through review comments is the best way to do
this. Ideally one person at a time would work on it, but since you can
merge with a rebase, it usually works out okay.

The thing about setting something to "WIP" is that another author actually
can't work on it while it's in WIP state (someone correct me if that's
wrong). Only the original author can set it to "ready for work" again.

Good question.

Also realize that two doc-core members must +2 something before it gets
merged in. Add comments if you don't want two doc-core members to merge
(without setting WIP).
Anne




On Sat, Jan 25, 2014 at 9:07 AM, Jonathan Proulx <jon at jonproulx.com> wrote:

> Hi All,
>
> Thinking specifically of the new upgrades chapter in the ops guide
> (https://review.openstack.org/#/c/68936)...
>
> Usually a single person takes responsibility for a change and reviewer
> comments are sufficient feed back for the author to get everything in
> shape.  I think the new upgrade chapter is going to take several
> people fleshing out different parts before it gets to the "normally"
> reviewable state.
>
> There must be a 'usual' way to do this, but I've not worked in that
> way before.  Seems most straight forward to make a review comment on
> the current patch set saying who's working on what next, then post a
> new patch set which someone else can claim next work on in the same
> way.  The iterate until the content is complete and it builds, then
> remove the "work in progress" note in the commit message and process
> with normal review.
>
> Does that make sense, will it screw up things like 'git blame' (do we
> care if it does), is there some other existing convention for this?
>
> -Jon
>
> _______________________________________________
> Openstack-docs mailing list
> Openstack-docs at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-docs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-docs/attachments/20140125/7d3709f9/attachment.html>