new patch file format

[Cliff Skolnick <cl...@steam.com>]

Here's an updated file format...for drtr and others...notice that
there is a new field "ref" for reference URL's.  The definition of
"code" has also changed and "req" has been added.  New/changed lines
start with a "|".



--------
The patch file format is a list of simple attribute value pairs followed
by a free form section of text.  The attribute is everthing to the left
of the first "=" on the line, the value is everying to the right.  If you
are using vi or emacs, please be aware of the format since scripts will
need to grok this stuff.  Defined pairs so far are as follows:

id:
	The patch ID as assigned from hyperreal.  There is a file
	called "lastid" which is the last issued patch id by the
	system.  Increment this number by one and use the result.

state:
	Where the patch is (there has been discussion about changing this).
	This field must be one of the following strings exactly, or pull
	down menus can't be easy done in forms:


		a) dispatched - The patch for is filled out, if it
		is not bogus it should be changed to "invote".  By
		bogus I mean someone didn't just enter data like
		"your mother is a hamster."

		b) invote - The patch is currently in discussion and
		will be voted upon soon. (maybe we should have a
		discussion state also?)

		c) accepted - The patch has been accepted and we are
		figuring out whose code to use (or possibly who will
		write it)  The description/comments should contain
		this info.

		d) received - We have code in hand that needs to be
		integrated.

		e) verified - The patch is verified as working (no
		core dumps, servers coming to a grinding halt, etc)
		This also means it's ready to be made into a patch
		or go into the formal release.

		f) patched - An official patch has been created.  This
		will only be for important bugs whose code *has* to
		get out.  Normally code would switch to the next state.

		g) integrated - The patch is in the next release.

		h) rejected - Your mother was not a hamster, the comment
		and discussion should reflect why unless it is obvious.


type:
	One of "B", "P", "E", or "O" (no others dues to forms)
	Which identified the patch type.  B=bug, P=performance,
	E=enhancement, O=other.

pri: (priority)
	A number 1 to 5, with 1 being "OH MY GOD, IT'S BAD" and
	5 being "This would be cool."

sum: (summary)
	A short (50 character or less) blurb on the problem.

keys: (keywords)
	A list of comma separated keywords.

conf: (conflicts)
	A list of comma separated patches that you know are in conflict.

submitter:
	Who started this mess about the problem.  Maybe not be the coder.

owner:
	Who is really thinking about this patch and will submit code.
|
|code:
|	A URL where this code can be found, or blank if the code
|	does not exists
|
|req:
|	Required patches.  A comma seperated list of patches required by
|	this patch.
|
|ref:
|	A comma seperated list of URLS that refer to this patch, perhaps into
|	the mail archive at hyperreal that descrive this patch and its
|	effects.

Any others?  They can be just added *and* the cgi's modified to accept
them.

The rest of the file (everything after "desc:") is just a
bunch of text that are comments and descriptions.  I suggest people
who add stuff identify themselves and put the date and time in there.

Plea)

It would be ultimately cool if someone could maintain the scripts
and mechanisms instead of me.  The stuff is in TCL right now, but
would be easy to convert to PERL.  (There are also still a couple
problems with the TCL stuff)  I would (or whoever is doing the
integration) still own the format of the files.

People are also invited (go rst!) to do their own forms up and
make them available for public use.  I will not feel hurt if my
forms are totaly replaced, really.

Cliff