'td' vs sys/fs/nfsserver/

[Alexander Leidinger]

Quoting Konstantin Belousov <kib at freebsd.org> (from Wed, 6 Mar 2019  
16:50:31 +0200):

> On Wed, Mar 06, 2019 at 02:25:16PM +0100, Alexander Leidinger via  
> freebsd-fs wrote:
>> Hi,
>>
>> About code churn:
>>  - Does it matter for an end user if the code repo gets bigger?
>>  - Will there be an (indirect) benefit for an end user (like code which is
>> more easy to understand and as such less bugs while changing something or
>> more people willing to touch/improve/extend)?
> Why does it matter how this affects end users ?

We're not making changes for the sake of making changes. We make  
changes to improve something. And in the end, users are the ones who  
shall benefit from improvements (be it directly by bug fixing / new  
features, or indirectl by code quality improvements which prevent some  
bugs in the future).

>>  - How many developers mirror the repo and are at the same time space
>> limited? = Does it matter for us developers?
> Why does it matter at all?

It was one of the points people complained about in the past in such  
situations.

>>  - How many developers are network transfer limited and what is the amount
>> of expected change compared to a clang / openssl /.... import?
>>  - At which "churn-factor" does it not make sense anymore (and why)?
> Repo churn is a situation where developers get significant amount
> of mail with changes that they must read, but which does not change
> functionality. The changes must be read to understand the current state
> of the code after the change, to see that there is no un-intentional or
> bad intentional chunks despite the the commit message.
>
> Vcs blame becomes harder to use after the churn because to get down to
> the interesting change for the part of the code, you must skip a lot
> of no-op commits (and before skipping, reader needs to ensure that the
> commits are no-op). Same for vcs log.
>
> Then, when you found older change that is interesting, it does not
> matches the current code state due to churn above it.
>
> Repo churn invalidates any out-of-tree patches or development trees
> and requires efforts to re-merge.

You basically say that code-refactoring is a no-go.

> Lets ignore MFC for a moment.
>
> These are basics why huge style changes alone, or large set of trivial
> non-functional changes cause lot of backpressure.  Look at libexec/rtld-elf
> for the canonical example of code breaking several important style(9)
> rules which are not corrected because that would cause churn.

In this thread we are not talking about style changes. To my  
understanding we are talking about code-refactoring which is supposed  
to lead to
  - be more easy understanding for people new to the code (and we want  
to attract new people in general, right?),
  - a faster understanding for those people which had theirs hands  
already in there but didn't had a look at it for a long time,
  - a simpler interface, and even
  - some clarity about the inner workings which is not available now  
(I refer to the "is td always currthread" question).

I fully agree to prevent code churn in terms of style changes.
I do not agree to code-refactoring is a no-go (it may depending on the  
situation... IMO it should be more "yes to code-refactoring unless"  
instead of "no to code-refactoring unless").

Bye,
Alexander.

-- 
http://www.Leidinger.net Alexander at Leidinger.net: PGP 0x8F31830F9F2772BF
http://www.FreeBSD.org    netchild at FreeBSD.org  : PGP 0x8F31830F9F2772BF
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: Digitale PGP-Signatur
URL: <http://lists.freebsd.org/pipermail/freebsd-fs/attachments/20190307/c207f06d/attachment.sig>