From owner-freebsd-current Sat Feb 23 13:40:31 2002 Delivered-To: freebsd-current@freebsd.org Received: from critter.freebsd.dk (critter.freebsd.dk [212.242.86.163]) by hub.freebsd.org (Postfix) with ESMTP id 0F8E237B416; Sat, 23 Feb 2002 13:40:29 -0800 (PST) Received: from critter.freebsd.dk (localhost [127.0.0.1]) by critter.freebsd.dk (8.12.2/8.12.2) with ESMTP id g1NLeRwC013093; Sat, 23 Feb 2002 22:40:28 +0100 (CET) (envelope-from phk@critter.freebsd.dk) To: Robert Watson Cc: current@FreeBSD.ORG Subject: Re: Discussion of guidelines for additional version control mechanisms In-Reply-To: Your message of "Sat, 23 Feb 2002 16:28:47 EST." Date: Sat, 23 Feb 2002 22:40:27 +0100 Message-ID: <13092.1014500427@critter.freebsd.dk> From: Poul-Henning Kamp Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message , Robe rt Watson writes: >Question 1: How should the presence of on-going work in an external >repository be announced to the broader community? On the project.freebsd.org web-page and the regular status emails generated from the contents of that web-page. >Question 2: How should the status of on-going work be announced to the >broader community? > >Suggestion: Bi-monthly developer status report >Suggestion: Status web page for the project >Suggestion: Regular status reports on work to relevant mailing lists All of the above with a s/Regular/As warranted/ on the third line. >Question 3: How should the results of the on-going work be made available >to the broader community? > >Suggestion: cvsup10 export of the Perforce tree >Suggestion: patchsets sent to appropriate mailing lists with status >Suggestion: patchsets generated automatically and posted to the mailing > list Whichever fits the particular project but it would be wonderful if a patch file for all projects could be accessed via the web-page. >Question 4: How agressively should on-going work be pushed back into the >base tree? > >Suggestion: For work requiring large source tree sweeps, API changes, etc, > only when the work is ready to commit. Panic: recursion: "commit only when ready to commit" Doesn't this one hinge on the stability/compilability goal of current and only that ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 phk@FreeBSD.ORG | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message