From: Andrew Lunn <andrew@lunn.ch>
To: Marek Vasut <marex@denx.de>
Cc: netdev@vger.kernel.org, f.fainelli@gmail.com,
vivien.didelot@savoirfairelinux.com, Woojung.Huh@microchip.com,
UNGLinuxDriver@microchip.com,
"David S . Miller" <davem@davemloft.net>,
Tristram Ha <Tristram.Ha@microchip.com>
Subject: Re: [PATCH V2] net: dsa: ksz: Add reset GPIO handling
Date: Mon, 10 Dec 2018 15:37:55 +0100 [thread overview]
Message-ID: <20181210143755.GD4660@lunn.ch> (raw)
In-Reply-To: <d245dbf3-65e7-b6c6-4bd1-b384ce47802c@denx.de>
On Mon, Dec 10, 2018 at 02:26:51PM +0100, Marek Vasut wrote:
> On 12/08/2018 12:11 PM, Andrew Lunn wrote:
> >> This actually is an individual patch, it doesn't depend on anything.
> >> Or do you mean a series with the DT documentation change ?
> >
> > Yes, i mean together with the DT documentation change. Those two
> > belong together, they are one functional change.
>
> Fine
>
> > Part of this is also to do with scalability. It takes less effort to
> > merge one patchset of two patches, as two individual patches. The
> > truth is, developer time is cheap, maintainer time is expensive
>
> This is _not_ fine and I am actually offended by this statement.
> The way I read this is that maintainer time has more value than
> developer time, which justifies spending the developer time by
> maintainers without having any appreciation for it. I hope I am
> misreading your statement ?
Hi Marek
Sorry, i was not meaning to be offence. But it is part of the
economics of the Linux Kernel. There are many more developers than
maintainers. There are lots of studies over the years which suggests
there are not enough maintainers, and those maintainers we have are
overloaded. So the development process is based towards making the
maintainer role easier, by asking the developers to do a bit more
work. Writing easy to review patchsets, adding reviewed by tags to new
versions of patches, including a summary of changes between each
version, meaningful patchset, etc. Much of that is to make the
reviewers job, who are mostly maintainers, easier. And to make the job
of people like David, who does the actually merge, easier, scalable to
the number of patches he needs to work on every day.
Andrew
next prev parent reply other threads:[~2018-12-10 14:37 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-07 21:51 [PATCH V2] net: dsa: ksz: Add reset GPIO handling Marek Vasut
2018-12-07 22:24 ` Andrew Lunn
2018-12-07 22:59 ` Marek Vasut
2018-12-07 23:46 ` David Miller
2018-12-08 4:21 ` Marek Vasut
2018-12-08 11:11 ` Andrew Lunn
2018-12-10 13:26 ` Marek Vasut
2018-12-10 14:37 ` Andrew Lunn [this message]
2018-12-12 0:39 ` Marek Vasut
2018-12-10 18:01 ` David Miller
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=20181210143755.GD4660@lunn.ch \
--to=andrew@lunn.ch \
--cc=Tristram.Ha@microchip.com \
--cc=UNGLinuxDriver@microchip.com \
--cc=Woojung.Huh@microchip.com \
--cc=davem@davemloft.net \
--cc=f.fainelli@gmail.com \
--cc=marex@denx.de \
--cc=netdev@vger.kernel.org \
--cc=vivien.didelot@savoirfairelinux.com \
/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.
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).