code cleanup for release 4.1

code cleanup for release 4.1

[Mel Hatzis]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Chad, as part of the code cleanup for release 4.1, I'd like
to contribute some function name changes and subtle code
re-organization in preparation for the gnats-dbi integration
(which I think we're going to fold into Gnats 5.0).

The name changes support the internal dbi api which I've put
together to define the interface between the higher level
GNATS functionality and the datastore specific stuff.

IMO, these name changes also make the code a little easier
to read and understand.

I just got back from a fairly long vacation, so, I'm going
to start putting the patches together and contributing them
to the help list for review. If everyone is happy with the
changes, I'd like to begin committing them into the 4.1 release.

Note: there will be no functional differences introduced.
This is purely a cleanup effort which will preserve the
existing threads of execution.

Let me know if you find this acceptable (or not). I think
that providing these patches in small chunks will make the
whole dbi project a lot easier to swallow and digest.

- -Mel
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFBDKPaNF74HmYqaSERAiNKAJ9tamztN0mbEyDO2YAE6Bth0828XQCg1kFF
nglihIDpDmoDvB64m+rFd+o=
=XugD
-----END PGP SIGNATURE-----


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

code cleanup for release 4.1

[Mel Hatzis]

[-- Attachment #1: Type: application/pgp, Size: 1359 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

Re: code cleanup for release 4.1

[Chad Walstrom]

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

Looks like I screwed up and didn't approve your post to help-gnats.  I'm
trying to bounce it there now, but Mailman may recognize duplicate
Message-Id and quell it.  I'll forward it instead if it doesn't go
through.

Mel Hatzis wrote:
> Chad, as part of the code cleanup for release 4.1, I'd like to
> contribute some function name changes and subtle code re-organization
> in preparation for the gnats-dbi integration (which I think we're
> going to fold into Gnats 5.0).
...
> Let me know if you find this acceptable (or not). I think that
> providing these patches in small chunks will make the whole dbi
> project a lot easier to swallow and digest.

Sounds like a good plan to me.  I'm not certain if you prefer to submit
patches for me to roll in, or if you want to use branching on the CVS
repository for savannah.  I'm open to either.

-- 
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

Re: code cleanup for release 4.1

[Chad Walstrom]

[-- 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