From owner-freebsd-ports Mon Feb 14 10: 8:45 2000 Delivered-To: freebsd-ports@freebsd.org Received: from mail.utexas.edu (wb2-a.mail.utexas.edu [128.83.126.136]) by builder.freebsd.org (Postfix) with SMTP id 68AC447A0 for ; Mon, 14 Feb 2000 10:08:40 -0800 (PST) Received: (qmail 20288 invoked by uid 0); 14 Feb 2000 18:08:50 -0000 Received: from dial-102-5.ots.utexas.edu (HELO nomad.dataplex.net) (128.83.176.5) by umbs-smtp-2 with SMTP; 14 Feb 2000 18:08:50 -0000 From: Richard Wackerbarth To: , Subject: Re: multi-level categories Date: Mon, 14 Feb 2000 11:46:44 -0600 X-Mailer: KMail [version 1.0.28] Content-Type: text/plain Cc: References: In-Reply-To: MIME-Version: 1.0 Message-Id: <00021412063300.07348@nomad.dataplex.net> Content-Transfer-Encoding: 8bit Sender: owner-freebsd-ports@FreeBSD.ORG Precedence: bulk X-Loop: FreeBSD.org On Mon, 14 Feb 2000, The Hermit Hacker wrote: > > .../patches/patch-aa > > .../patches/patch-ab > Just curious, but why not merge all the patch-* files into one large > patch, and move *that* to the top level? I could never quite figure out > the reason for several small files ... As much as I advocate fewer files, I can certainly see the advantage to a maintainer when he is allowed multiple patch files IF he uses the "privledge" appropriately. Examine WHY there are any patches in the first place. Some of the patches are because FreeBSD has chosen a different file structure for the installation. Many "authors" don't really care about supporting multiple systems in the first place. Our maintainer is forced to make patches to conform to the FreeBSD way of doing things. Others consider multi-platform only in the sense of their code and not the installation. These patches are likely to persist for a long time. There are additional patches which conform system calls to our libraries. As our libraries change or the "author" makes an effort to support our libraries, these patches may disappear. A third category are outright bug fixes that our maintainer fixes before the "author" has a chance to update his distribution. These are likely to disappear soon. Each patch may affect multiple files. By grouping the patches by subject, the maintainer can simplify the task of reviewing them when it comes time to make an update. Those are the reasons off the top of my head. Perhaps others can add more. However, these are enough to satisfy me that it is reasonable to allow multiple patches. Oh, another reason comes to mind. Some authors regularly distribute patches themselves. It may be better for us to hold to a fixed base and patch it with the author's patches rather than scrub everything and start from a new base. This is particularly true if the base is huge and the patches are small. -- Richard Wackerbarth rkw@Dataplex.NET To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-ports" in the body of the message