[TCLCORE] CVS write access

[Jeffrey H. <jef...@aj...>]

I've moved this question to the tclcore list as it applies for
all people with CVS write access.

> From: drh [mailto:drh]On Behalf Of D. Richard Hipp
	...
> I have in hand a patch to Tk8.4 that fixes a X11
> "BadMatch" error.  It used to be that I would send
> such patches to Jeff and they would get into the 
> next release.  But I'm thinking it sure would be 
> a lot easier (for me and Jeff both) to just do a
> "cvs commit"....

All TCT members are allowed direct write access to the core, but
we need to all agree on the basic rules of code cleanliness and
good docs and tests (as Jim mentioned before).  It's been
suggested that any TCT member can recommend others to have write
access to work on particular projects, and that that TCT member
would be responsible for making sure the project doesn't break
things (hopefully the other person takes care of this themselves).

> What are the procedures for writing to the CVS
> repository?  How are updates coordinated to prevent
> someone from committing an unstable change right 
> before an important release, for example?  Is there
> any kind of peer review of changes?  How to we get
> turned on for write access to the CVS repository?

All changes should be thoroughly tested before being commited.
We understand that some people only have one Unix or Windows
flavor to test on.  We hope to get a nightly build set up that
does the full builds and tests (we have that already) and then
points fingers at the last who commited changes when something
breaks (we don't have that yet).

The concept of peer review is interesting.  Hopefully anyone
putting code back will have read and stick to the Tcl Engineering
Style Guide (basically tells all the C style that is used in
the current code - we have emacs lisp code to assist in sticking
to this), as well as the Tcl Style Guide for Tcl code and how
to write test suites.

John Ousterhout recommended that as we start up, each TCT member
could work on a project that was destined for the next release.
We could then all do a mass peer review and make comments.  I'm
not sure how necessary this is, how comfortable everyone is with
this, or if people even feel they have the time to do that.

In general, you can be sure that peer review of a sort occurs
because every other developer will see the check-ins.  I guess
the most important point then is to make sure that everyone knows
how to use ChangeLogs properly so we can just track things just
in case something happens.  After all, this is an open project,
and if the build doesn't work for a couple of nights, the world
will not come to an end.

However, we do want to stick to the high standards set by those
who came before (starting with JohnO).  That's made it very easy
for people like myself to step in and learn to work on the core
without wondering what the heck the other guy was thinking when
they wrote some code.  We don't want to come to the point that
Perl has - having to rewrite Perl6 from "scratch" because the
internals are in such a bad shape.

Jeffrey Hobbs                     Tcl Ambassador
ho...@Aj...          Ajuba Solutions (nee Scriptics)

--
The TclCore mailing list is sponsored by Ajuba Solutions
To unsubscribe:  email tcl...@aj... with the 
                 word UNSUBSCRIBE as the subject.