[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: Daniel Shahaf <d.s_at_daniel.shahaf.name>
Date: Wed, 1 Apr 2020 11:43:05 +0000

Stefan Sperling wrote on Wed, 01 Apr 2020 11:51 +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.

Adding something to STATUS does not signify an "urgent need to backport"
it and does not make it a release blocker.

Thanks for addressing the commit review.

However, I can't end this mail without saying that I feel your conduct
in these threads has been wanting, even hostile.

Daniel
Received on 2020-04-01 13:43:21 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.