You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@subversion.apache.org by ju...@apache.org on 2017/12/11 13:41:35 UTC
svn commit: r1817775 -
/subversion/site/publish/docs/community-guide/releasing.part.html
Author: julianfoad
Date: Mon Dec 11 13:41:35 2017
New Revision: 1817775
URL: http://svn.apache.org/viewvc?rev=1817775&view=rev
Log:
* publish/docs/community-guide/releasing.part.html
(release-branches): Add a step: 'ensure buildbots build the new branch'.
Suggested by: brane
Modified:
subversion/site/publish/docs/community-guide/releasing.part.html
Modified: subversion/site/publish/docs/community-guide/releasing.part.html
URL: http://svn.apache.org/viewvc/subversion/site/publish/docs/community-guide/releasing.part.html?rev=1817775&r1=1817774&r2=1817775&view=diff
==============================================================================
--- subversion/site/publish/docs/community-guide/releasing.part.html (original)
+++ 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>
+<li><p>Make sure all buildbot builders are building the new release branch.</p></li>
+
</ul>
</div> <!-- release-branches -->
Re: Website 'staging' branch catch-up merges [was: svn commit:
r1817775]
Posted by Stefan <lu...@posteo.de>.
On 13/12/2017 21:28, Julian Foad wrote:
> Stefan wrote:
>> On 11/12/2017 18:15, Daniel Shahaf wrote:
>>> julianfoad@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
Website 'staging' branch catch-up merges [was: svn commit: r1817775]
Posted by Julian Foad <ju...@apache.org>.
Stefan wrote:
> On 11/12/2017 18:15, Daniel Shahaf wrote:
>> julianfoad@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
Website 'staging' branch catch-up merges [was: svn commit: r1817775]
Posted by Julian Foad <ju...@apache.org>.
Stefan wrote:
> On 11/12/2017 18:15, Daniel Shahaf wrote:
>> julianfoad@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
Re: svn commit: r1817775 -
/subversion/site/publish/docs/community-guide/releasing.part.html
Posted by Stefan <lu...@posteo.de>.
On 11/12/2017 18:15, Daniel Shahaf wrote:
> julianfoad@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.
Regards,
Stefan
Re: svn commit: r1817775 -
/subversion/site/publish/docs/community-guide/releasing.part.html
Posted by Stefan <lu...@posteo.de>.
On 11/12/2017 18:15, Daniel Shahaf wrote:
> julianfoad@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.
Regards,
Stefan
Re: svn commit: r1817775 -
/subversion/site/publish/docs/community-guide/releasing.part.html
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
julianfoad@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?
> +++ 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
Re: svn commit: r1817775 -
/subversion/site/publish/docs/community-guide/releasing.part.html
Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
julianfoad@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?
> +++ 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