You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Daniel Shahaf <d....@daniel.shahaf.name> on 2018/10/31 20:08:51 UTC

Re: svn commit: r1845378 - /subversion/trunk/CHANGES

brane@apache.org wrote on Wed, 31 Oct 2018 19:42 +0000:
> +++ subversion/trunk/CHANGES Wed Oct 31 19:42:05 2018
> @@ -26,6 +26,7 @@ https://svn.apache.org/repos/asf/subvers
> +    * Storing passowrds in plain text on disk is disabled by default (r1845377)

Typo "passwords"

Other issue: In the three months centered on the 1.12.0 release we'll be
supporting 1.9, 1.10, 1.11, 1.12, and trunk in parallel, so I think we
should reduce the CHANGES management effort.  To take this commit as an
example, while brane added a line to the 1.12 CHANGES, the RM's of 1.9,
1.10, 1.11 will have to copy it manually.  That adds up.

The first idea that comes to mind is to put the CHANGES info in the log
message (as I advised rpluem@ yesterday to do), whence 'release.py
write-changelog' can pick it automatically.  Other approaches are
possible, of course; I don't mind which one is chosen¹, but I do think
we should do plan ahead and make sure we can generate the CHANGES
sections for stable lines with as little effort as possible.

Cheers,

Daniel

¹ Though write-changelog has already been implemented, and is really
very sensible, so I don't see any reason to switch away from it.

Re: svn commit: r1845378 - /subversion/trunk/CHANGES

Posted by Daniel Shahaf <d....@daniel.shahaf.name>.
Branko Čibej wrote on Wed, 31 Oct 2018 21:10 +0100:
> On 31.10.2018 21:08, Daniel Shahaf wrote:
> > Other issue: In the three months centered on the 1.12.0 release we'll be
> > supporting 1.9, 1.10, 1.11, 1.12, and trunk in parallel, so I think we
> > should reduce the CHANGES management effort.  To take this commit as an
> > example, while brane added a line to the 1.12 CHANGES, the RM's of 1.9,
> > 1.10, 1.11 will have to copy it manually.  That adds up.
> 
> Nope, they will not; this change will not be backported.

I said, to take that commit "as an example".  My point was that we need
to think about reducing the CHANGES maintenance overhead; whether
any particular commit does or does not require backporting is besides
that point.

Re: svn commit: r1845378 - /subversion/trunk/CHANGES

Posted by Branko Čibej <br...@apache.org>.
On 31.10.2018 21:08, Daniel Shahaf wrote:
> brane@apache.org wrote on Wed, 31 Oct 2018 19:42 +0000:
>> +++ subversion/trunk/CHANGES Wed Oct 31 19:42:05 2018
>> @@ -26,6 +26,7 @@ https://svn.apache.org/repos/asf/subvers
>> +    * Storing passowrds in plain text on disk is disabled by default (r1845377)
> Typo "passwords"

Thanks, will fix.

> Other issue: In the three months centered on the 1.12.0 release we'll be
> supporting 1.9, 1.10, 1.11, 1.12, and trunk in parallel, so I think we
> should reduce the CHANGES management effort.  To take this commit as an
> example, while brane added a line to the 1.12 CHANGES, the RM's of 1.9,
> 1.10, 1.11 will have to copy it manually.  That adds up.

Nope, they will not; this change will not be backported.

-- Brane