OK..I think we are getting ourselves into a bind here and loosing
track of which patch does what, which is the latest, etc. I think
we needs some formal process (ick) for voting patches in or out and
stuff. More importantly we need to link the patch reports and bug reports
to the discussions somehow, which will not be an easy trick.
I propose:
1) Patch Creation:
All new patches get an ID. You can use the form or
log into hyperreal and create the file. I'll be documenting the format
later in another document. No patches (even if they are a single line
of code) will go into the apache release without a patch id. I also
might set something up to file a patch via email, but I don't know
if that is needed. [ thanks for moving the stuff to hyperreal
Brian]
2) Patch Updates:
All updates can either be done via the form, or again
by editing the file on hyperreal. All patches that have changed over
the course of a day should be listed in a daily status email (which
will be generated by a cron job)
3) Patch Discussion:
When discussing a patch, the patch id should be in the
subject as "[patch %c%n]", with the brackets. The %c will be B, P, E, or
O. The % will be the patchid. This will make it easy to go
thought the archives and fine messages about a patch. It is important
we talk about one patch per email. Also, If you saying something like,
"The patch is busted, use this instead." or "This killed my system"
please update the bug report, it will be very important.
The bug report is a home for things like:
a) Description of the problem
b) Status
c) Where the code can be found
d) Any problems/corrections
Email is a the place for:
a) Questions about the correctness of the patch.
b) Discussion on if to include it in the release or not
4) Voting System:
The voting system will be simple. One a week all patches who's
discussion has ended will be voted upon. We need a vote taking volunteer
for this that will sift though the email an figure what the heck the
person is voting on and how they voted. (Or someone to do forms)
5) About integration:
Integration takes time...we don't just toss in 30 patches
from various people and hack until it's compiled. That's fine for testing
the patches and finding incompatibilities, but does not make a true
product. People coding style (naming to be one) are different...and it
is not a good idea to call procedures in a product something of
the form blah_blah_hack_ick, those will be renamed :-) Comments
will also be added. This is a big part of software engineering as
opposed to hacking.
FYI this is what I am doing with patches now, complaints about
why not just toss it together and sending it out the door will be ignored.
If the group wants to head in that direction, I'm not the guy to
put the pieces together. Getting something together in 2 weeks is
actually a very *short* time BTW.
6) About pre-apache:
The pre-apache code people are playing with is great...lots of good testing
and bug finding going on in there. I don't think there is any problem
with this. Keep on chugging along.
Cliff
track of which patch does what, which is the latest, etc. I think
we needs some formal process (ick) for voting patches in or out and
stuff. More importantly we need to link the patch reports and bug reports
to the discussions somehow, which will not be an easy trick.
I propose:
1) Patch Creation:
All new patches get an ID. You can use the form or
log into hyperreal and create the file. I'll be documenting the format
later in another document. No patches (even if they are a single line
of code) will go into the apache release without a patch id. I also
might set something up to file a patch via email, but I don't know
if that is needed. [ thanks for moving the stuff to hyperreal
Brian]
2) Patch Updates:
All updates can either be done via the form, or again
by editing the file on hyperreal. All patches that have changed over
the course of a day should be listed in a daily status email (which
will be generated by a cron job)
3) Patch Discussion:
When discussing a patch, the patch id should be in the
subject as "[patch %c%n]", with the brackets. The %c will be B, P, E, or
O. The % will be the patchid. This will make it easy to go
thought the archives and fine messages about a patch. It is important
we talk about one patch per email. Also, If you saying something like,
"The patch is busted, use this instead." or "This killed my system"
please update the bug report, it will be very important.
The bug report is a home for things like:
a) Description of the problem
b) Status
c) Where the code can be found
d) Any problems/corrections
Email is a the place for:
a) Questions about the correctness of the patch.
b) Discussion on if to include it in the release or not
4) Voting System:
The voting system will be simple. One a week all patches who's
discussion has ended will be voted upon. We need a vote taking volunteer
for this that will sift though the email an figure what the heck the
person is voting on and how they voted. (Or someone to do forms)
5) About integration:
Integration takes time...we don't just toss in 30 patches
from various people and hack until it's compiled. That's fine for testing
the patches and finding incompatibilities, but does not make a true
product. People coding style (naming to be one) are different...and it
is not a good idea to call procedures in a product something of
the form blah_blah_hack_ick, those will be renamed :-) Comments
will also be added. This is a big part of software engineering as
opposed to hacking.
FYI this is what I am doing with patches now, complaints about
why not just toss it together and sending it out the door will be ignored.
If the group wants to head in that direction, I'm not the guy to
put the pieces together. Getting something together in 2 weeks is
actually a very *short* time BTW.
6) About pre-apache:
The pre-apache code people are playing with is great...lots of good testing
and bug finding going on in there. I don't think there is any problem
with this. Keep on chugging along.
Cliff