Re: [Plplot-devel] Where do we go from here?

[Geoffrey F. <fu...@ga...>]

Rafael Laboissiere writes:
Quoted out of order:
 > > Yeah, I'd feel the most comfortable if the effort were led by Rafael.
 > > Hopefully no time real soon so I can get some other work done. :)
 > 
 > No doubt, I am the most entitled person to do the job.  Unfortunately, I
 > have this time budget problem right now.  At any rate, I did not resign from
 > the project yet, but if I see that I cannot do anything to improve the
 > situation, I will have to make a decision.  I will tell you when/if this
 > arrive (I hope not).

Hey buddy, you can run but you can't hide.  Once a member always a
member.  :-).  Seriously, we all face differing time demands,
diverging personal sw and research interests, etc.  If you need to
spend N months doing something else, even an indeterminately long
dive, that's no reason to feel you need to "resign".  Maurice and I
have both had long fallow periods on PLplot, whilst pushing other
agendas. Don't sweat it.  We're happy to have your constructive
contributions whenever you have the time.  And we'll push on as best
we can the rest of the time.  Really, its that way for all of us.  My
personal ambitions for what I wish I could accomplish on PLplot /far/
exceed what I can actually deliver, measured over any human
timescale of interest.  Such is life.

 > * Maurice LeBrun <mj...@ga...> [2002-02-06 21:56]:
 > 
 > > I'm a bit skeptical it would have made a big difference.  It seems to me
 > > that with the addition of dyndrivers, there were going to be a lot of
 > > configuration changes regardless of which configuration model we were
 > > using.
 > 
 > I do not remember if I told you guys about this, but in my private AM/LT
 > branch (not in CVS) I started porting the dyndrv code to libltdl, a portable
 > library for manipulating dynamically loaded objects (see
 > http://www.gnu.org/manual/libtool-1.4.2/html_node/libtool_45.html).  The
 > goal is to make the dyndrv code largely portable across platforms. By no
 > means, using libltdl means using libtool, but the two things work nice
 > together.
 > 
 > > Certainly the commits I made personally left me with that impression.  I
 > > don't mean to be throwing water on your enthusiasm, I just think it will
 > > take a while for the payoff from AM/LT (or dyndrivers for that matter) to
 > > be really evident.  The payoff from cool new features, however, can be
 > > immediate.
 > 
 > I also think that AM/LT will not bring anything visible for the end-user. My
 > interest in AM/LT is from the packager point of view.  Believe me, the
 > current configuration can be a nightmare for people packaging PLplot
 > (witness rpath problems, non-relocatability, etc).  Besides that,
 > integrating the TEA stuff may be an easier task in the framework of AM/LT.
 > I also think that making the configuration scheme more "modern" (yeah, in
 > the GNU sense...) will make it much more attractive for the potential future
 > developers joining our team.

I'll say again that I share Maurice's (healthy) skepticism, but both
of Rafael's pp's above have interesting, even tantalizing aspects, so
we should by all means endeavor to carry this through to the point
where it can be seriously evaluated.

My only real beef wit the "modern GNU (autoconf) way", is that it is
so woefully inadequate for the overwhelming majority of the software
development I do.  Which is to say, day-in-and-day-out development of
highly levelized C++ software.  Okay, those words don't describe
PLplot much, so maybe a more "modern" autoconf scheme would be okay
for PLplot.  I'm willing to be shown.  But I've just never really felt
that the GNU autoconf system really brings much to the table in the
area of software organization, layout, and general developer-centric
sw issues.  What it does wonderfully, par-excellance, is system
suckiness deobfuscation and workaround demystification.  And that's
pretty much what we use it for, to my mind, with substantial benefit.
And if I could read Maurice's mind from here, I'm guessing he's
feeling about the same, that we are deriving the main benefit of
autoconf right now.  In fact, we are actually deriving more than the
usual benefit, because Maurice has spent so much time (way back at the
beginning) desuckifying some of the autoconf macros.  Maybe they're
catching up by now, but at least for several years, our autoconf stuff
worked a lot better than the average.  I cannot count the number of
times I was able to configure PLplot, but not other GNU software, on
various unix systems where the swadmins had done various cockamaymee
nonsense.  This was especially bad in the labs, where "national
security" was such an oft-abused rubric for excusing any imaginable
sort of sysadmin-lunacy.  X headers under /dont/look/here, X libs
under /you/wont/believe/its/over/here, etc.  

I dunno, we need to see it working.  It may well be worth the switch.
I think the summary for Maurice and me, is just "let's not decide
before we see the proof".  But by all means, if the evidence can be
seen, we'll look.

-- 
Geoffrey Furnish         fu...@ga...