Note, that Mel's patches will probably go into 4.2. I just got back from vacation in Mexico and have only one test left for my GSEC certification. After that, I'll have some free-time again to work on GNATS. Mel Hatzis wrote: > You'll be glad to know that I finally got started on this. What I'd > like to propose is that I submit a series of patches for review, and > commit them as I go. Sounds good to me. > The alternative is that we lay a tag and create a branch for me to do > all the development and then merge the branch back with the mainline. I've found the savannah CVS to be a bit slow and unresponsive, so I don't want to require contributors to have to work heavily with branching and merging. Likewise, I'm not always around and want to leverage the expertise of other developers in our group. I would like to simply help with managing which features and changes go into which mainline branches. I don't want to be the Benevolent Dictator of the project. I'd rather be the coxswain, helping to guide our team forward. > The reason I like the former approach is that I think the changes will > be more thoroughly reviewed. True. > Each of the patches will retain operational integrity...and some will > even improve performance. Excellent! This should be one of the requirements for commits to the CVS mainline branches. Let's list out what would probably be manageable for our group: * Operational Integrity -- the change-set doesn't break anything * Follow GNU Coding Standards * Use the ChangeLogs liberally * Post your patch for review I don't want the "review process" to be mired in unnecessary, political frameworks. Let's assume that if someone has commit access to CVS that he or she is a "trusted" developer and can reasonably coordinate merging and committing with others. Let's use help-gnats as our medium to announce impending changes to the branch. I haven't done this in the past with my libiberty work, but I will follow this guideline for the future. To those that don't have CVS commit access, you don't really need it to contribute to the project. Just send the patch to help-gnats for review. If you feel more comfortable forwarding the patch to me rather than committing to the development branches, please do so. We really don't have the numbers to necessitate a more structured development framework. If we do get to a point where a number of us are working on the trunk, CVS probably isn't the tool for us anyway and perhaps something like GNU Arch or Subversion would be more appropriate. Until we reach that point, CVS is probably good enough. > I'm ready to submit my first patch. Do you have a preference for where > I should email it? For simplicity's sake, you could send them to me and help-gnats for review. If you get the OK, apply the patch directly to CVS. It might be useful to pre-tag and post-tag the branch if you plan on making multiple commits or change-sets. We're not using the commit log message to generate ChangeLog files automatically, so feel free to use the same message for all files in the change-set. The ChangeLog file is where we want the file and function level messages to be anyway. While we're making changes, it might be a good idea to add a bit of documentation to each of the functions. Nothing overtly structured is needed, just a description about what the function is for and how its used. libiberty has a cute little "collector" perl script to generate texi documentation that's embeded into pre-function comments that we could steal if we want. The GNU Coding Standards doesn't mention any "standard" toolkit for generating documentation, stating that documentation should be found in the manual anyway. I personally find it helpful to see SOMETHING in the code, though. ;-) Ideas? Objections? > Also, I answered a question on the help-gnats mailing list but my > response was held for review by the moderator. I got a message back > saying that this was because it's an internal list. Are you able to > add me to the "in" crowd? It looks like you're a member of the list without a moderation flag. Have you continued to have problems with this? -- Chad Walstrom http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */