Justin Erenkrantz <email@example.com> writes:
> I'm not looking for a code review at this point - hence, no log
> message. I won't even tell you how to use it, or configure it. If
> you sift through the code, you can figure it out though.
Oh :-). Okay, then I'll wait, thanks.
> I know where there is room for improvement, but I'm guessing I'd like
> a sandbox where I can work on this and share my work with
> others. Eventually, I believe this could be merged into the trunk.
> I'm just not ready for that yet, and I don't care to keep maintaining
> patches like these on my local machine. This stuff really needs to be
> versioned somewhere! Due to the lack of cross-repository merges, I
> couldn't even setup a server to do this right on my own. Stuff like
> this has to live in the CollabNet repository. -- justin
Sure, but if it's going to go even on a branch, it still needs a log
message and documentation. The branch isn't useful to others unless
meets the same sandbox standards as the rest of Subversion.
Hmmm, I guess we haven't really had this discussion yet. This is as
good a time as any... What I'm proposing is a basic policy on
experimental branches in general:
Experimental branches are great as long as they're conducted the
same way as trunk development -- with the exception that they don't
necessarily have to build and pass 'make check' at all times (the
group maintaining the branch can decide about that; I mean, there's
a reason it's called "experimental"! :-) ). But as far as log
messages and documentation go, branches should be as thorough as
trunk, because people rely on that information to follow branch
It is not costless for our repository to version an experimental
branch. If the branch is there, people will look at it. It will get
discussed on the list. People will start filing issues against it in
the database, etc, etc. None of which is bad, of course; it's just
that to work well with these processes, the branch needs to meet
There's no point having a bunch of code dumped into the repository if
only one or two people know what state it's in and how to use it. It
has to be consumable by everyone.
To unsubscribe, e-mail: firstname.lastname@example.org
For additional commands, e-mail: email@example.com
Received on Fri Dec 13 16:14:07 2002