public inbox for gnats-devel@sourceware.org
 help / color / mirror / Atom feed
From: Chad Walstrom <chewie@wookimus.net>
To: help-gnats@gnu.org
Cc: Mel Hatzis <mel@wattes.org>
Subject: Re: code cleanup for release 4.1
Date: Fri, 18 Feb 2005 19:56:00 -0000	[thread overview]
Message-ID: <20050218194227.GF7611@wookimus.net> (raw)
In-Reply-To: <4215A2D1.3060200@wattes.org>


[-- Attachment #1.1: Type: text/plain, Size: 4404 bytes --]

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 <chewie@wookimus.net>           http://www.wookimus.net/
           assert(expired(knowledge)); /* core dump */

[-- Attachment #1.2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 140 bytes --]

_______________________________________________
Help-gnats mailing list
Help-gnats@gnu.org
http://lists.gnu.org/mailman/listinfo/help-gnats

      parent reply	other threads:[~2005-02-18 19:56 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-08-01 13:53 Mel Hatzis
2004-08-01 14:40 ` Mel Hatzis
2004-08-01 15:04 ` Chad Walstrom
     [not found] ` <20050127230534.GC12372@wookimus.net>
     [not found]   ` <4215A2D1.3060200@wattes.org>
2005-02-18 19:56     ` Chad Walstrom [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20050218194227.GF7611@wookimus.net \
    --to=chewie@wookimus.net \
    --cc=help-gnats@gnu.org \
    --cc=mel@wattes.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).