From owner-freebsd-current@FreeBSD.ORG Tue Mar 29 19:27:03 2005 Return-Path: Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id CCC0316A4CE for ; Tue, 29 Mar 2005 19:27:03 +0000 (GMT) Received: from s1tank.virtdom.com (s1tank.virtdom.com [12.26.83.50]) by mx1.FreeBSD.org (Postfix) with SMTP id 2A48043D39 for ; Tue, 29 Mar 2005 19:27:03 +0000 (GMT) (envelope-from brian@aljex.com) Received: (qmail 80696 invoked by uid 89); 29 Mar 2005 19:30:33 -0000 Received: from ool-43552092.dyn.optonline.net (HELO venti) (brian@aljex.com@67.85.32.146) by s1tank.virtdom.com with SMTP; 29 Mar 2005 19:30:33 -0000 Message-ID: <00ce01c53495$46eb62d0$6800000a@venti> From: "Brian K. White" To: References: <4248EA01.6030902@pacific.net.sg><02bd01c53426$eaec3f40$6800000a@venti> <20050329181059.GA46108@82-168-75-155-bbxl.xdsl.tiscali.nl> Date: Tue, 29 Mar 2005 14:26:33 -0500 Organization: Aljex Software MIME-Version: 1.0 Content-Type: text/plain; format=flowed; charset="iso-8859-1"; reply-type=original Content-Transfer-Encoding: 7bit X-Priority: 3 X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook Express 6.00.2900.2180 X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.2180 Subject: Re: freebsd naming of releases X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 29 Mar 2005 19:27:03 -0000 ----- Original Message ----- From: "Rene Ladan" To: "Brian K. White" Cc: Sent: Tuesday, March 29, 2005 1:10 PM Subject: Re: freebsd naming of releases >> % changed >> % known good >> % known bad > Are these in lines of code? Who knows? I didn't give serious thought to coming up with meaningful properties, let alone how to measure them. >> then translate the percentages to 0-255 values and use them as an RGB >> value >> to colorize download links on a web page. >> red , purple, blue links you stay away from, >> you use only the greenest green ones for production, or dip into yellows >> for production when necessary. >> >> the ratings on fresh or recent updates would be WAG's and mostly dark >> grey, > wouldn't they be red, as only % changed is known? WAG = wild assed guess ie: a new commit may be labeled safe or risky by the committer which of course should carry very little weight. and not necessarily all that red, plenty of commits don't change much, or don't change much that carries any risk. (docs, aesthetics) A tiny change could cause a known major breakage (until matching changes are made elsewhere) so the color might be bright blue with very little red or green. But then we get into how to measure the properties again. The tiny code change, if it causes major sweeping breakage, maybe that fallout should be part of the %changed and then yes, it'd be a very red snapshot. I think the properties are just not very good. I think maybe %known-bad is redundant and needs to be replaced with something else. I think each version of each file in the cvs web interface should also have these same properties. It would be like filesystem meta-data. Maybe the colors for the whole system snapshot would be arrived at by 50% average of all component files colors, and 50% based on user feedback for the whole system. Or 3rd's, 1/3 average of all files, 1/3 user feedback, 1/3 developer inside knowledge For an individual file it's 1/2 feedback and 1/2 developer decree, and so neither users nor a developer has the power to make a file fully green or red all by them self. Brian K. White -- brian@aljex.com -- http://www.aljex.com/bkw/ +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO Prosper/FACTS AutoCAD #callahans Satriani