Re: svn commit: r1817775 - /subversion/site/publish/docs/community-guide/releasing.part.html

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r1817775 - /subversion/site/publish/docs/community-guide/releasing.part.html

Daniel Shahaf-2
[hidden email] 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?

> +++ subversion/site/publish/docs/community-guide/releasing.part.html Mon Dec 11 13:41:35 2017
> @@ -1282,6 +1282,8 @@ A.B with the version you're preparing, e
>  <li><p>Ask someone with appropriate access to add the A.B.x branch to the
>         <tt>svn-role</tt> mergebot.</p></li>
>  

I believe nowadays this managed by infra here:

https://github.com/apache/infrastructure-puppet/blob/deployment/modules/svnqavm_pvm_asf/manifests/init.pp

It currently uses backport.pl.  I think it's up to you whether to have
1.10.x use backport.pl (as 1.9.x does; just add 1.10.x to the for loop
there) or backport.py (the newer / shinier / non-deprecated
equivalent; tools/dist/README.backport has details).

Someone needs to run the 'svn checkout' manually.  I've just done that.
The exact checkout command is documented in machines/svn-qavm2/notes.txt
in the private repository (need to use a trunk client and the svn-master.a.o
hostname).

> +<li><p>Make sure all buildbot builders are building the new release branch.</p></li>

I added 1.10.x to the buildbot config a while ago.  Now would be a good
time to add 1.11.x to it, though. :-)

Cheers,

Daniel
Reply | Threaded
Open this post in threaded view
|

Re: svn commit: r1817775 - /subversion/site/publish/docs/community-guide/releasing.part.html

Stefan
On 11/12/2017 18:15, Daniel Shahaf wrote:
> [hidden email] 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.

Regards,
Stefan


Reply | Threaded
Open this post in threaded view
|

Website 'staging' branch catch-up merges [was: svn commit: r1817775]

Julian Foad-5
Stefan wrote:
> On 11/12/2017 18:15, Daniel Shahaf wrote:
>> [hidden email] 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
Reply | Threaded
Open this post in threaded view
|

Re: Website 'staging' branch catch-up merges [was: svn commit: r1817775]

Stefan
On 13/12/2017 21:28, Julian Foad wrote:

> Stefan wrote:
>> On 11/12/2017 18:15, Daniel Shahaf wrote:
>>> [hidden email] 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