On Wed, Apr 01, 2020 at 11:43:05AM +0000, Daniel Shahaf wrote:
> 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, we are simply having some disagreements over priorities of things
affecting the release process. I don't intend to be hostile towards you.
FWIW, "You are expected to fix it" could also be interpreted as hostile.
It's a direct order from you directed at me, telling me what I should do.
I would feel a lot better if you did work to improve upon existing work
and then showed me "this is how you could have done it, what do you think?"
instead of making suggestion after suggestion and expecting results from me.
If it makes you feel any better, I'd be happy to stop voluteering for the
RM role, and let you or someone else worry about the release going forward.
Received on 2020-04-01 13:58:37 CEST