From owner-freebsd-doc@FreeBSD.ORG  Sat Aug 21 00:35:50 2004
Return-Path: <owner-freebsd-doc@FreeBSD.ORG>
Delivered-To: freebsd-doc@freebsd.org
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP
	id 88D8416A4CE; Sat, 21 Aug 2004 00:35:50 +0000 (GMT)
Received: from mail.soaustin.net (mail.soaustin.net [207.200.4.66])
	by mx1.FreeBSD.org (Postfix) with ESMTP
	id 4A9C843D39; Sat, 21 Aug 2004 00:35:50 +0000 (GMT)
	(envelope-from linimon@lonesome.com)
Received: by mail.soaustin.net (Postfix, from userid 502)
	id BCBA014316; Fri, 20 Aug 2004 19:35:49 -0500 (CDT)
Date: Fri, 20 Aug 2004 19:35:49 -0500 (CDT)
From: Mark Linimon <linimon@lonesome.com>
X-X-Sender: linimon@pancho
To: Ceri Davies <ceri@FreeBSD.org>
In-Reply-To: <20040821001142.GO5433@submonkey.net>
Message-ID: <Pine.LNX.4.44.0408201926140.6833-100000@pancho>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII
cc: freebsd-doc@freebsd.org
Subject: Re: To PR Senders
X-BeenThere: freebsd-doc@freebsd.org
X-Mailman-Version: 2.1.1
Precedence: list
List-Id: Documentation project <freebsd-doc.freebsd.org>
List-Unsubscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-doc>,
	<mailto:freebsd-doc-request@freebsd.org?subject=unsubscribe>
List-Archive: <http://lists.freebsd.org/pipermail/freebsd-doc>
List-Post: <mailto:freebsd-doc@freebsd.org>
List-Help: <mailto:freebsd-doc-request@freebsd.org?subject=help>
List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-doc>,
	<mailto:freebsd-doc-request@freebsd.org?subject=subscribe>
X-List-Received-Date: Sat, 21 Aug 2004 00:35:50 -0000

On Sat, 21 Aug 2004, Ceri Davies wrote:

> Pulling down a patch via fetch or similar is basically a PITA when they
> need follow ups in the PR, and I would rather see patches in GNATS for
> pretty much everything.

I'd have to agree -- the key item being that the more eyes that see it
initially, the more people will probably comment on it/submit patches.
However, if something is of very limited interest and is large (200k
lines of whitespace patches), then it should probably be in a URL.

On checking, it seems that most ports PRs are <20k.  A few are huge,
and sometimes that's because someone attaches (e.g.) a config.log.
I'd rather see huge files like that, that may be very specific to
one installation and possibly even transient, not be in GNATS.
However, kernel tracebacks do need to be included for the kern PRs
to be useful; but 'syncing disks 1 1 1 ...' is just wasted space.

We should probably come up with a hard limit above which you should
not put it into GNATS.

mcl