[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: svn commit: r1875921 - in /subversion/trunk: subversion/include/ subversion/include/private/ subversion/libsvn_fs_fs/ subversion/svnadmin/ subversion/tests/cmdline/ subversion/tests/libsvn_fs_fs/ tools/client-side/

From: Stefan Sperling <stsp_at_elego.de>
Date: Wed, 1 Apr 2020 10:31:22 +0200

On Wed, Apr 01, 2020 at 01:43:28AM +0000, Daniel Shahaf wrote:
> Daniel Shahaf wrote on Tue, 31 Mar 2020 09:23 +00:00:
> > Please add a docstring.
>
> I've gone ahead and added this to STATUS so it doesn't slip through any
> cracks. Feel free to remove the -0 vote once it's been addressed (you
> needn't round-trip through me for this).

Isn't a discussion of docstrings for local functions in a backport
nomination too much distraction? Adding comments has no effect on code
correctness, and they would have to be added on trunk first anyway.

Higlighting bugs and missing things is of course important, but this is a
relatively small detail that could just be dealt with on the side.
From the RM point of view, every objection we add to STATUS takes up
reviewers' time, even if it's "just" a -0.

Wouldn't it be enough if you or someone else added docstrings on trunk
at some convenient point in time in the future, and then nominated that
revision as a regular follow-up change if it's deemed important enough?

Or do you actually need the docstrings to make sense of the code?
If that was the case, then why not vote -1?
Received on 2020-04-01 10:31:35 CEST

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.