[EMAIL PROTECTED] (Terry Eck) writes: > What I'd like to know is how is the file Packages constructed.
dpkg-scanpackages(8) -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED] >From miss Received: from mongo.pixar.com (138.72.50.60) by master.debian.org with SMTP; 10 Jan 1997 22:44:53 -0000 Received: (qmail 23817 invoked from network); 10 Jan 1997 19:13:13 -0000 Received: from primer.i-connect.net (HELO master.debian.org) ([EMAIL PROTECTED]) by mongo.pixar.com with SMTP; 10 Jan 1997 19:13:13 -0000 Message-Id: <[EMAIL PROTECTED]> Date:Fri, 10 Jan 1997 14:14:39 -0500 From: Ami Ganguli <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] Organization: Ganguli Consulting Inc. X-Sender: Ami Ganguli <[EMAIL PROTECTED]> X-Mailer: Mozilla 4.0b1 (Win95; I) MIME-Version: 1.0 To: [email protected] Subject: Re: Problems with 1.2.1 X-Priority: Normal References: <[EMAIL PROTECTED]> Content-Transfer-Encoding: 7bit Content-Type: text/plain; charset=us-ascii Resent-Message-ID: <"ocmFl2.0.uB7.CKfro"@master.debian.org> Resent-From: [email protected] Resent-Reply-To: [email protected] X-Mailing-List: <[email protected]> archive/latest/3136 X-Loop: [email protected] Precedence: list Priority: non-urgent Importance: low Resent-Sender: [EMAIL PROTECTED] Dale Scheetz wrote: > The first rule of publishing: Don't let the writer proof his/her own work. > Yet, we as maintainers, are the first to test our packages, and in some > cases, no other test occurs untill the general user gets to try it out. > We do have several folks who do "new installs" to test things out, but > many of the problems users have are due to their particular hardware > configuration. > > As a result of these factors, we must depend upon our user base to "find" > the other problems. Understandable, but maybe fixable. I remember Bruce asking people on the list to test 1.2 before it went out. If that testing process were a little more structured, we might have found more of the problems ahead of time. I understand that there's a bug tracking system. Is there a release tracking/ testing system to complement it? I'll volunteer for this if needed, although there are probably people closer to the project who'd be better suited to it. My approach would be to treat the distribution as a whole in the same way you treat a large application program. After a new package is integrated into the release the entire release passes a series of tests (performed by various people on various platforms) before the package is accepted. The process would probably delay the release of "stable" distributions by a couple of weeks, but I think it would be worth it. Comments? ... Ami. -- TO UNSUBSCRIBE FROM THIS MAILING LIST: e-mail the word "unsubscribe" to [EMAIL PROTECTED] . Trouble? e-mail to [EMAIL PROTECTED]
