Re: freebsd naming of releases

From: Brian K. White <brian_at_aljex.com>
Date: Tue, 29 Mar 2005 14:26:33 -0500
----- Original Message ----- 
From: "Rene Ladan" <r.c.ladan_at_student.tue.nl>
To: "Brian K. White" <brian_at_aljex.com>
Cc: <current_at_freebsd.org>
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_at_aljex.com  --  http://www.aljex.com/bkw/
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx  Linux SCO  Prosper/FACTS AutoCAD  #callahans Satriani
Received on Tue Mar 29 2005 - 17:27:03 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:38:30 UTC