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:
Code has been ftp'ed to hyperreal, not that you have it.
This is a change from the existing form.
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
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:
Code has been ftp'ed to hyperreal, not that you have it.
This is a change from the existing form.
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