LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
From: Ingo Molnar <mingo@elte.hu>
To: Theodore Tso <tytso@mit.edu>, Andreas Dilger <adilger@sun.com>,
	Adrian Bunk <bunk@kernel.org>,
	sct@redhat.com, akpm@linux-foundation.org,
	linux-ext4@vger.kernel.org, linux-kernel@vger.kernel.org
Subject: Re: [2.6 patch] fs/jbd/journal.c: cleanups
Date: Mon, 18 Feb 2008 13:57:02 +0100	[thread overview]
Message-ID: <20080218125702.GB15044@elte.hu> (raw)
In-Reply-To: <20080218114936.GM8905@mit.edu>


* Theodore Tso <tytso@MIT.EDU> wrote:

> I'm going to NACK it as well.  This kind of code churn where we make 
> symbols static only to make them non-static again in an existing ext4 
> tree is exactly the sort of needless code churn that makes patches 
> start to conflict and where we need different patches depending on 
> whether it is intended for -mm or linux-next or mainline.

Resolving a reject due to a line of code difference is about 10 seconds 
of your or time - and you two already spent 10-100 times more time on 
just fighting that line of code - which is weird. Yes, "naked" exports 
are sometimes OK (and i recently defended and NACK-ed an export removal 
in one such case), but the reason given here, out of tree forks are very 
much not such a case.

Example: recently i got some scheduler stuff not included in time - and 
had to remove an unnecessary export. Stupid me for not having planned it 
right and i deserved looking stupid in the git log. This time you did 
not get the "journal checksum patch" into 2.6.25 by time: tough luck, it 
shows that you suck at getting stuff done in time sometimes.

So please deal with it like most other subsystem maintainers do and stop 
complaining about "code churn" - nobody but you changes the ext3 
codebase, it's one of the codebases least affected by general kernel 
flux, it's an ultimate "leaf" subsystem.

In fact, we only had 5300 lines of code flux in ext3 in the past ~3 
years:

  $ git-log -p -M v2.6.12.. fs/ext3/ | diffstat | tail -1
    45 files changed, 3205 insertions(+), 2043 deletions(-)

with its 16 KLOC's that's a churn rate of ~10% per year. [and 9% out of 
that was ext3's own feature churn, nothing externally inflicted]

As a comparison, the core kernel had a churn of 182,000 lines [and this 
excludes renames] in the past 3 years:

  $ git-log -p -M v2.6.12.. kernel/ | diffstat | tail -1
    284 files changed, 96256 insertions(+), 45277 deletions(-)

and with it being a 91 KLOC codebase that's a _51%_ churn rate per year.

Or take a look at the networking code, with a ~40% 3-year churn rate in 
half a million lines of code. _That_ is a high rate of change - but the 
networking people have learned how to deal with it and Linux has become 
the best OS on the planet in terms of networking technology.

The whole kernel has 8406491 LOC at the moment, in the past 3 years it 
had a churn of 9214017 lines of code (excluding renames), which averages 
to a churn rate of ~35% per year.

	Ingo

  reply	other threads:[~2008-02-18 12:57 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-02-17  8:19 Adrian Bunk
2008-02-18  7:04 ` Andreas Dilger
2008-02-18  7:12   ` Ingo Molnar
2008-02-18 11:49     ` Theodore Tso
2008-02-18 12:57       ` Ingo Molnar [this message]
2008-02-18 13:31         ` Theodore Tso
2008-02-18 13:55           ` Ingo Molnar
2008-02-18 13:12       ` Adrian Bunk
2008-02-18 13:28         ` Theodore Tso
2008-02-27 19:39           ` Adrian Bunk
2008-02-18 13:31         ` Ingo Molnar
2008-02-18 15:11           ` Theodore Tso
2008-02-18 16:22             ` Ingo Molnar
2008-02-27 21:20   ` [2.6 patch] unexport journal_update_superblock Adrian Bunk

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=20080218125702.GB15044@elte.hu \
    --to=mingo@elte.hu \
    --cc=adilger@sun.com \
    --cc=akpm@linux-foundation.org \
    --cc=bunk@kernel.org \
    --cc=linux-ext4@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=sct@redhat.com \
    --cc=tytso@mit.edu \
    --subject='Re: [2.6 patch] fs/jbd/journal.c: cleanups' \
    /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

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