[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 11:51:52 +0200

On Wed, Apr 01, 2020 at 09:34:39AM +0000, Daniel Shahaf wrote:
> Stefan Sperling wrote on Wed, 01 Apr 2020 10:31 +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).
> >
> > 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?
> >
> No, it wouldn't. You committed two new functions without docstring.
> That's a bug in your commit. You are expected to fix it.

I am not questioning that functions need docstrings in principle.
I am just questioning the urgent need to backport such docstrings.

I would understand your objection if these were public API functions.
But these are local static functions, so the docstrings don't serve
the public. They will only be read by SVN developers.

Why is it not good enough if we put these docstrings on trunk without
also having to worry about them becoming part of the next release?

I am just suggesting that you already did enough by just asking for
the docstrings to be added on dev@ in response to my commit. That's
a perfectly reasonable request. I am only questioning the need to add
this request to STATUS also. From the RM perspective every little thing
in STATUS contributes to delaying the release.
Received on 2020-04-01 11:52:11 CEST

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