'td' vs sys/fs/nfsserver/

Konstantin Belousov kostikbel at gmail.com
Thu Mar 7 10:50:19 UTC 2019


On Thu, Mar 07, 2019 at 10:24:52AM +0100, Alexander Leidinger via freebsd-fs wrote:
> 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.
I did not said even close to what you are trying to put into my mouth.

> 
> > 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).
The change is not a refactoring by any common definition of the term, it
is minor functional adjustment. Its benefits are questionable (this is
why that discussion started at all), while effect in the changed lines
count is huge.

Bringing 'improvements for users', 'code clarity', 'refactoring' into
the thread is so much disproportionate that I am really impressed
despite my experience with reading powerpoint slides.

> 
> 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




More information about the freebsd-fs mailing list