From owner-freebsd-vuxml@FreeBSD.ORG Thu May 6 11:56:50 2004 Return-Path: Delivered-To: freebsd-vuxml@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 2177516A4CE for ; Thu, 6 May 2004 11:56:50 -0700 (PDT) Received: from gw.celabo.org (gw.celabo.org [208.42.49.153]) by mx1.FreeBSD.org (Postfix) with ESMTP id 65F2A43D46 for ; Thu, 6 May 2004 11:56:49 -0700 (PDT) (envelope-from nectar@celabo.org) Received: from madman.celabo.org (madman.celabo.org [10.0.1.111]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client CN "madman.celabo.org", Issuer "celabo.org CA" (not verified)) by gw.celabo.org (Postfix) with ESMTP id E33D454840; Thu, 6 May 2004 13:56:48 -0500 (CDT) Received: by madman.celabo.org (Postfix, from userid 1001) id 8B6F96FF36; Thu, 6 May 2004 13:56:48 -0500 (CDT) Date: Thu, 6 May 2004 13:56:48 -0500 From: "Jacques A. Vidrine" To: Frankye - ML Message-ID: <20040506185648.GA1777@madman.celabo.org> Mail-Followup-To: "Jacques A. Vidrine" , Frankye - ML , freebsd-vuxml@freebsd.org References: <20040506161853.GA649@lum.celabo.org> <20040506193818.3bd177a4@godzilla> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20040506193818.3bd177a4@godzilla> X-Url: http://www.celabo.org/ User-Agent: Mutt/1.5.6i cc: freebsd-vuxml@freebsd.org Subject: Re: Adding `branches' to VuXML X-BeenThere: freebsd-vuxml@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Documenting security issues in VuXML List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 06 May 2004 18:56:50 -0000 On Thu, May 06, 2004 at 07:38:18PM +0200, Frankye - ML wrote: > Just a little idea. > > Wouldn't be better to put into the item? I understand > "branches" might not always be increasing numbers, so this might limit the > general usefulness of such an idea, but at least in openbsd are (iirc). > > in the example above this would mean: > > > foo > > 3.3 > foo-1.1 > > > > It would not add much complexity (I hope it at least :) and we can use the > added flexibility provided by the various lt, ge, et al. In general, branches are arbitrary strings, at we cannot count on them to have any particular ordering. Happily, they are not usually numerous, so the utility of and so forth doesn't buy much. In fact, I thought that it might be wise to name the new element rather than , to reflect that this is really just one additional way to distinguish different packages. As for making it a child element of ... I don't think that is a good idea. Changing the content model of will have more impact on existing tools than just adding a new element to /. It could also multiply the number of elements required. > And now, since we're speaking of branches, here comes another silly idea > of mine: can we use the cvs tags instead of the versions (i.e.: RELENG_4 > or RELENG_4_9) in items for the freebsd vuln.xml file? > > This has no real practical reason whatsoever, but imvho for the historical > record is better-looking to say "-STABLE and 4.9-RELEASE were affected" > rather than "this version, which if you go looking for turns out to be the > -STABLE one, and this other ..." > (If this has a beneficial effect on the eventual confusion generated by > the item, remains to be seen, imho it has not) I'm not sure what you mean. The FreeBSD Ports Collection does not have branches. Are you referring to the elements specifically? I think the information would be redundant, due to the way release engineering is done today. i.e. RELENG_N_M always corresponds to FreeBSD N.M-something. Branch names cannot replace version numbers, because there is a difference between, say 4.9-RELEASE-p1 (4.9_1) and 4.9-RELEASE-p7 (4.9_7) that cannot be reflected in the CVS branch name (RELENG_4_9) by its very nature. But, it's possible I misunderstood what you are suggesting. It is probably a topic for another thread that there currently isn't a way to express that a -STABLE or -CURRENT branch is or isn't affected. This has to do with the fact that -STABLE and -CURRENT aren't versioned until there is a release. > Just my 2 cents Thanks much! Cheers, -- Jacques Vidrine / nectar@celabo.org / jvidrine@verio.net / nectar@freebsd.org