re: [development] Suggestion for people releasing new modules and themes into CVS
Since I recently added a module and didn't realize the initial commit message had special significance, I'll invite you to look at: http://drupal.org/project/volunteer_timeslots This module utilizes the event module and defines a new node type representing an event where site users can volunteer for a specific time period. I am starting to use it initially to organize volunteers for a table to do voter registration and distribute literature for Democratic candidates. This in not meant to be as full featured as the volunteer module (which seems not yet to be released for 4.7 and which requires CiviCRM), but I hope will fill an intermediate need in political/NGO organizing. -Peter
Date: Wed, 13 Sep 2006 10:10:17 -0400 From: Syscrusher <syscrusher@4th.com> Subject: [development] Suggestion for people releasing new modules and themes into CVS Message-ID: <200609131010.17673.syscrusher@4th.com>
...
Alternatively, a note posted to the Development list would be fine, too. The main point is to remember that the module or theme name may not provide much info on what it does, especially for those who aren't familiar with whatever previous work inspired the name. (E.g., if you don't know what Deli.cio.us does, you might think a module by that name is for recipes or restaurant listings, etc.)
On Wednesday 13 September 2006 12:35, Peter Wolanin wrote:
Since I recently added a module and didn't realize the initial commit message had special significance,
AFAIK, it doesn't *officially*. I'm just suggesting this as a good idea to do voluntarily. :-) Thanks for your post; your module may be of interest to me in a site I'll be upgrading to Drupal 4.7 this fall. Scott -- ------------------------------------------------------------------------------- Syscrusher (Scott Courtney) Drupal page: http://drupal.org/user/9184 syscrusher at 4th dot com Home page: http://4th.com/
Here are other notes to CVS committers that should be written as guidelines for all to follow: Note to all, please add to this list what you think should go in, this will then be summarized and put it as a guidelines page. - Upon committing a new module or theme, add a concise description of what the module does or how this theme is unique (e.g. fluid/fixed, tables/css, ...etc.) - Try to not commit every issue separately. If you plan to fix three issues, then do not commit three times. Better do one commit with the three fixes in it. - Do not commit every file separately when initially committing a module. Do a cvs add on all the files that need to go in, then do a cvs commit to check them into the repository. - Make sure you have the -kkv and not -kk, specially if you use Eclipse - Use the format following format for commits that relate to an issue: #nodeid description-goes-here, by patch-contributor On Drupal.org, the commits will be automatically linked to the issue. - Do not post the entire URL of the issue on Drupal.org. - ???
Khalid B wrote:
- Try to not commit every issue separately. If you plan to fix three issues, then do not commit three times. Better do one commit with the three fixes in it.
I disagree with this, quite seriously. Committing one fix at a time has benefits in being able to derive patch files to back out problems from just one fix. Muddling a bunch together makes that less possible.
I imagined that some would disagree with this, for that very reason. The other side of the coin is clutter in CVS and RSS feeds, but I guess your argument wins. Does this mean you agree with all the rest of my points? Can you add some more? On 9/13/06, Earl Miles <merlin@logrus.com> wrote:
Khalid B wrote:
- Try to not commit every issue separately. If you plan to fix three issues, then do not commit three times. Better do one commit with the three fixes in it.
I disagree with this, quite seriously. Committing one fix at a time has benefits in being able to derive patch files to back out problems from just one fix. Muddling a bunch together makes that less possible.
Khalid B wrote:
I imagined that some would disagree with this, for that very reason. The other side of the coin is clutter in CVS and RSS feeds, but I guess your argument wins.
Does this mean you agree with all the rest of my points?
I either agree with or have no opinion on the rest. I didn't know about the automatic translation of CVS so the format bit is interesting and I should look into that some.
On Sep 13, 2006, at 10:24 AM, Khalid B wrote:
I imagined that some would disagree with this, for that very reason. The other side of the coin is clutter in CVS and RSS feeds, but I guess your argument wins.
i, too, *strongly* disagree with your original suggestion on this. the whole point of version control is keeping track of individual changes so you know when, who, and why any given change happened, so you can undo changes you don't like, and so you can more easily share those changes with others. fixing N issues in 1 giant commit completely violates many of the benefits of using version control in the first place... 2 immediate examples of why this makes life difficult: 1) if you need to undo a given change, but the same commit includes 4 other things you want, you're totally screwed. now you get to track down the various patches that were actually committed (something our existing practice isn't very good about -- you get a link to an issue id, but sometimes there are 60+ patches in the issue, and it's not always obvious which patch was actually used), undo the whole revision, re-apply the 4 patches you want to keep, re-test everything, commit it, etc. 2) you're looking at "cvs annotate" output to try to understand some code you're not familiar with. there's a weird line in the code that doesn't make much sense, you think it's a bug, and you want to know where it came from. you see it was last touched in revision 1.67, but when you look at the log message, there are 5 different issue #s. :( now you have to read 5 issues to try to figure out which one of them might really be the source of this change, and how it might relate to the problems you're trying to understand... avoiding "clutter" in the CVS logs and RSS feeds is looking at this completely backwards. don't read all the logs if you don't care about all the changes. ;) the solution here is to filter on messages you actually care about (i.e. the ones from projects you care about, or even the ones on specific branches of specific projects you care about). there are already many ways to filter your view of the cvs commits based on what you want to see (either on the command-line, in various GUIs/viewcvs ways, and via drupal itself, e.g. http:// drupal.org/project/cvs/3281). that's how to keep your signal/noise ratio high, not by trying to limit the overall # of commits in the repo. anyway, enourmous -100 to this practice in the first place, and it should by no means become a "guideline". ;) quite the contrary, the guideline should spell this out (with more concise language) and implore people to only make 1 change per commit...
Does this mean you agree with all the rest of my points?
yes, i think the rest of them look good. thanks for helping to document this wisdom. -derek (dww)
Should probably affect only those using Eclipse. Someone on this list had issues with the CVS Id tag and it turned out to be those options. Otherwise, disregard this. On 9/13/06, Johan Forngren <johan@forngren.com> wrote:
What does that mean for mortal cvs noobs?
2006/9/13, Khalid B <kb@2bits.com>:
...
- Make sure you have the -kkv and not -kk, specially if you use Eclipse ...
Most CVS clients that I've used allow the choice of kkv etc... They all seem to have different defaults. On 9/13/06, Khalid B <kb@2bits.com> wrote:
Should probably affect only those using Eclipse. Someone on this list had issues with the CVS Id tag and it turned out to be those options.
Otherwise, disregard this.
On 9/13/06, Johan Forngren <johan@forngren.com> wrote:
What does that mean for mortal cvs noobs?
2006/9/13, Khalid B <kb@2bits.com>:
...
- Make sure you have the -kkv and not -kk, specially if you use Eclipse ...
-- -> JV
Johan Forngren wrote:
What does that mean for mortal cvs noobs?
2006/9/13, Khalid B <kb@2bits.com <mailto:kb@2bits.com>>:
... - Make sure you have the -kkv and not -kk, specially if you use Eclipse ...
-kkv does keyword expansion; it turns $Id:$ into a real string. -kk will ignore that and leave previous IDs in, which is rarely what we want.
Khalid B wrote:
- Upon committing a new module or theme, add a concise description of what the module does or how this theme is unique (e.g. fluid/fixed, tables/css, ...etc.)
What is more important is having a concise description in your .info file.
- Try to not commit every issue separately. If you plan to fix three issues, then do not commit three times. Better do one commit with the three fixes in it.
As stated earlier, this is wrong.
- Make sure you have the -kkv and not -kk, specially if you use Eclipse
I'm guessing most people don't use Eclipse.
- Use the format following format for commits that relate to an issue:
#nodeid description-goes-here, by patch-contributor On Drupal.org, the commits will be automatically linked to the issue.
- Do not post the entire URL of the issue on Drupal.org.
These seem somewhat arbitrary. Any sufficiently descriptive format is fine. What should be said is Drupal's CVS messages are published at http://drupal.org/cvs - '#n' will be converted to a link to http://drupal.org/node/n. Do provide a reference to the issue on Drupal.org. - Drupal.org user names will be converted to links. Do give credit for patches. - Anything else special that CVS module does. -- Neil Drumm http://delocalizedham.com/
On Wednesday 13 September 2006 12:07, Khalid B wrote:
Here are other notes to CVS committers that should be written as guidelines for all to follow:
Note to all, please add to this list what you think should go in, this will then be summarized and put it as a guidelines page.
- Upon committing a new module or theme, add a concise description of what the module does or how this theme is unique (e.g. fluid/fixed, tables/css, ...etc.)
Agreed.
- Try to not commit every issue separately. If you plan to fix three issues, then do not commit three times. Better do one commit with the three fixes in it.
Not agreed. That's bad practice for versioned development. Commits should be the smallest atomic unit that can be reasonably achieved. One bug/feature per commit.
- Do not commit every file separately when initially committing a module. Do a cvs add on all the files that need to go in, then do a cvs commit to check them into the repository.
Agreed.
- Make sure you have the -kkv and not -kk, specially if you use Eclipse
I have no idea what you just said.
- Use the format following format for commits that relate to an issue:
#nodeid description-goes-here, by patch-contributor On Drupal.org, the commits will be automatically linked to the issue.
- Do not post the entire URL of the issue on Drupal.org.
I'll take your word for it. Does the patch-contributor need to be the user's Drupal name? Others I'd add: - If you are referencing another module or a 3rd party site in your description, be sure to provide a proper link to it, not just a bare URL. Also, I recall a debate about branching vs. tagging. I'm pretty sure I've been bitten by that question. What is the Drupal recommended way? And why is the other way listed on the site anywhere? :-) That should be explained along-side the rest of these instructions, on the very same page. -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Here is the updated list based on the comments above: - Upon committing a new module or theme, add a concise description of what the module does or how this theme is unique (e.g. fluid/fixed, tables/css, ...etc.) - Try to group your commits functionally. For example a change that affects several files has to be committed in a single commit. This allows others to know what has changed, roll it back if necessary, create patches, ...etc. Do not commit unrelated changes together in one commit, and do not commit the change to each file separately. - Do not commit every file separately when initially committing a module. Do a cvs add on all the files that need to go in, then do a cvs commit to check them into the repository. - If you are using a GUI client, check its default settings. For example Eclipse uses -kk which affects the CVS Id tag. Change that to -kkv. - Use the format following format for commits that relate to an issue: #nodeid description-goes-here, by patch-contributor On Drupal.org, the commits will be automatically linked to the issue. - Do not post the entire URL of the issue on Drupal.org. - It is important to provide a reference to the issue on Drupal.org, if one exists. If you use #nid (where nid is the node Id of the issue in Drupal), then it will be converted automatically to a hyperlink to http://drupal.org/node/nid. This gets published at http://drupal.org/cvs. - Drupal.org user names will be converted to links. - A good convention to use is: #nodeid description-goes-here, by patch-contributor - If you are referencing another module or a 3rd party site in your description, it is best if you provide a proper link to it, not just a bare URL, or worse, just the name.
On Wednesday 13 September 2006 22:15, Khalid B wrote:
Here is the updated list based on the comments above:
I just thought of another one while browsing the module list right now... If you have status information in the module's description ("is being updated for 4.7", "is not yet ready for prime time", "has now been updated for...", etc.) for the love of Dries date it! A module that says in its description: "It is not yet ready for 4.6, nor for HEAD. Allthough It does work, it still needs a lot of love ad time. So you can help." yet has a 4.6 tag and a last update in CVS of sometime over the summer leaves me scratching my head as to wtf its actual status is. Yes, this is an actual example I just saw that prompted me to write this email, but I've seen it a great deal. Related to that, make sure you tag a release in a timely fashion. If a module is tagged for 4.6 but not 4.7, but has lots of recent activity in the HEAD branch, does that mean that the 4.7 version doesn't work yet? That the latest CVS snapshot is 4.7-friendly but the developer is just lazy? That it skipped 4.7 completely and the CVS version is now partially converted to 5.0? Inquiring module-users want to know! OK, this is something of a rant, but I do consider proper maintenance of a project's page and release tags to be basic responsibility. Someone who's not tired and frazzled at the moment, please translate that into good documentation. :-) -- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012 "If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Is your point about the temporal nature of what HEAD is? Or about someone tagging the module for a version while it is not yet converted to the version? HEAD by definition is a moving target. It means different things at different times. For example, in April, it was 4.7, now it means 5.0. So, in any commit, when it says "HEAD" it means "HEAD at the time of the commit whatever it may be". Another problem is that we often don't know if the next release will be an x+1.0 or x.y+1, so we can't say "ported for 5.0" before Dries makes that decision. This is another case where code names for future releases will help. As for people tagging the module before it is ported, this should not be happening and I can add a point on it. On 9/14/06, Larry Garfield <larry@garfieldtech.com> wrote:
On Wednesday 13 September 2006 22:15, Khalid B wrote:
Here is the updated list based on the comments above:
I just thought of another one while browsing the module list right now...
If you have status information in the module's description ("is being updated for 4.7", "is not yet ready for prime time", "has now been updated for...", etc.) for the love of Dries date it! A module that says in its description:
"It is not yet ready for 4.6, nor for HEAD. Allthough It does work, it still needs a lot of love ad time. So you can help."
yet has a 4.6 tag and a last update in CVS of sometime over the summer leaves me scratching my head as to wtf its actual status is. Yes, this is an actual example I just saw that prompted me to write this email, but I've seen it a great deal.
Related to that, make sure you tag a release in a timely fashion. If a module is tagged for 4.6 but not 4.7, but has lots of recent activity in the HEAD branch, does that mean that the 4.7 version doesn't work yet? That the latest CVS snapshot is 4.7-friendly but the developer is just lazy? That it skipped 4.7 completely and the CVS version is now partially converted to 5.0?
Inquiring module-users want to know!
OK, this is something of a rant, but I do consider proper maintenance of a project's page and release tags to be basic responsibility. Someone who's not tired and frazzled at the moment, please translate that into good documentation. :-)
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012
"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
Now that I'm less tired... :-) Actually, it's a little of neither. 1) HEAD is a moving target, for any module. That comes with the territory. 2) I've noticed that some modules will be updated for a new version, but not get tagged for it for some reason. Or maybe they're 90% updated and then, for whatever reason, the maintainer stops working on it so it's not really compatible with anything. 3) Given #2, if I see a module that has recent activity in HEAD but no 4.7 tag, I can't tell if that's because it's not fully updated for 4.7 yet or if it is but the maintainer is just lazy/busy/forgetful. 4) Some module descriptions say things like "right now it doesn't work yet" or "it now works with 4.6", but the module itself is 3 years old. There's no indication when "right now" is. Given #3 and #4, it's not always easy to tell a module's status unless. Solution: A) If you're going to put comments like "right now it needs some love" or other temporally-dependent comments into a project description, please *date them* so that we know when "right now" is. B) Status information ("Upgrade for version X in progress") is useful, but only if it's kept up to date and is accurate. Even "does not yet work with" is an important piece of information that can save people a lot of time, yet takes only seconds to add. C) There was a patch at one point to expose "last updated on" information about a node to the theme layer in addition to creation time. I don't recall if it ever got in, but that would be very helpful information to have as well. In all, it boils down to the need for good communication by the module author on what the status of the project is, beyond simply the existence of a tag. There's a lot that a module author can do in a matter of seconds with their module description to help improve that communication. That should be encouraged. -- Larry Garfield On Thu, September 14, 2006 8:58 am, Khalid B said:
Is your point about the temporal nature of what HEAD is? Or about someone tagging the module for a version while it is not yet converted to the version?
HEAD by definition is a moving target. It means different things at different times. For example, in April, it was 4.7, now it means 5.0.
So, in any commit, when it says "HEAD" it means "HEAD at the time of the commit whatever it may be".
Another problem is that we often don't know if the next release will be an x+1.0 or x.y+1, so we can't say "ported for 5.0" before Dries makes that decision. This is another case where code names for future releases will help.
As for people tagging the module before it is ported, this should not be happening and I can add a point on it.
On 9/14/06, Larry Garfield <larry@garfieldtech.com> wrote:
On Wednesday 13 September 2006 22:15, Khalid B wrote:
Here is the updated list based on the comments above:
I just thought of another one while browsing the module list right now...
If you have status information in the module's description ("is being updated for 4.7", "is not yet ready for prime time", "has now been updated for...", etc.) for the love of Dries date it! A module that says in its description:
"It is not yet ready for 4.6, nor for HEAD. Allthough It does work, it still needs a lot of love ad time. So you can help."
yet has a 4.6 tag and a last update in CVS of sometime over the summer leaves me scratching my head as to wtf its actual status is. Yes, this is an actual example I just saw that prompted me to write this email, but I've seen it a great deal.
Related to that, make sure you tag a release in a timely fashion. If a module is tagged for 4.6 but not 4.7, but has lots of recent activity in the HEAD branch, does that mean that the 4.7 version doesn't work yet? That the latest CVS snapshot is 4.7-friendly but the developer is just lazy? That it skipped 4.7 completely and the CVS version is now partially converted to 5.0?
Inquiring module-users want to know!
OK, this is something of a rant, but I do consider proper maintenance of a project's page and release tags to be basic responsibility. Someone who's not tired and frazzled at the moment, please translate that into good documentation. :-)
-- Larry Garfield AIM: LOLG42 larry@garfieldtech.com ICQ: 6817012
"If nature has made any one thing less susceptible than all others of exclusive property, it is the action of the thinking power called an idea, which an individual may exclusively possess as long as he keeps it to himself; but the moment it is divulged, it forces itself into the possession of every one, and the receiver cannot dispossess himself of it." -- Thomas Jefferson
On Sep 14, 2006, at 8:09 AM, Larry Garfield wrote:
In all, it boils down to the need for good communication by the module author on what the status of the project is, beyond simply the existence of a tag.
for the record, the new system for releases[1] will provide more structured ways for contrib authors to communicate this information. however, the bottom line is still that the authors themselves have to be responsible enough to provide the info. the degenerate case of the new release system (if a contrib maintainer does *no* additional work to take advantage of it) will basically be what we have now (though the tarballs will be named a little differently). the bottom line is that the TRUNK version of a module (every branch has a HEAD, can we please start being specific about which "HEAD" we're talking about?) is always going to be a pain in the ass to use since the version info and potential compatibility is such a moving target. however, a big part of the problem is that because contrib authors don't have any freedom in creating branches for their modules, if they want stable and development branches for a certain version of core (e.g. 4.7) their only option currently is to make the "DRUPAL-4-7" branch the 4.7-stable branch, and TRUNK is the 4.7-dev branch. so, every contrib author can have a different policy about how they use TRUNK. some might be early adopters and port to the latest core API as it's changing. others might use TRUNK as the dev branch for the latest stable core. some might leave it that way, even after core has moved on (e.g. some TRUNK code sitting around now is probably the 4.6-dev version of some modules)... *this* part of the problem is completely addressed by the new system (again, if the author is willing to spend *any* additional effort to take advantage of it). because there will be built-in support for stable + dev branches against *all* versions of the core API, contrib authors will never have to use the TRUNK for this. we can break people of the habit of using the TRUNK versions of modules (except explicitly as testers/developers/maintainers). contrib authors could make real releases off the TRUNK (so long as the tag name matches the conventions the new system will rely on and enforce, CVS doesn't care if that tag lives on a branch or the TRUNK). however, even though these releases technically came off the TRUNK, they'd have explicit version info, including the version of core they're targeted for, so everyone would know exactly what they were and if they wanted to use them... -derek [1] http://drupal.org/node/77562 -- still in need of donations ;)
Published here http://drupal.org/node/84256 Please comment here on the devel mailing list if you feel like it.
On Sep 14, 2006, at 6:35 PM, Khalid B wrote:
Published here http://drupal.org/node/84256
Please comment here on the devel mailing list if you feel like it.
i just noticed that some of the info in there is duplicate with http://drupal.org/node/52287 ("Commit messages--providing history and credit"). we should either merge the 2 pages, or move/merge the info about the specifics of what goes in the commit message from your new page and just add a link to #52287... thanks, -derek
That's an excellent addition. Since we are talking about newbies and Eclipse (thanks, I've now changed to -kkv), I would like to mention the only outstanding issue I have with Eclipse and creating truly useful patches. There is a CVS command-line option to that includes the function names as part of the patch. This context really helps for quick assessment. I have been trying for a while to get Eclipse to create patches like this, but with not luck. If anyone has instructions on how to do this, I'd love to know. Simon Khalid B wrote:
Published here http://drupal.org/node/84256
Please comment here on the devel mailing list if you feel like it.
On Sep 14, 2006, at 7:23 PM, sime wrote:
There is a CVS command-line option to that includes the function names as part of the patch.
FYI: that's "-F^f" for everyone playing along at home with the cli... -derek
Derek Wright wrote:
On Sep 14, 2006, at 7:23 PM, sime wrote:
There is a CVS command-line option to that includes the function names as part of the patch.
FYI: that's "-F^f" for everyone playing along at home with the cli...
cvs -up is what I've always been using. Easier to type and seems to have the same effect.
On 9/14/06, sime <info@urbits.com> wrote:
There is a CVS command-line option to that includes the function names as part of the patch. This context really helps for quick assessment. I have been trying for a while to get Eclipse to create patches like this, but with not luck.
I searched and searched for that earlier today and found nothing. I'm convinced that it's not currently possible, though I didn't find (nor submit) an issue on the subject. Greg -- Greg Knaddison | Growing Venture Solutions Denver, CO | http://growingventuresolutions.com Technology Solutions for Communities, Individuals, and Small Businesses
Greg Knaddison - GVS wrote:
On 9/14/06, sime <info@urbits.com> wrote:
There is a CVS command-line option to that includes the function names as part of the patch. This context really helps for quick assessment. I have been trying for a while to get Eclipse to create patches like this, but with not luck.
I searched and searched for that earlier today and found nothing. I'm convinced that it's not currently possible, though I didn't find (nor submit) an issue on the subject.
Greg
I have just joined the Eclipse newgroup. It is very active. I'll see if I can get some clues. Simon
It looks good but it would be more persuasive/helpful if each tip included the reasoning behind it. Otherwise the reader is left wondering why these guidelines were chosen. "If you are using a GUI client, check its default settings. For example Eclipse uses -kk which affects the CVS Id tag. Change that to -kkv." It's not clear what the implication of "check its default settings" is, especially for the people who don't use Eclipse. What are they supposed to be looking for? If it isn't possible to be more specific, I think it would be better to only include the Eclipse-specific configuration notice. I would also move this tip to the very bottom since it probably won't be relevant to most contributors. Khalid B wrote:
Published here http://drupal.org/node/84256
Please comment here on the devel mailing list if you feel like it.
the bottom line is that the TRUNK version of a module (every branch has a HEAD, can we please start being specific about which "HEAD" we're talking about?) is always going to be a pain in the ass to use since the version info and potential compatibility is such a moving target.
Derek. Thanks for setting many of us straight on the use of TRUNK vs. HEAD. The new system sounds real nice.
Khalid B wrote:
Another problem is that we often don't know if the next release will be an x+1.0 or x.y+1, so we can't say "ported for 5.0" before Dries makes that decision. This is another case where code names for future releases will help.
That is probably the single best argument I've seen for code naming releases before they are released -- so we can refer to them easily and accurately in documentation of all kinds (project pages, CVS comments, postings, etc.).
I tried making the same argument before. It is a common practice in the industry for that very reason, you have the feline names for OSX (Tiger, Panther, ...etc.) as well as city names for Windows (Chicago, ...etc.) On 9/16/06, Chris Johnson <chris@tinpixel.com> wrote:
Khalid B wrote:
Another problem is that we often don't know if the next release will be an x+1.0 or x.y+1, so we can't say "ported for 5.0" before Dries makes that decision. This is another case where code names for future releases will help.
That is probably the single best argument I've seen for code naming releases before they are released -- so we can refer to them easily and accurately in documentation of all kinds (project pages, CVS comments, postings, etc.).
participants (14)
-
Chris Johnson -
Chris Kennedy -
Derek Wright -
Earl Miles -
Greg Knaddison - GVS -
Johan Forngren -
John Vandervort -
Khalid B -
Larry Garfield -
Moshe Weitzman -
Neil Drumm -
Peter Wolanin -
sime -
Syscrusher