[rtg] 0.74 vs. 0.81

[bill fumerola]

On Thu, May 25, 2006 at 03:51:16PM -0400, Steve Scaffidi wrote:
> 2. It looks like some of the patches floating around could be *quite*
> useful. Would anybody be interested in having some sort of repository for
> these patches - with basic documentation and such. It would be great to make
> it part of http://rtg-utilities.sourceforge.net

i'd rather see the rtg development model improve rather than fork. yrtg
was as close to a fork as i wanted to get. community support should just
be that. if you think i'm surly now, envision me getting 20 individual
mails about "my" version/patch of rtg all with the same question or
having two or three "rtg mailing lists" none of which are related or
share archives and having to answer questions on all of them. and so on.

i'd rather see decisions made based on technical merit centrally on this
list (the rtg-devel list seems stillborn) rather than adopting the linux
model of different distributions. worse yet: rtg-0.81+yrtg+billfmodz.

> Also, as a marginally-related question - I've never used CVS - To try out
> the yrtg patch I checked out RTG using the following command:
> 
>  cvs -z3 -d:pserver:anonymous at rtg.cvs.sourceforge.net:/cvsroot/rtg co -D
> 2004/11/03 -P rtg

for someone who never has used cvs you sure picked up quickly :)

> That got me a source tree that patched cleanly - but compiling just barfs. I
> RTFM, but should have checked out the code in a different way? (I understand
> that it may be impossible to get it working though)

compiling and getting it working when patched against old code shouldn't
be an issue.  mail me the details privately. the patch now available on
mu.org may have been generated more recently than 2004 (i kept up the
work until spring 2005). i had code that converted the output of 'p4
diff2' into something patch could use and the dates may be bullshit or
based on import time versus diff generation time or some such.

the divergance of the code since then is the real problem. at minimum
sqlbuf would need to use the libfool db interface and i'm sure there's
plenty of other changes since then that conflict architectually.  the
yrtg patch is almost as big as a code checkout (sans rtgplot) itself.

for example: all the mutex/pthread changes i made are inter-related and
the sqlbuf code depends on those changes being there.

i'd consider committing the changes independently based on function (a
mutex commit, a rtghash commit, an snmp commit, etc). even if it did
apply cleanly today (or if i brought it up to HEAD) i'm not advocating
committing the entire thing as one big checkin.  however, what i'm not
going to do is produce the above staged commits as 12 steps of patches,
be in the same spot i was a year ago, have them never checked in, and
watch them rot. pass.

ideally we could find some way to get the new features of cvs HEAD w/
the performance modifications that have already been written.

-- bill