Open Stack

Makes sense, Guess we'll need to wait for Tom to land & weigh in then
as he's the author in question.   What I typically do if I want to get
a review up but not to merge yet is to give myself -1 and leave a
note, didn't really know WIP was an official state something could be
in.

-Jon

On Sat, Jan 25, 2014 at 10:27 AM, Anne Gentle <anne at openstack.org> wrote:
> 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
>
>