zsh-workers
 help / color / mirror / code / Atom feed
From: Daniel Shahaf <d.s@daniel.shahaf.name>
To: Zsh hackers list <zsh-workers@zsh.org>
Subject: Re: [PATCHv1] [long] improvements to limit/ulimit API and doc
Date: Fri, 27 Nov 2020 17:16:38 +0000	[thread overview]
Message-ID: <20201127171638.GE26720@tarpaulin.shahaf.local2> (raw)
In-Reply-To: <20201125064443.a6zdrwka2ajkgb2t@chazelas.org>

Stephane Chazelas wrote on Wed, Nov 25, 2020 at 06:44:43 +0000:
> 2020-11-25 00:35:12 +0000, Daniel Shahaf:
> [...]
> > > A few issues addressed:
> > > 
> > 
> > This patch is over 1k lines long and makes multiple independent changes.
> > 
> > Could you please split this into one patch per logical change?  That
> > would make it easier to review, both now, and in the future should
> > a regression be bisected to it.
> [...]
> 
> Hi Daniel,
> 
> thanks for having looking into it.
> 
> They're not independent, except maybe for the "limit"/"unlimit"
> now back in csh which is a 5 code line change.
> 

*nod*

> Chunks of the code and doc have been rewritten to address
> those. Separating out the changes would mean rewriting the code
> several times which would be more effort for me and reviewers,
> mostly wasted if we're only keeping the last iteration.

How so?  In v2 2/2's log message I see, for starters, several bullet
points about documentation-only bugs, and in the .c diff the
showlimitvalue() stands out as _prima facie_ independent of the rest.

I don't see how _splitting_ those involves a _rewrite_.  Splitting is
fairly easy,¹ and I don't think it'd be a "waste" of time.  On the
contrary, I think it'd be a O(1) effort for O(N) gain (split it once and
then, even years from now, anyone who reviews the history will have a
easier time).  Moreover, smaller diff can help ensure that each change
is tested and help catch unintentional behaviour changes (always a risk
in refactorings).

I do agree that a single logical change that happens to fix a dozen
interdependent bugs needn't be split, but I don't see how that's the
case here.  Enlighten me ☺

> But maybe before looking in detail at the code, we can discuss
> whether the change in API makes sense.

Seems to make sense, going by the log message.  Really, the only part
that jumped out at me was changing the behaviour of "KB" on input from
error to "1000 bytes".

Cheers,

Daniel

¹ Stephane: I elaborated offlist recently on splitting.



  reply	other threads:[~2020-11-27 17:16 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-11-23 21:49 Stephane Chazelas
2020-11-25  0:35 ` Daniel Shahaf
2020-11-25  6:44   ` Stephane Chazelas
2020-11-27 17:16     ` Daniel Shahaf [this message]
2020-11-26  6:57   ` [PATCHv2 1/2] [long] improvements to limit/ulimit API and doc ((un)limit in csh emulation) Stephane Chazelas
2020-11-25 23:43 ` [PATCHv1] [long] improvements to limit/ulimit API and doc Oliver Kiddle
2020-11-26 20:14   ` [PATCH] ulimit option completions using ulimit -a output Stephane Chazelas
2020-11-27  7:13     ` Stephane Chazelas
2020-11-27  8:15       ` Felipe Contreras
2020-11-27 12:19       ` Oliver Kiddle
2021-03-27 21:25         ` Lawrence Velázquez
2021-04-03 14:57           ` Lawrence Velázquez
2021-04-10 20:11             ` Lawrence Velázquez
2021-04-13 14:35     ` Daniel Shahaf
2021-05-09 20:37       ` Lawrence Velázquez
2021-05-11 19:05         ` Stephane Chazelas
2020-11-26 20:58   ` [PATCHv2 2/2] [long] improvements to limit/ulimit API and doc (the rest) Stephane Chazelas
2020-11-27 16:39     ` Daniel Shahaf
2020-11-27 20:13       ` Stephane Chazelas
2020-11-27 20:36         ` Daniel Shahaf
2020-11-28  6:52           ` zsh coding style (was about a limit patch review) Stephane Chazelas
2020-12-01 16:47             ` Daniel Shahaf
2020-11-28  8:16         ` [PATCHv3 2/2] [long] improvements to limit/ulimit API and doc (the rest) Stephane Chazelas
2021-03-27 21:21           ` Lawrence Velázquez
2021-03-31 18:06             ` Stephane Chazelas
2020-11-26 11:19 ` [PATCHv1] [long] improvements to limit/ulimit API and doc Jun T
2020-11-26 13:55   ` Stephane Chazelas
2020-11-26 15:22     ` Jun. T
2020-11-26 17:23       ` Stephane Chazelas
2020-11-27 18:24         ` Jun. T
2020-11-27 18:34           ` Daniel Shahaf
2020-11-27 20:46           ` Stephane Chazelas

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201127171638.GE26720@tarpaulin.shahaf.local2 \
    --to=d.s@daniel.shahaf.name \
    --cc=zsh-workers@zsh.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/zsh/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).