From: Jerry Van Baren <gerald.vanbaren@ge.com>
To: u-boot@lists.denx.de
Subject: [U-Boot-Users] Request to mailing list U-Boot-Users rejected
Date: Wed, 12 Dec 2007 16:21:47 -0500 [thread overview]
Message-ID: <476050EB.6040901@ge.com> (raw)
In-Reply-To: <200712111743.40701.vapier@gentoo.org>
Mike Frysinger wrote:
> On Tuesday 11 December 2007, Mike Frysinger wrote:
>> On Tuesday 11 December 2007, Wolfgang Denk wrote:
>>> In message <200712112009.06587.sr@denx.de> you wrote:
>>>>>> Message body is too big: 40979 bytes with a limit of 40 KB
>>> ...
>>>
>>>> 100k limit, please.
>>> And what happens whith the next posting with a size of 100k + N bytes?
>> with that logic, why allow 40k. take it down to 10k. or 1k.
>>
>> posting valid patches that exceed 40k is not uncommon. patches exceeding
>> 100k is much less uncommon.
>
> actually, if you're NAK-ing this by yourself, then i dont see why you'ed NAK a
> valid patch in the first place.
>
> someone posts a log file or configuration file or something that exceeds the
> limit makes sense. people developing source code when patches are supposed
> to be sent to the list does not.
> -mike
I would agree with Mike... have a soft limit of 40K where bounced
messages go to Wolfgang and he authorizes "reasonable" patches.
Alternatively, set the limit higher (100K) and cut it back if it gets
abused. I suspect it won't.
I don't know how many "oversize" (>40K) messages Wolfgang sees. Judging
from the small number of complaints about oversize bounces on the list,
it doesn't seem to be many.
Discarding oversize patches on a hard numerical criteria rather than on
a softer validity criteria is easy for decision making but hard on the
developers. Arbitrarily breaking (in *both* senses of the word) patches
just to fit them under the 40K limit causes more work and results in
*less* benefit.
I like Koha's motto: "Every time a patch falls on the floor, a kitten
dies." <http://wiki.koha.org/doku.php?id=en:development:git_usage>
We should be encouraging patches of a reasonable size and should be
flexible on the definition of "reasonable." We are willing to use 3rd
party code (e.g. linux driver code) that may not quite meet our coding
standards because it is useful and expedient to not have to rewrite
perfectly good code. If we have reasonable flexibility on coding
standards, why not on patch sizes???
My 2 cents,
gvb
P.S. courtesy of Ogden Nash :-)
THE KITTEN
----------
The trouble with a kitten is
THAT
Eventually it becomes a
CAT.
next prev parent reply other threads:[~2007-12-12 21:21 UTC|newest]
Thread overview: 19+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <mailman.0.1197390201.2247.u-boot-users@lists.sourceforge.net>
2007-12-11 16:47 ` [U-Boot-Users] Request to mailing list U-Boot-Users rejected Haavard Skinnemoen
2007-12-11 19:09 ` Stefan Roese
2007-12-11 21:52 ` Timur Tabi
2007-12-11 22:13 ` Wolfgang Denk
2007-12-11 22:41 ` Mike Frysinger
2007-12-11 22:43 ` Mike Frysinger
2007-12-12 21:21 ` Jerry Van Baren [this message]
2007-12-12 0:08 ` Wolfgang Denk
2007-12-12 1:49 ` Ben Warren
2007-12-11 19:53 ` Mike Frysinger
2007-12-11 20:00 ` Scott Wood
2007-12-11 22:26 ` Wolfgang Denk
2007-12-12 9:29 ` Haavard Skinnemoen
2007-12-13 0:10 ` Wolfgang Denk
2007-12-13 6:16 ` Stefan Roese
2007-12-13 6:27 ` Kumar Gala
2007-12-13 6:31 ` ksi at koi8.net
2007-12-13 7:31 ` Robert Schwebel
2007-12-12 15:15 ` Timur Tabi
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=476050EB.6040901@ge.com \
--to=gerald.vanbaren@ge.com \
--cc=u-boot@lists.denx.de \
/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