linux-kernel - Re: [git pull] vfs.git part 5

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 5 Jul 2017 13:33:52 -0700
From:   Linus Torvalds <torvalds@...ux-foundation.org>
To:     Al Viro <viro@...iv.linux.org.uk>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        linux-fsdevel <linux-fsdevel@...r.kernel.org>
Subject: Re: [git pull] vfs.git part 5

On Wed, Jul 5, 2017 at 12:15 AM, Al Viro <viro@...iv.linux.org.uk> wrote:
>
>         That's probably it for today; again, I apologize for the amount of
> pull requests, but the tree topology is really nasty this cycle.

There is *no* reason to apologize.

Really - I *much* rather do five separate pull requests where each
pull has a stated reason and target, than do one big mixed-up one.

The "git pull" itself is the least of my problems: it usually takes a
couple of seconds at most, and doing one or five of them doesn't
matter much.

Yes, five of them does slow me down a bit, because I do the "make
allmodconfig" build in between each, but it's not really any more
_work_.

And in fact, smaller and well-defined pull requests make it _so_ much
easier for me to go over and review the thing, and tends to make any
possible conflicts easier to handle too, so I much prefer them this
way.

Because for me, the real job and effort really has nothing to do with
the "git pull" part. It's me looking at *what* I pull that is the real
job, and having that split up logically just makes everything better
for me.

So I heartily encourage everybody to do topic branches - at least when
it is stuff where I care and review. It really does make life better
for me, and I think the real upside is that it also makes for better
kernel development in general when people have that model of trying to
keep separate development threads separate.

Now, there are exceptions, of course. When it comes to tons of
drivers, I really don't want to see fifty pull requests for different
areas of drivers, and I'm really happy that Greg only splits things
out along the really big/broad strokes - because I'm not going to
review individual drivers *anyway*. So it's not like I want to see
_all_ the nitty-gritty details of different development threads. The
big submaintainers (Greg, Davem, etc) do a lot of that aggregation,
and I end up relying on them to just DTRT.

But I really do love seeing the x86 -tip tree send me stuff as 20+
different pull requests for different areas, and merging the ARM
changes has gone from being painful to being no trouble at all, and I
really like seeing the work come in as multiple clear different
branches. It just makes me feel better about the whole maintenance
cycle of the code, even outside of the "easier for me to get an
overview of what is going on".

So yes, getting the VFS code as five different pull requests means
that it takes me longer to merge, but it's literally "longer but
easier", so I'm not at all complaining.

Of course, I say that right now, when I have so far actually only
merged the first of the five pull requests (despite me _replying_ to
the fifth one).  It's going through the build motions right now, and
I'm starting to look at the other ones while that finishes.

So maybe in half an hour you'll get an angry email from me where I
bitch about how horrible pull request #2 was ;)

                Linus