On 13/12/2017 21:28, Julian Foad wrote:
> Stefan wrote:
>> On 11/12/2017 18:15, Daniel Shahaf wrote:
>>> julianfoad_at_apache.org wrote on Mon, 11 Dec 2017 13:41 +0000:
>>>> Modified:
>>>> subversion/site/publish/docs/community-guide/releasing.part.html
>>> Could you backport this to staging/ so future changes to staging don't
>>> merge conflict when they are published?
>> Since I was working on the site right now, I took the liberty and
>> quickly did it in r1817860.
>
> Thanks, Stefan.
>
> We discussed on IRC about this. I see 'staging' as being a development
> branch and 'publish' as being the trunk, and changes being made
> directly on the 'trunk' or on the branch according to how the
> developer feels about needing or not needing a staging point. From
> that point of view, this merge would be a catch-up merge and would be
> the normal expected practice for anyone working on the staging branch
> to do from time to time and immediately before promoting changes to
> 'publish'.
>
> However that was just my assumption -- we haven't established that
> work flow as a community.
>
> Various other ideas and points were made on IRC -- see the log,
> starting here, 25 mins long:
> http://colabti.org/irclogger/irclogger_log/svn-dev?date=2017-12-11#l98
>
> - Julian
Personally I think the model you are describing is fine.
In practice I however do catch-up merges myself directly whenever I
commit anything to publish, so to provide the next developer with a
clean environment without shifting workload from my shoulders onto his;
i.e. having him to do the catch-up merge and potentially resolve and
deal with merge conflicts which my commit would have caused --- in the
end I, who did the commit in the first place, should know best how to
resolve any potential conflict and therefore it should be the least work
to do it myself. Therefore, I wouldn't set the expectation you phrases
(i.e. "[...] catch-up merge [...] would be the normal expected practice
for anyone working on the staging branch to do [...] immediately before
promoting changes to 'publish'). Otherwise someone following the same
practice as I do would have to do two catch-up merges plus the
cherry-pick merge to publish (i.e. catch-up merge from publish to
staging / cherry pick merge from staging to publish (with potentially
additional direct changes to publish / catch-up merge from publish of
the additional direct changes to publish).
That said, I've got no issue with keeping these direct catch-up merges
completely up to the decision of the developer and I'm certainly fine
doing the catch-up merges of commits done by other developers whenever I
do a catch-up merge myself.
Regards,
Stefan
Received on 2017-12-14 00:46:16 CET