[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: code cleanup for release 4.1

From: Chad Walstrom
Subject: Re: code cleanup for release 4.1
Date: Fri, 18 Feb 2005 13:42:27 -0600
User-agent: Mutt/1.5.6+20040907i

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

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.


> 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

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 <address@hidden> 
           assert(expired(knowledge)); /* core dump */

Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]