From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30343 invoked from network); 18 Feb 2005 19:56:13 -0000 Received: from unknown (HELO lists.gnu.org) (199.232.76.165) by sourceware.org with SMTP; 18 Feb 2005 19:56:13 -0000 Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D2ES2-00087e-Qb for listarch-gnats-devel@sources.redhat.com; Fri, 18 Feb 2005 15:10:10 -0500 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1D2EQH-0007Ml-F7 for help-gnats@gnu.org; Fri, 18 Feb 2005 15:08:21 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1D2EQD-0007Kb-6Z for help-gnats@gnu.org; Fri, 18 Feb 2005 15:08:18 -0500 Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1D2EQC-0007Ih-O4 for help-gnats@gnu.org; Fri, 18 Feb 2005 15:08:16 -0500 Received: from [199.199.210.160] (helo=chef.nerp.net) by monty-python.gnu.org with esmtp (Exim 4.34) id 1D2E5G-0007C4-Da for help-gnats@gnu.org; Fri, 18 Feb 2005 14:46:38 -0500 Received: from skuld.wookimus.net (c-66-41-156-164.mn.client2.attbi.com [66.41.156.164]) (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by chef.nerp.net (Postfix) with ESMTP id 735CF565A4; Fri, 18 Feb 2005 13:46:37 -0600 (CST) Received: from wookimus.net (skuld.wk [192.168.5.100]) by skuld.wookimus.net (Postfix) with ESMTP id E1A373DDD; Fri, 18 Feb 2005 13:46:35 -0600 (CST) Received: by wookimus.net (Postfix, from userid 1000) id 2ED0328B8; Fri, 18 Feb 2005 13:42:27 -0600 (CST) Date: Fri, 18 Feb 2005 19:56:00 -0000 From: Chad Walstrom To: help-gnats@gnu.org Message-ID: <20050218194227.GF7611@wookimus.net> Mail-Followup-To: help-gnats@gnu.org, Mel Hatzis References: <410CA3DA.6080800@wattes.org> <20050127230534.GC12372@wookimus.net> <4215A2D1.3060200@wattes.org> Mime-Version: 1.0 In-Reply-To: <4215A2D1.3060200@wattes.org> X-Operating-System: Linux skuld 2.6.8-1-k7 X-GnuPG-Fingerprint: B4AB D627 9CBD 687E 7A31 1950 0CC7 0B18 206C 5AFD User-Agent: Mutt/1.5.6+20040907i Cc: Mel Hatzis Subject: Re: code cleanup for release 4.1 X-BeenThere: help-gnats@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General discussion about GNU GNATS List-Archive: List-Post: List-Help: List-Subscribe: , Content-Type: multipart/mixed; boundary="===============1673699870==" Sender: help-gnats-bounces+listarch-gnats-devel=sources.redhat.com@gnu.org Errors-To: help-gnats-bounces+listarch-gnats-devel=sources.redhat.com@gnu.org X-SW-Source: 2005-q1/txt/msg00032.txt.bz2 --===============1673699870== Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="jL2BoiuKMElzg3CS" Content-Disposition: inline --jL2BoiuKMElzg3CS Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-length: 4310 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? --=20 Chad Walstrom http://www.wookimus.net/ assert(expired(knowledge)); /* core dump */ --jL2BoiuKMElzg3CS Content-Type: application/pgp-signature; name="signature.asc" Content-Description: Digital signature Content-Disposition: inline Content-length: 189 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.5 (GNU/Linux) iD8DBQFCFkUjDMcLGCBsWv0RAtKkAJ0We3BDk7opwLpVK6nBfwmZMxPifgCg2CTp cRwCXLwn4EVseDci7nqqMUs= =yHsP -----END PGP SIGNATURE----- --jL2BoiuKMElzg3CS-- --===============1673699870== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline Content-length: 140 _______________________________________________ Help-gnats mailing list Help-gnats@gnu.org http://lists.gnu.org/mailman/listinfo/help-gnats --===============1673699870==--