From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 4224 invoked from network); 21 Jul 2004 19:59:55 +0000 Received: from smtp.gentoo.org (156.56.111.197) by lists.gentoo.org with AES256-SHA encrypted SMTP; 21 Jul 2004 19:59:55 +0000 Received: from lists.gentoo.org ([156.56.111.196] helo=parrot.gentoo.org) by smtp.gentoo.org with esmtp (Exim 4.34) id 1BnMpr-0007YB-6N for arch-gentoo-dev@lists.gentoo.org; Wed, 21 Jul 2004 19:33:24 +0000 Received: (qmail 32063 invoked by uid 89); 21 Jul 2004 19:33:02 +0000 Mailing-List: contact gentoo-dev-help@gentoo.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-dev@gentoo.org Received: (qmail 31749 invoked from network); 21 Jul 2004 19:33:01 +0000 From: Stuart Herbert Reply-To: stuart@gentoo.org Organization: Gentoo Linux Project To: gentoo-dev@lists.gentoo.org Date: Wed, 21 Jul 2004 20:32:54 +0100 User-Agent: KMail/1.6.2 References: <20040721163435.7F10B3F03@latitude.mynet.no-ip.org> In-Reply-To: <20040721163435.7F10B3F03@latitude.mynet.no-ip.org> MIME-Version: 1.0 Content-Type: multipart/signed; protocol="application/pgp-signature"; micalg=pgp-sha1; boundary="Boundary-02=_rTs/AXDlFbWeVdU"; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Message-Id: <200407212032.59857.stuart@gentoo.org> Subject: Re: [gentoo-dev] Revisiting GLEP 19 X-Archives-Salt: 12f799ee-1b6f-468a-ae08-c2de75cfeb86 X-Archives-Hash: c2788dc52ecaede7f48b89d0ad656cdb --Boundary-02=_rTs/AXDlFbWeVdU Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Content-Disposition: inline On Wednesday 21 July 2004 17:34, aeriksson@fastmail.fm wrote: > > Two things. First off, I'd hope to achieve a lot more than just adding= a > > [S] entry to emerge -pv. > > Care to elaborate? "It's nifty for the future" is a bad argument. Far > too many times have I came across people who thinks all problems goes > away if the solution is implemented using xml (I'm NOT saying you're > one of them). Present the problems you want to fix, and we'll discuss > them. Let's deal with the XML vs plain text argument first. I'm not an XML-everywhere person, but I do believe that XML is *the* right= =20 technology when you want to add meaning to structured data - meaning that c= an=20 be re-used in software tools. It's nowhere near as difficult to use as=20 ASN.1, not as clumbsy as the plain-text markups in common-use, and if you d= o=20 read the raw XML in a text editor, most people can follow what the file say= s. You *can* do everything I'm suggesting below using a plain text file -=20 provided everyone follows the same conventions. You might even be successf= ul=20 in getting everyone to keep to the conventions. But using XML for the job= =20 gives your tool-writers instant access to rich libraries for parsing,=20 manipulating, and verifying the data. These libraries are available to=20 programmers in all the major languages (except bash alas ... perhaps it's=20 time for someone to change that? ;-) Tools that work on XML data are much= =20 easier to write, and much easier to maintain. Our changelogs are supposed to contain the following information: =2D package version affected =2D list of changed files =2D reason for change =2D bug(s) addressed by the change (inc security issues announced through G= LSAs) =2D developer who made the change =2D user(s) who originally suggested the change (credit for patches, ebuild= s,=20 and the like) Let's look at what we could do with this sort of data. Now, if I'm reading a changelog, if I want to see what issues are fixed, th= e=20 changelog isn't normally enough. Why? Because it's very common for the=20 changelog to only contain a bug number and not a description. Normally, yo= u=20 have to open up a browser, and search for each bug in turn on=20 bugs.gentoo.org. It's not exactly hard work, but we could make a better=20 experience. There's no reason why the changelog couldn't contain both the bug id and th= e=20 summary line from bugzilla. There's no reason why a GUI tool like Porthole= -=20 or even the command-line based emerge - couldn't provide you with a [more]= =20 link to go and get the full discussion from bugzilla. Instead of unconnect= ed=20 data stored in different places, we now have connected data and a means to= =20 connect them. That idea - of making it possible for tools to connect the=20 data - of making it possible for the tools to understand the data - is wher= e=20 the real value of XML lies. If we were really wanting to take this further, for those packages that=20 provide a list of upstream bugs that are fixed in a release, we could store= =20 that list in the changelogs too, with summaries and click-throughs. That's= a=20 bit more work, and not everyone's idea of fun, but it could be done. At th= e=20 very least we could provide a link to the upstream changelog. That's just looking at one aspect of bugs and changes. Being able to say=20 whether a bug fix is security-related or not is another aspect. That's jus= t=20 another type of change information. It shouldn't have to be stored and=20 treated as a special case - which is where the glsa-check tool seems to be= =20 going. Let's look at the reasons why a new version of a package is added to Portag= e. =20 I believe 'version bump' will prove the most popular in our changelogs righ= t=20 now. Is it to address serious bugs? Is it for security reasons? We could= =20 standardise that into a choice of one or more reasons. That's information= =20 that can then be used by GUIs such as Porthole and packages.gentoo.org. =20 That's information that users could search on. =20 Where is the upstream changelog? Something else that can be added. If you= =20 write your tools correctly, you can introduce new types of information into= =20 your XML data without having to change your tools. I'm in the information business. I work on publishing tools for developers= =2E =20 I work on a CMS tool (yes, it's XML based). I write about my work. I work= =20 with information probably more than I work with code. Most information jus= t=20 doesn't exist in isolation. Most information is really just information=20 about yet more information, information that people don't read because it=20 isn't served to them on a plate. It's not about getting left behind. I didn't buy that argument during the= =20 dotcom boom, and I definitely don't buy it now. What it's about is making = a=20 lot more of what we already have, by making it more available. To make it= =20 more available to people, you have to make it more available to the tools=20 first. I'm not looking for problems to fix. "It ain't broke, so don't fix it" isn= 't=20 always the best advice. Sometimes, the thing to do is to look at what is=20 possible, rather than just accept what you're stuck with today. Now, maybe this information should be part of the metadata for an ebuild=20 instead of being in a 'ChangeLog' - as Weeve was aluding to earlier in this= =20 thread. From an SCM point of view, it's all configuration information=20 related to a change, whether you want to call it a 'ChangeLog' or=20 'metadata.xml' file or whatever. > Why not add that bit of info the the ebuild which incorporates the > fix? "SECURITYFIX=3Durl1 url2 http://www.gentoo.org/GLSA1234whatever" > would be all need. That's one way to do it. Build another special case into ebuilds and into= =20 Portage. It'll work. But if the information was somewhere in XML, it'd be= =20 an easier change to introduce. All you'd have to do would be to update an= =20 XML schema. You shouldn't have to update tools. > Or put the other way around, why not move > all the other headers in ebuilds to xml, and use xml-aware tools to > execute on them? (joke) That's a topic that keeps cropping up. If you look at our GLEPs, there's o= ne=20 currently open with people chomping at the bit to make that happen, at leas= t=20 for some of the information. Best regards, Stu =2D-=20 Stuart Herbert stuart@gentoo.o= rg Gentoo Developer http://www.gentoo.or= g/ http://stu.gnqs.org/diar= y/ GnuPG key id# F9AFC57C available from http://pgp.mit.edu Key fingerprint =3D 31FB 50D4 1F88 E227 F319 C549 0C2F 80BA F9AF C57C =2D- --Boundary-02=_rTs/AXDlFbWeVdU Content-Type: application/pgp-signature Content-Description: signature -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.4 (GNU/Linux) iD8DBQBA/sTrDC+AuvmvxXwRAvXHAKCXhAYhQS2M4/h3/G9GrmLYx08j9ACgkvCy +Q+1lm1FK7x4AO/bak+qfPI= =oXsA -----END PGP SIGNATURE----- --Boundary-02=_rTs/AXDlFbWeVdU--