diverse-devel — For discussion among developers and users

Re: [diverse-devel] OpenGL Performer 3.2.1 now available, can i use it??

[John K. <ke...@be...>]

Thanks Pat- I was about to give this a try.  What version of dpf?

Did you do it for both Linux & Irix?

-John

On Tue, 20 Sep 2005, Patrick Shinpaugh wrote:

> I have found no issues with Performer 3.2.1 working with DIVERSE.
>
>
> On Tue, 2005-09-20 at 08:04, John Kelso wrote:
> > Hi,
> >
> > I built diverse with 3.2.0 a while back without any problems.  I don't
> > expect any problems with 3.2.1 either, but will probably not get to it for
> > a couple of days.  If you try it before I do, please let the group know if
> > you had any problems.
> >
> > Thanks,
> >
> > -John
> >
> >
> > On Tue, 20 Sep 2005, Raymond Wadie wrote:
> >
> > >
> > > Hi there
> > > How is everybody :)
> > > OpenGL Performer 3.2.1 is now available
> > > I was asking if it is ok to use it, or I should wait until somebody
> > > verify that it works fine with diverse?
> > > Thanks in advance
> > >
> > > Ray
> > > -----Original Message-----
> > > From: own...@pe...
> > > [mailto:own...@pe...] On Behalf Of Allan
> > > Schaffer
> > > Sent: Monday, September 19, 2005 6:26 PM
> > > To: info-performer Mailing List
> > > Subject: [info-performer] Announcement: OpenGL Performer 3.2.1 now
> > > available
> > >
> > > Hello Performers,
> > >
> > > SGI is very pleased to announce, OpenGL Performer 3.2.1 is now released!
> > >
> > > The web downloads for 64-bit Linux, 32-bit Linux, IRIX, and Windows OS
> > > platforms are all available.  Please visit the Performer web site:
> > >
> > >          <http://www.sgi.com/software/performer/>
> > >
> > > The Demo Edition of Performer 3.2.1 is available as a free web
> > > download.  An SGI Supportfolio membership is required to access the
> > > download site.  If you don't already have an SGI Supportfolio account
> > > you can sign up for free.
> > >
> > > Here's some of what's new for Performer 3.2.1.  Check it out:
> > >
> > >      Changes in OpenGL Performer 3.2.1
> > >
> > >         o Support for SGI ProPack 4 Service Pack 2.  (SCR 936282)
> > >           Performer now supports the SGI ProPack 4 Service Pack 2
> > >           operating system release for Silicon Graphics Prism.
> > >
> > >         o Support for Microsoft Visual Studio 7.  (SCR 929852)
> > >           Performer now supports the Visual Studio 7 (.NET)
> > >           compiler on Windows.
> > >
> > >         o Performer City demo now included.  (SCR 929989)
> > >           The modern "Performer City" demonstration application is
> > >           now bundled with OpenGL Performer.
> > >           IRIX:    /usr/sbin/pfCity
> > >           Linux:   /usr/X11R6/bin/pfCity
> > >           Windows: %PFROOT%/bin/pfCity
> > >
> > >         o New "sgi-performer-clipdemos" rpm on Linux.  (SCR 902282)
> > >           Sample cliptexture data is now shipped with OpenGL Performer
> > >           for Linux in the sgi-performer-clipdemos RPM file.
> > >           See: /usr/share/Performer/data/clipdata
> > >
> > >         o 914835:  Missing pfStats tokens.  Headers and handlers for
> > >           PFFSTATSVAL_PFTIMES_{NUMFRAMES_COMPUTE, APPSTAMP_COMPUTE,
> > >           PROC_COMPUTE, MISSES_COMPUTE, HIST_ALL_COMPUTE} were missing.
> > >           This has been fixed.
> > >
> > >         o 920517:  GeoArray stride information missing in PFB output.
> > >           Added support for saving/storing pfGeoArray pfVertexAttr
> > >           information in cases where stride information != (size of
> > >           data type * # elements needed to represent type).
> > >
> > >         o 924143:  Prism/IA64 - C++ samples crash in pfMemory::ref().
> > >           Several samples and tools failed on 64-bit Prism systems
> > >           with a stack trace leading to pfMemory::ref().  This was due
> > >           to using 'new pfMemory' for array allocation.  This has been
> > >           fixed.
> > >
> > >         o 924685:  Manpages give error msg on SuSE Linux.  "man pfNode"
> > >           would give this error on SuSE Linux (32-bit and 64-bit):
> > >           man: warning: /usr/man/man3/pfNode.3pf.c.gz: ignoring
> > >              bogus filename
> > >           man: warning: /usr/man/man3/pfNode.3pf.C++.gz: ignoring
> > >              bogus filename
> > >           No manual entry for pfNode.
> > >           This has been fixed.
> > >
> > >         o 927024:  perfly powerwall modes require pipe or
> > >           compositor list.  perfly powerwall mode would hang if
> > >           a pipe list was not specified. This has been fixed.
> > >
> > >         o 927184:  Onyx4: Fill stats cause perfly crash.  Hangs
> > >           and crashes could occur when enabling perfly 'Fill stats'
> > >           on Onyx4.  This has been fixed.
> > >
> > >         o 928429:  Performer does not reset attach address after
> > >           usinit().  Arenas created by the user after calling pfConfig
> > >           may fail with 'resource busy' errors.  This has been fixed.
> > >
> > >         o 929057:  some pfdb header files missing on Windows.
> > >           pfcsb.h, pfiv.h, pflsb.h, pfmedit.h, and pfptu.h were
> > >           missing from <Performer/pfdb> on Windows.  This has been
> > >           fixed.
> > >
> > >         o 929361:  Performer 3.2 MP hangs on startup in pfGetTime().
> > >           When first starting perfly in any multi-process mode on an
> > >           SMP linux system (2.6 kernel), the process will hang just
> > >           after displaying the "OpenGL Performer" text.  This has been
> > >           fixed.
> > >
> > >         o 935755:  Onyx4: performer town textures have black spots.
> > >           This has been fixed.
> > >
> > >         o 936906:  GL_LUMINANCE problems with emulated cliptextures.
> > >           Cliptexture files specifying a 16-bit luminance format (such
> > >           as the hl.L16.ct sample) were not supported when using
> > >           cliptexture emulation.  This has been fixed.
> > >
> > >         o 936963:  Problems in automatic clipsize shrinking.
> > >           Calculations to automatically shrink a given cliptexture if
> > >           it is too large to fit in texture memory were incorrect when
> > >           using cliptexture emulation.  This has been fixed.
> > >
> > >         o 937271:  undefined GL_FUNC_REVERSE_SUBTRACT_EXT in bump
> > >           sample.  Several EXT_blend_minmax, EXT_blend_subtract, and
> > >           EXT_blend_logic_op tokens were missing or used incorrectly.
> > >           This has been fixed.
> > >
> > >         o 937327:  pfuSelectFBConfig.c not installed on linux.  The
> > >           new pfuSelectFBConfig.c file was missing.  This has been
> > > fixed.
> > >
> > >         o 937657:  windows version can't find license.  After
> > >           installing Performer for the first time, the user may be
> > >           prompted by FlexLM for the location of a license.  This has
> > >           been fixed.
> > >
> > >      Problems fixed in OpenGL Performer 3.2 rev E
> > >
> > >           OpenGL Performer 3.2 rev E was a platform-specific release
> > >           for Silicon Graphics Prism only.  All 3.2 rev E fixes are now
> > >           included in the all-platform OpenGL Performer 3.2.1 release.
> > >
> > >         o 909953:  Performance drop with latest nvidia drivers.  The
> > >           default visual was 8x multisampled.  This has been corrected.
> > >
> > >         o 919800, 912651, 924251:  Support for Cliptexture Emulation.
> > >           Cliptexture emulation is now functional on Silicon Graphics
> > >           Prism and Silicon Graphics Onyx4 UltimateVision.
> > >
> > >         o 914183:  pfdBuildTopologyTravese() and
> > >           pfTopo::buildTopology() failure.  This has been corrected.
> > >
> > >         o 921088:  Support for SecondaryColor, FogCoords &
> > >           VertexWeight.  GeoArray support for these data types has
> > >           been added.
> > >
> > >         o 927186:  perfly collision detections don't work in fly mode
> > >           on Prism.  This has been corrected.
> > >
> > >         o 929514:  pfGeoArrays don't handle odd strides.  This has
> > >           been corrected.
> > >
> > >         o 930580:  Perfly crash with large GeoArray pfb file.  This
> > >           has been corrected.
> > >
> > >         o 930594:  .gopt pseudoloader causes infinte loop.  This has
> > >           been corrected.
> > >
> > >         o 931507:  pfQuerySys calls in libpfdu slow file loading.
> > >           This has been corrected.  Note that applications containing
> > >           repeated calls to pfQuerySys(PFQSYS_GL, &q) may also see
> > >           delays.
> > >
> > >         o 932929:  12-pipe support on Silicon Graphics Prism.  OpenGL
> > >           Performer now supports up to 12 pipes on Prism.
> > >
> > >         o 932931:  4-compositor support on Silicon Graphics Prism.
> > >           OpenGL Performer now supports up to 4 compositors on Prism.
> > >
> > >         o 932934:  Support for multiple X servers.  OpenGL Performer
> > >           now supports Silicon Graphics Prism systems configured with
> > >           multiple X servers.
> > >
> > >         o 932936:  Multipipe GLSL.  OpenGL Performer now supports
> > >           OpenGL 2.0 GLSL in multi-pipe configurations
> > >
> > >         o 933277:  Non-power of 2 textures load incorrectly in
> > >           Performer applications.  NPOT textures are now partially
> > >           supported.
> > >
> > >         o 933387:  perfly compositor options & pfCompositor man page.
> > >           perfly's compositor options have been added to the perfly
> > >           man page; and the missing pfCompositor man page is now
> > >           included in the OpenGL Performer distribution.
> > >
> > >         o 933727:  Performer crashes when building topology for trim
> > >           curves & shadow trim curves.  This has been corrected.
> > >
> > >         o 933777:  Some transparent objects not rendered correctly on
> > >           Silicon Graphics Prism. This has been corrected.
> > >
> > >         o 934166:  perfly GUI crashes.  On Silicon Graphics Prism, if
> > >           perfly is run in a multi-process mode with the GUI disabled,
> > >           then the user presses F1 to bring up the GUI, the
> > >           application crashes.  This has been corrected.
> > >
> > >      Problems fixed in OpenGL Performer 3.2 rev D
> > >
> > >           OpenGL Performer 3.2 rev D was a platform-specific release
> > >           for Silicon Graphics Prism only.  All 3.2 rev D fixes are now
> > >           included in the all-platform OpenGL Performer 3.2.1 release.
> > >
> > >         o 925641:  perfly crash on Prism depending on values assigned
> > >           to PFSHAREDSIZE.  Increased default PFSHAREDSIZE to 512MB.
> > >
> > >         o 928974:  pfGeoArray::tryVAOCache() is not multiprocess
> > >           safe.  This has been fixed.
> > >
> > >         o 928975:  Error in pfQueue::getNum().  This has been fixed.
> > >
> > >         o 929848:  Multipipe GLSL support in performer.  GLSL support
> > >           on Prism was only functional on a single pipe.  This has
> > >           been fixed.
> > >
> > >         o 929850:  OpenGL Multipipe interferes with OpenGL Performer.
> > >           Performance may suffer if OpenGL Performer is used while the
> > >           session is in OpenGL Multipipe mode.  Prominent warnings
> > >           have been added.
> > >
> > >         o 929853:  Additional Silicon Graphics Prism product line
> > >           models are now recognized.
> > >
> > >         o 929951:  Performer fails when run under OMP.  This has been
> > >           fixed.
> > >
> > >         o 931057:  performer .gopt loader crash.  Certain datasets
> > >           could cause the .gopt Pseudo-Loader to crash.  This has been
> > >           fixed.
> > >
> > >         o 931290:  Perfly exits with segmentation fault.  perfly would
> > >           sometimes crash on systems with a hardware compositor
> > >           attached.  This has been fixed.
> > >
> > >         o 932007:  Use of hardware swap barriers now disabled by
> > >           default with compositor.  The use of swapbarrier
> > >           functionality can sometimes cause a deadlock on Prism
> > >           systems.  Performer now disables this functionality by
> > >           default, further changing the behavior from 3.2 rev C.  To
> > >           enable the previous behavior the user may set the
> > >           environment variable PFCOMP_DO_SWAPBARRIERS to 1.
> > >
> > >
> > >      Problems fixed in OpenGL Performer 3.2 rev C
> > >
> > >           OpenGL Performer 3.2 rev C was a platform-specific release
> > >           for Silicon Graphics Prism only.  All 3.2 rev C fixes are now
> > >           included in the all-platform OpenGL Performer 3.2.1 release.
> > >
> > >         o 927225: Enable PF_SEMA_BEFORE_SWAP and PFU_LOAD_WIN_CURSOR
> > >           workarounds for swapbarrier deadlock by default.  Set either
> > >           variable to 0 to revert to its pre-workaround behavior.
> > >
> > >
> > >
> > >
> >
> >
> >
> > -------------------------------------------------------
> > SF.Net email is sponsored by:
> > Tame your development challenges with Apache's Geronimo App Server. Download
> > it for free - -and be entered to win a 42" plasma tv or your very own
> > Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> > _______________________________________________
> > diverse-devel mailing list
> > div...@li...
> > https://lists.sourceforge.net/lists/listinfo/diverse-devel
>

Re: [diverse-devel] OpenGL Performer 3.2.1 now available, can i use it??

[Patrick S. <psh...@vt...>]

I have found no issues with Performer 3.2.1 working with DIVERSE.


On Tue, 2005-09-20 at 08:04, John Kelso wrote:
> Hi,
> 
> I built diverse with 3.2.0 a while back without any problems.  I don't
> expect any problems with 3.2.1 either, but will probably not get to it for
> a couple of days.  If you try it before I do, please let the group know if
> you had any problems.
> 
> Thanks,
> 
> -John
> 
> 
> On Tue, 20 Sep 2005, Raymond Wadie wrote:
> 
> >
> > Hi there
> > How is everybody :)
> > OpenGL Performer 3.2.1 is now available
> > I was asking if it is ok to use it, or I should wait until somebody
> > verify that it works fine with diverse?
> > Thanks in advance
> >
> > Ray
> > -----Original Message-----
> > From: own...@pe...
> > [mailto:own...@pe...] On Behalf Of Allan
> > Schaffer
> > Sent: Monday, September 19, 2005 6:26 PM
> > To: info-performer Mailing List
> > Subject: [info-performer] Announcement: OpenGL Performer 3.2.1 now
> > available
> >
> > Hello Performers,
> >
> > SGI is very pleased to announce, OpenGL Performer 3.2.1 is now released!
> >
> > The web downloads for 64-bit Linux, 32-bit Linux, IRIX, and Windows OS
> > platforms are all available.  Please visit the Performer web site:
> >
> >          <http://www.sgi.com/software/performer/>
> >
> > The Demo Edition of Performer 3.2.1 is available as a free web
> > download.  An SGI Supportfolio membership is required to access the
> > download site.  If you don't already have an SGI Supportfolio account
> > you can sign up for free.
> >
> > Here's some of what's new for Performer 3.2.1.  Check it out:
> >
> >      Changes in OpenGL Performer 3.2.1
> >
> >         o Support for SGI ProPack 4 Service Pack 2.  (SCR 936282)
> >           Performer now supports the SGI ProPack 4 Service Pack 2
> >           operating system release for Silicon Graphics Prism.
> >
> >         o Support for Microsoft Visual Studio 7.  (SCR 929852)
> >           Performer now supports the Visual Studio 7 (.NET)
> >           compiler on Windows.
> >
> >         o Performer City demo now included.  (SCR 929989)
> >           The modern "Performer City" demonstration application is
> >           now bundled with OpenGL Performer.
> >           IRIX:    /usr/sbin/pfCity
> >           Linux:   /usr/X11R6/bin/pfCity
> >           Windows: %PFROOT%/bin/pfCity
> >
> >         o New "sgi-performer-clipdemos" rpm on Linux.  (SCR 902282)
> >           Sample cliptexture data is now shipped with OpenGL Performer
> >           for Linux in the sgi-performer-clipdemos RPM file.
> >           See: /usr/share/Performer/data/clipdata
> >
> >         o 914835:  Missing pfStats tokens.  Headers and handlers for
> >           PFFSTATSVAL_PFTIMES_{NUMFRAMES_COMPUTE, APPSTAMP_COMPUTE,
> >           PROC_COMPUTE, MISSES_COMPUTE, HIST_ALL_COMPUTE} were missing.
> >           This has been fixed.
> >
> >         o 920517:  GeoArray stride information missing in PFB output.
> >           Added support for saving/storing pfGeoArray pfVertexAttr
> >           information in cases where stride information != (size of
> >           data type * # elements needed to represent type).
> >
> >         o 924143:  Prism/IA64 - C++ samples crash in pfMemory::ref().
> >           Several samples and tools failed on 64-bit Prism systems
> >           with a stack trace leading to pfMemory::ref().  This was due
> >           to using 'new pfMemory' for array allocation.  This has been
> >           fixed.
> >
> >         o 924685:  Manpages give error msg on SuSE Linux.  "man pfNode"
> >           would give this error on SuSE Linux (32-bit and 64-bit):
> >           man: warning: /usr/man/man3/pfNode.3pf.c.gz: ignoring
> >              bogus filename
> >           man: warning: /usr/man/man3/pfNode.3pf.C++.gz: ignoring
> >              bogus filename
> >           No manual entry for pfNode.
> >           This has been fixed.
> >
> >         o 927024:  perfly powerwall modes require pipe or
> >           compositor list.  perfly powerwall mode would hang if
> >           a pipe list was not specified. This has been fixed.
> >
> >         o 927184:  Onyx4: Fill stats cause perfly crash.  Hangs
> >           and crashes could occur when enabling perfly 'Fill stats'
> >           on Onyx4.  This has been fixed.
> >
> >         o 928429:  Performer does not reset attach address after
> >           usinit().  Arenas created by the user after calling pfConfig
> >           may fail with 'resource busy' errors.  This has been fixed.
> >
> >         o 929057:  some pfdb header files missing on Windows.
> >           pfcsb.h, pfiv.h, pflsb.h, pfmedit.h, and pfptu.h were
> >           missing from <Performer/pfdb> on Windows.  This has been
> >           fixed.
> >
> >         o 929361:  Performer 3.2 MP hangs on startup in pfGetTime().
> >           When first starting perfly in any multi-process mode on an
> >           SMP linux system (2.6 kernel), the process will hang just
> >           after displaying the "OpenGL Performer" text.  This has been
> >           fixed.
> >
> >         o 935755:  Onyx4: performer town textures have black spots.
> >           This has been fixed.
> >
> >         o 936906:  GL_LUMINANCE problems with emulated cliptextures.
> >           Cliptexture files specifying a 16-bit luminance format (such
> >           as the hl.L16.ct sample) were not supported when using
> >           cliptexture emulation.  This has been fixed.
> >
> >         o 936963:  Problems in automatic clipsize shrinking.
> >           Calculations to automatically shrink a given cliptexture if
> >           it is too large to fit in texture memory were incorrect when
> >           using cliptexture emulation.  This has been fixed.
> >
> >         o 937271:  undefined GL_FUNC_REVERSE_SUBTRACT_EXT in bump
> >           sample.  Several EXT_blend_minmax, EXT_blend_subtract, and
> >           EXT_blend_logic_op tokens were missing or used incorrectly.
> >           This has been fixed.
> >
> >         o 937327:  pfuSelectFBConfig.c not installed on linux.  The
> >           new pfuSelectFBConfig.c file was missing.  This has been
> > fixed.
> >
> >         o 937657:  windows version can't find license.  After
> >           installing Performer for the first time, the user may be
> >           prompted by FlexLM for the location of a license.  This has
> >           been fixed.
> >
> >      Problems fixed in OpenGL Performer 3.2 rev E
> >
> >           OpenGL Performer 3.2 rev E was a platform-specific release
> >           for Silicon Graphics Prism only.  All 3.2 rev E fixes are now
> >           included in the all-platform OpenGL Performer 3.2.1 release.
> >
> >         o 909953:  Performance drop with latest nvidia drivers.  The
> >           default visual was 8x multisampled.  This has been corrected.
> >
> >         o 919800, 912651, 924251:  Support for Cliptexture Emulation.
> >           Cliptexture emulation is now functional on Silicon Graphics
> >           Prism and Silicon Graphics Onyx4 UltimateVision.
> >
> >         o 914183:  pfdBuildTopologyTravese() and
> >           pfTopo::buildTopology() failure.  This has been corrected.
> >
> >         o 921088:  Support for SecondaryColor, FogCoords &
> >           VertexWeight.  GeoArray support for these data types has
> >           been added.
> >
> >         o 927186:  perfly collision detections don't work in fly mode
> >           on Prism.  This has been corrected.
> >
> >         o 929514:  pfGeoArrays don't handle odd strides.  This has
> >           been corrected.
> >
> >         o 930580:  Perfly crash with large GeoArray pfb file.  This
> >           has been corrected.
> >
> >         o 930594:  .gopt pseudoloader causes infinte loop.  This has
> >           been corrected.
> >
> >         o 931507:  pfQuerySys calls in libpfdu slow file loading.
> >           This has been corrected.  Note that applications containing
> >           repeated calls to pfQuerySys(PFQSYS_GL, &q) may also see
> >           delays.
> >
> >         o 932929:  12-pipe support on Silicon Graphics Prism.  OpenGL
> >           Performer now supports up to 12 pipes on Prism.
> >
> >         o 932931:  4-compositor support on Silicon Graphics Prism.
> >           OpenGL Performer now supports up to 4 compositors on Prism.
> >
> >         o 932934:  Support for multiple X servers.  OpenGL Performer
> >           now supports Silicon Graphics Prism systems configured with
> >           multiple X servers.
> >
> >         o 932936:  Multipipe GLSL.  OpenGL Performer now supports
> >           OpenGL 2.0 GLSL in multi-pipe configurations
> >
> >         o 933277:  Non-power of 2 textures load incorrectly in
> >           Performer applications.  NPOT textures are now partially
> >           supported.
> >
> >         o 933387:  perfly compositor options & pfCompositor man page.
> >           perfly's compositor options have been added to the perfly
> >           man page; and the missing pfCompositor man page is now
> >           included in the OpenGL Performer distribution.
> >
> >         o 933727:  Performer crashes when building topology for trim
> >           curves & shadow trim curves.  This has been corrected.
> >
> >         o 933777:  Some transparent objects not rendered correctly on
> >           Silicon Graphics Prism. This has been corrected.
> >
> >         o 934166:  perfly GUI crashes.  On Silicon Graphics Prism, if
> >           perfly is run in a multi-process mode with the GUI disabled,
> >           then the user presses F1 to bring up the GUI, the
> >           application crashes.  This has been corrected.
> >
> >      Problems fixed in OpenGL Performer 3.2 rev D
> >
> >           OpenGL Performer 3.2 rev D was a platform-specific release
> >           for Silicon Graphics Prism only.  All 3.2 rev D fixes are now
> >           included in the all-platform OpenGL Performer 3.2.1 release.
> >
> >         o 925641:  perfly crash on Prism depending on values assigned
> >           to PFSHAREDSIZE.  Increased default PFSHAREDSIZE to 512MB.
> >
> >         o 928974:  pfGeoArray::tryVAOCache() is not multiprocess
> >           safe.  This has been fixed.
> >
> >         o 928975:  Error in pfQueue::getNum().  This has been fixed.
> >
> >         o 929848:  Multipipe GLSL support in performer.  GLSL support
> >           on Prism was only functional on a single pipe.  This has
> >           been fixed.
> >
> >         o 929850:  OpenGL Multipipe interferes with OpenGL Performer.
> >           Performance may suffer if OpenGL Performer is used while the
> >           session is in OpenGL Multipipe mode.  Prominent warnings
> >           have been added.
> >
> >         o 929853:  Additional Silicon Graphics Prism product line
> >           models are now recognized.
> >
> >         o 929951:  Performer fails when run under OMP.  This has been
> >           fixed.
> >
> >         o 931057:  performer .gopt loader crash.  Certain datasets
> >           could cause the .gopt Pseudo-Loader to crash.  This has been
> >           fixed.
> >
> >         o 931290:  Perfly exits with segmentation fault.  perfly would
> >           sometimes crash on systems with a hardware compositor
> >           attached.  This has been fixed.
> >
> >         o 932007:  Use of hardware swap barriers now disabled by
> >           default with compositor.  The use of swapbarrier
> >           functionality can sometimes cause a deadlock on Prism
> >           systems.  Performer now disables this functionality by
> >           default, further changing the behavior from 3.2 rev C.  To
> >           enable the previous behavior the user may set the
> >           environment variable PFCOMP_DO_SWAPBARRIERS to 1.
> >
> >
> >      Problems fixed in OpenGL Performer 3.2 rev C
> >
> >           OpenGL Performer 3.2 rev C was a platform-specific release
> >           for Silicon Graphics Prism only.  All 3.2 rev C fixes are now
> >           included in the all-platform OpenGL Performer 3.2.1 release.
> >
> >         o 927225: Enable PF_SEMA_BEFORE_SWAP and PFU_LOAD_WIN_CURSOR
> >           workarounds for swapbarrier deadlock by default.  Set either
> >           variable to 0 to revert to its pre-workaround behavior.
> >
> >
> >
> >
> 
> 
> 
> -------------------------------------------------------
> SF.Net email is sponsored by:
> Tame your development challenges with Apache's Geronimo App Server. Download
> it for free - -and be entered to win a 42" plasma tv or your very own
> Sony(tm)PSP.  Click here to play: http://sourceforge.net/geronimo.php
> _______________________________________________
> diverse-devel mailing list
> div...@li...
> https://lists.sourceforge.net/lists/listinfo/diverse-devel
-- 
Patrick Shinpaugh
Virginia Tech
UVAG System Administrator/Programmer
540-231-2054

Re: [diverse-devel] OpenGL Performer 3.2.1 now available, can i use it??

[John K. <ke...@be...>]

Hi,

I built diverse with 3.2.0 a while back without any problems.  I don't
expect any problems with 3.2.1 either, but will probably not get to it for
a couple of days.  If you try it before I do, please let the group know if
you had any problems.

Thanks,

-John


On Tue, 20 Sep 2005, Raymond Wadie wrote:

>
> Hi there
> How is everybody :)
> OpenGL Performer 3.2.1 is now available
> I was asking if it is ok to use it, or I should wait until somebody
> verify that it works fine with diverse?
> Thanks in advance
>
> Ray
> -----Original Message-----
> From: own...@pe...
> [mailto:own...@pe...] On Behalf Of Allan
> Schaffer
> Sent: Monday, September 19, 2005 6:26 PM
> To: info-performer Mailing List
> Subject: [info-performer] Announcement: OpenGL Performer 3.2.1 now
> available
>
> Hello Performers,
>
> SGI is very pleased to announce, OpenGL Performer 3.2.1 is now released!
>
> The web downloads for 64-bit Linux, 32-bit Linux, IRIX, and Windows OS
> platforms are all available.  Please visit the Performer web site:
>
>          <http://www.sgi.com/software/performer/>
>
> The Demo Edition of Performer 3.2.1 is available as a free web
> download.  An SGI Supportfolio membership is required to access the
> download site.  If you don't already have an SGI Supportfolio account
> you can sign up for free.
>
> Here's some of what's new for Performer 3.2.1.  Check it out:
>
>      Changes in OpenGL Performer 3.2.1
>
>         o Support for SGI ProPack 4 Service Pack 2.  (SCR 936282)
>           Performer now supports the SGI ProPack 4 Service Pack 2
>           operating system release for Silicon Graphics Prism.
>
>         o Support for Microsoft Visual Studio 7.  (SCR 929852)
>           Performer now supports the Visual Studio 7 (.NET)
>           compiler on Windows.
>
>         o Performer City demo now included.  (SCR 929989)
>           The modern "Performer City" demonstration application is
>           now bundled with OpenGL Performer.
>           IRIX:    /usr/sbin/pfCity
>           Linux:   /usr/X11R6/bin/pfCity
>           Windows: %PFROOT%/bin/pfCity
>
>         o New "sgi-performer-clipdemos" rpm on Linux.  (SCR 902282)
>           Sample cliptexture data is now shipped with OpenGL Performer
>           for Linux in the sgi-performer-clipdemos RPM file.
>           See: /usr/share/Performer/data/clipdata
>
>         o 914835:  Missing pfStats tokens.  Headers and handlers for
>           PFFSTATSVAL_PFTIMES_{NUMFRAMES_COMPUTE, APPSTAMP_COMPUTE,
>           PROC_COMPUTE, MISSES_COMPUTE, HIST_ALL_COMPUTE} were missing.
>           This has been fixed.
>
>         o 920517:  GeoArray stride information missing in PFB output.
>           Added support for saving/storing pfGeoArray pfVertexAttr
>           information in cases where stride information != (size of
>           data type * # elements needed to represent type).
>
>         o 924143:  Prism/IA64 - C++ samples crash in pfMemory::ref().
>           Several samples and tools failed on 64-bit Prism systems
>           with a stack trace leading to pfMemory::ref().  This was due
>           to using 'new pfMemory' for array allocation.  This has been
>           fixed.
>
>         o 924685:  Manpages give error msg on SuSE Linux.  "man pfNode"
>           would give this error on SuSE Linux (32-bit and 64-bit):
>           man: warning: /usr/man/man3/pfNode.3pf.c.gz: ignoring
>              bogus filename
>           man: warning: /usr/man/man3/pfNode.3pf.C++.gz: ignoring
>              bogus filename
>           No manual entry for pfNode.
>           This has been fixed.
>
>         o 927024:  perfly powerwall modes require pipe or
>           compositor list.  perfly powerwall mode would hang if
>           a pipe list was not specified. This has been fixed.
>
>         o 927184:  Onyx4: Fill stats cause perfly crash.  Hangs
>           and crashes could occur when enabling perfly 'Fill stats'
>           on Onyx4.  This has been fixed.
>
>         o 928429:  Performer does not reset attach address after
>           usinit().  Arenas created by the user after calling pfConfig
>           may fail with 'resource busy' errors.  This has been fixed.
>
>         o 929057:  some pfdb header files missing on Windows.
>           pfcsb.h, pfiv.h, pflsb.h, pfmedit.h, and pfptu.h were
>           missing from <Performer/pfdb> on Windows.  This has been
>           fixed.
>
>         o 929361:  Performer 3.2 MP hangs on startup in pfGetTime().
>           When first starting perfly in any multi-process mode on an
>           SMP linux system (2.6 kernel), the process will hang just
>           after displaying the "OpenGL Performer" text.  This has been
>           fixed.
>
>         o 935755:  Onyx4: performer town textures have black spots.
>           This has been fixed.
>
>         o 936906:  GL_LUMINANCE problems with emulated cliptextures.
>           Cliptexture files specifying a 16-bit luminance format (such
>           as the hl.L16.ct sample) were not supported when using
>           cliptexture emulation.  This has been fixed.
>
>         o 936963:  Problems in automatic clipsize shrinking.
>           Calculations to automatically shrink a given cliptexture if
>           it is too large to fit in texture memory were incorrect when
>           using cliptexture emulation.  This has been fixed.
>
>         o 937271:  undefined GL_FUNC_REVERSE_SUBTRACT_EXT in bump
>           sample.  Several EXT_blend_minmax, EXT_blend_subtract, and
>           EXT_blend_logic_op tokens were missing or used incorrectly.
>           This has been fixed.
>
>         o 937327:  pfuSelectFBConfig.c not installed on linux.  The
>           new pfuSelectFBConfig.c file was missing.  This has been
> fixed.
>
>         o 937657:  windows version can't find license.  After
>           installing Performer for the first time, the user may be
>           prompted by FlexLM for the location of a license.  This has
>           been fixed.
>
>      Problems fixed in OpenGL Performer 3.2 rev E
>
>           OpenGL Performer 3.2 rev E was a platform-specific release
>           for Silicon Graphics Prism only.  All 3.2 rev E fixes are now
>           included in the all-platform OpenGL Performer 3.2.1 release.
>
>         o 909953:  Performance drop with latest nvidia drivers.  The
>           default visual was 8x multisampled.  This has been corrected.
>
>         o 919800, 912651, 924251:  Support for Cliptexture Emulation.
>           Cliptexture emulation is now functional on Silicon Graphics
>           Prism and Silicon Graphics Onyx4 UltimateVision.
>
>         o 914183:  pfdBuildTopologyTravese() and
>           pfTopo::buildTopology() failure.  This has been corrected.
>
>         o 921088:  Support for SecondaryColor, FogCoords &
>           VertexWeight.  GeoArray support for these data types has
>           been added.
>
>         o 927186:  perfly collision detections don't work in fly mode
>           on Prism.  This has been corrected.
>
>         o 929514:  pfGeoArrays don't handle odd strides.  This has
>           been corrected.
>
>         o 930580:  Perfly crash with large GeoArray pfb file.  This
>           has been corrected.
>
>         o 930594:  .gopt pseudoloader causes infinte loop.  This has
>           been corrected.
>
>         o 931507:  pfQuerySys calls in libpfdu slow file loading.
>           This has been corrected.  Note that applications containing
>           repeated calls to pfQuerySys(PFQSYS_GL, &q) may also see
>           delays.
>
>         o 932929:  12-pipe support on Silicon Graphics Prism.  OpenGL
>           Performer now supports up to 12 pipes on Prism.
>
>         o 932931:  4-compositor support on Silicon Graphics Prism.
>           OpenGL Performer now supports up to 4 compositors on Prism.
>
>         o 932934:  Support for multiple X servers.  OpenGL Performer
>           now supports Silicon Graphics Prism systems configured with
>           multiple X servers.
>
>         o 932936:  Multipipe GLSL.  OpenGL Performer now supports
>           OpenGL 2.0 GLSL in multi-pipe configurations
>
>         o 933277:  Non-power of 2 textures load incorrectly in
>           Performer applications.  NPOT textures are now partially
>           supported.
>
>         o 933387:  perfly compositor options & pfCompositor man page.
>           perfly's compositor options have been added to the perfly
>           man page; and the missing pfCompositor man page is now
>           included in the OpenGL Performer distribution.
>
>         o 933727:  Performer crashes when building topology for trim
>           curves & shadow trim curves.  This has been corrected.
>
>         o 933777:  Some transparent objects not rendered correctly on
>           Silicon Graphics Prism. This has been corrected.
>
>         o 934166:  perfly GUI crashes.  On Silicon Graphics Prism, if
>           perfly is run in a multi-process mode with the GUI disabled,
>           then the user presses F1 to bring up the GUI, the
>           application crashes.  This has been corrected.
>
>      Problems fixed in OpenGL Performer 3.2 rev D
>
>           OpenGL Performer 3.2 rev D was a platform-specific release
>           for Silicon Graphics Prism only.  All 3.2 rev D fixes are now
>           included in the all-platform OpenGL Performer 3.2.1 release.
>
>         o 925641:  perfly crash on Prism depending on values assigned
>           to PFSHAREDSIZE.  Increased default PFSHAREDSIZE to 512MB.
>
>         o 928974:  pfGeoArray::tryVAOCache() is not multiprocess
>           safe.  This has been fixed.
>
>         o 928975:  Error in pfQueue::getNum().  This has been fixed.
>
>         o 929848:  Multipipe GLSL support in performer.  GLSL support
>           on Prism was only functional on a single pipe.  This has
>           been fixed.
>
>         o 929850:  OpenGL Multipipe interferes with OpenGL Performer.
>           Performance may suffer if OpenGL Performer is used while the
>           session is in OpenGL Multipipe mode.  Prominent warnings
>           have been added.
>
>         o 929853:  Additional Silicon Graphics Prism product line
>           models are now recognized.
>
>         o 929951:  Performer fails when run under OMP.  This has been
>           fixed.
>
>         o 931057:  performer .gopt loader crash.  Certain datasets
>           could cause the .gopt Pseudo-Loader to crash.  This has been
>           fixed.
>
>         o 931290:  Perfly exits with segmentation fault.  perfly would
>           sometimes crash on systems with a hardware compositor
>           attached.  This has been fixed.
>
>         o 932007:  Use of hardware swap barriers now disabled by
>           default with compositor.  The use of swapbarrier
>           functionality can sometimes cause a deadlock on Prism
>           systems.  Performer now disables this functionality by
>           default, further changing the behavior from 3.2 rev C.  To
>           enable the previous behavior the user may set the
>           environment variable PFCOMP_DO_SWAPBARRIERS to 1.
>
>
>      Problems fixed in OpenGL Performer 3.2 rev C
>
>           OpenGL Performer 3.2 rev C was a platform-specific release
>           for Silicon Graphics Prism only.  All 3.2 rev C fixes are now
>           included in the all-platform OpenGL Performer 3.2.1 release.
>
>         o 927225: Enable PF_SEMA_BEFORE_SWAP and PFU_LOAD_WIN_CURSOR
>           workarounds for swapbarrier deadlock by default.  Set either
>           variable to 0 to revert to its pre-workaround behavior.
>
>
>
>

[diverse-devel] OpenGL Performer 3.2.1 now available, can i use it??

[Raymond W. <Ray...@bi...>]

Hi there
How is everybody :)
OpenGL Performer 3.2.1 is now available=20
I was asking if it is ok to use it, or I should wait until somebody
verify that it works fine with diverse?
Thanks in advance

Ray
-----Original Message-----
From: own...@pe...
[mailto:own...@pe...] On Behalf Of Allan
Schaffer
Sent: Monday, September 19, 2005 6:26 PM
To: info-performer Mailing List
Subject: [info-performer] Announcement: OpenGL Performer 3.2.1 now
available

Hello Performers,

SGI is very pleased to announce, OpenGL Performer 3.2.1 is now released!

The web downloads for 64-bit Linux, 32-bit Linux, IRIX, and Windows OS
platforms are all available.  Please visit the Performer web site:

         <http://www.sgi.com/software/performer/>

The Demo Edition of Performer 3.2.1 is available as a free web
download.  An SGI Supportfolio membership is required to access the
download site.  If you don't already have an SGI Supportfolio account
you can sign up for free.

Here's some of what's new for Performer 3.2.1.  Check it out:

     Changes in OpenGL Performer 3.2.1

        o Support for SGI ProPack 4 Service Pack 2.  (SCR 936282)
          Performer now supports the SGI ProPack 4 Service Pack 2
          operating system release for Silicon Graphics Prism.

        o Support for Microsoft Visual Studio 7.  (SCR 929852)
          Performer now supports the Visual Studio 7 (.NET)
          compiler on Windows.

        o Performer City demo now included.  (SCR 929989)
          The modern "Performer City" demonstration application is
          now bundled with OpenGL Performer.
          IRIX:    /usr/sbin/pfCity
          Linux:   /usr/X11R6/bin/pfCity
          Windows: %PFROOT%/bin/pfCity

        o New "sgi-performer-clipdemos" rpm on Linux.  (SCR 902282)
          Sample cliptexture data is now shipped with OpenGL Performer
          for Linux in the sgi-performer-clipdemos RPM file.
          See: /usr/share/Performer/data/clipdata

        o 914835:  Missing pfStats tokens.  Headers and handlers for
          PFFSTATSVAL_PFTIMES_{NUMFRAMES_COMPUTE, APPSTAMP_COMPUTE,
          PROC_COMPUTE, MISSES_COMPUTE, HIST_ALL_COMPUTE} were missing.
          This has been fixed.

        o 920517:  GeoArray stride information missing in PFB output.
          Added support for saving/storing pfGeoArray pfVertexAttr
          information in cases where stride information !=3D (size of
          data type * # elements needed to represent type).

        o 924143:  Prism/IA64 - C++ samples crash in pfMemory::ref().
          Several samples and tools failed on 64-bit Prism systems
          with a stack trace leading to pfMemory::ref().  This was due
          to using 'new pfMemory' for array allocation.  This has been
          fixed.

        o 924685:  Manpages give error msg on SuSE Linux.  "man pfNode"
          would give this error on SuSE Linux (32-bit and 64-bit):
          man: warning: /usr/man/man3/pfNode.3pf.c.gz: ignoring
             bogus filename
          man: warning: /usr/man/man3/pfNode.3pf.C++.gz: ignoring
             bogus filename
          No manual entry for pfNode.
          This has been fixed.

        o 927024:  perfly powerwall modes require pipe or
          compositor list.  perfly powerwall mode would hang if
          a pipe list was not specified. This has been fixed.

        o 927184:  Onyx4: Fill stats cause perfly crash.  Hangs
          and crashes could occur when enabling perfly 'Fill stats'
          on Onyx4.  This has been fixed.

        o 928429:  Performer does not reset attach address after
          usinit().  Arenas created by the user after calling pfConfig
          may fail with 'resource busy' errors.  This has been fixed.

        o 929057:  some pfdb header files missing on Windows.
          pfcsb.h, pfiv.h, pflsb.h, pfmedit.h, and pfptu.h were
          missing from <Performer/pfdb> on Windows.  This has been
          fixed.

        o 929361:  Performer 3.2 MP hangs on startup in pfGetTime().
          When first starting perfly in any multi-process mode on an
          SMP linux system (2.6 kernel), the process will hang just
          after displaying the "OpenGL Performer" text.  This has been
          fixed.

        o 935755:  Onyx4: performer town textures have black spots.
          This has been fixed.

        o 936906:  GL_LUMINANCE problems with emulated cliptextures.
          Cliptexture files specifying a 16-bit luminance format (such
          as the hl.L16.ct sample) were not supported when using
          cliptexture emulation.  This has been fixed.

        o 936963:  Problems in automatic clipsize shrinking.
          Calculations to automatically shrink a given cliptexture if
          it is too large to fit in texture memory were incorrect when
          using cliptexture emulation.  This has been fixed.

        o 937271:  undefined GL_FUNC_REVERSE_SUBTRACT_EXT in bump
          sample.  Several EXT_blend_minmax, EXT_blend_subtract, and
          EXT_blend_logic_op tokens were missing or used incorrectly.
          This has been fixed.

        o 937327:  pfuSelectFBConfig.c not installed on linux.  The
          new pfuSelectFBConfig.c file was missing.  This has been
fixed.

        o 937657:  windows version can't find license.  After
          installing Performer for the first time, the user may be
          prompted by FlexLM for the location of a license.  This has
          been fixed.

     Problems fixed in OpenGL Performer 3.2 rev E

          OpenGL Performer 3.2 rev E was a platform-specific release
          for Silicon Graphics Prism only.  All 3.2 rev E fixes are now
          included in the all-platform OpenGL Performer 3.2.1 release.

        o 909953:  Performance drop with latest nvidia drivers.  The
          default visual was 8x multisampled.  This has been corrected.

        o 919800, 912651, 924251:  Support for Cliptexture Emulation.
          Cliptexture emulation is now functional on Silicon Graphics
          Prism and Silicon Graphics Onyx4 UltimateVision.

        o 914183:  pfdBuildTopologyTravese() and
          pfTopo::buildTopology() failure.  This has been corrected.

        o 921088:  Support for SecondaryColor, FogCoords &
          VertexWeight.  GeoArray support for these data types has
          been added.

        o 927186:  perfly collision detections don't work in fly mode
          on Prism.  This has been corrected.

        o 929514:  pfGeoArrays don't handle odd strides.  This has
          been corrected.

        o 930580:  Perfly crash with large GeoArray pfb file.  This
          has been corrected.

        o 930594:  .gopt pseudoloader causes infinte loop.  This has
          been corrected.

        o 931507:  pfQuerySys calls in libpfdu slow file loading.
          This has been corrected.  Note that applications containing
          repeated calls to pfQuerySys(PFQSYS_GL, &q) may also see
          delays.

        o 932929:  12-pipe support on Silicon Graphics Prism.  OpenGL
          Performer now supports up to 12 pipes on Prism.

        o 932931:  4-compositor support on Silicon Graphics Prism.
          OpenGL Performer now supports up to 4 compositors on Prism.

        o 932934:  Support for multiple X servers.  OpenGL Performer
          now supports Silicon Graphics Prism systems configured with
          multiple X servers.

        o 932936:  Multipipe GLSL.  OpenGL Performer now supports
          OpenGL 2.0 GLSL in multi-pipe configurations

        o 933277:  Non-power of 2 textures load incorrectly in
          Performer applications.  NPOT textures are now partially
          supported.

        o 933387:  perfly compositor options & pfCompositor man page.
          perfly's compositor options have been added to the perfly
          man page; and the missing pfCompositor man page is now
          included in the OpenGL Performer distribution.

        o 933727:  Performer crashes when building topology for trim
          curves & shadow trim curves.  This has been corrected.

        o 933777:  Some transparent objects not rendered correctly on
          Silicon Graphics Prism. This has been corrected.

        o 934166:  perfly GUI crashes.  On Silicon Graphics Prism, if
          perfly is run in a multi-process mode with the GUI disabled,
          then the user presses F1 to bring up the GUI, the
          application crashes.  This has been corrected.

     Problems fixed in OpenGL Performer 3.2 rev D

          OpenGL Performer 3.2 rev D was a platform-specific release
          for Silicon Graphics Prism only.  All 3.2 rev D fixes are now
          included in the all-platform OpenGL Performer 3.2.1 release.

        o 925641:  perfly crash on Prism depending on values assigned
          to PFSHAREDSIZE.  Increased default PFSHAREDSIZE to 512MB.

        o 928974:  pfGeoArray::tryVAOCache() is not multiprocess
          safe.  This has been fixed.

        o 928975:  Error in pfQueue::getNum().  This has been fixed.

        o 929848:  Multipipe GLSL support in performer.  GLSL support
          on Prism was only functional on a single pipe.  This has
          been fixed.

        o 929850:  OpenGL Multipipe interferes with OpenGL Performer.
          Performance may suffer if OpenGL Performer is used while the
          session is in OpenGL Multipipe mode.  Prominent warnings
          have been added.

        o 929853:  Additional Silicon Graphics Prism product line
          models are now recognized.

        o 929951:  Performer fails when run under OMP.  This has been
          fixed.

        o 931057:  performer .gopt loader crash.  Certain datasets
          could cause the .gopt Pseudo-Loader to crash.  This has been
          fixed.

        o 931290:  Perfly exits with segmentation fault.  perfly would
          sometimes crash on systems with a hardware compositor
          attached.  This has been fixed.

        o 932007:  Use of hardware swap barriers now disabled by
          default with compositor.  The use of swapbarrier
          functionality can sometimes cause a deadlock on Prism
          systems.  Performer now disables this functionality by
          default, further changing the behavior from 3.2 rev C.  To
          enable the previous behavior the user may set the
          environment variable PFCOMP_DO_SWAPBARRIERS to 1.


     Problems fixed in OpenGL Performer 3.2 rev C

          OpenGL Performer 3.2 rev C was a platform-specific release
          for Silicon Graphics Prism only.  All 3.2 rev C fixes are now
          included in the all-platform OpenGL Performer 3.2.1 release.

        o 927225: Enable PF_SEMA_BEFORE_SWAP and PFU_LOAD_WIN_CURSOR
          workarounds for swapbarrier deadlock by default.  Set either
          variable to 0 to revert to its pre-workaround behavior.



--=20
Allan Schaffer                                            al...@sg...
Engr. Dept. Manager, Visual Systems Group                1-650-933-2160
Silicon Graphics                                     http://www.sgi.com


-----------------------------------------------------------------------
   List Archives, Info, FAQ:  http://www.sgi.com/software/performer/
   Open Development Project:  http://oss.sgi.com/projects/performer/
                Submissions:  inf...@sg...
            Admin. requests:  inf...@sg...
-----------------------------------------------------------------------

Re: [diverse-devel] SGI Downloads

[Steve S. <st...@ni...>]

On Mon, 12 Sep 2005, Patrick Shinpaugh wrote:

> Has anyone tried downloading SGI Performer lately? I've tried various links
> with the same result - a blank page instead of access to a file.
>
> Let me know if any of you have any luck.
>
> Pat
>


Same problem for me. I sent the following:

  Date: Mon, 12 Sep 2005 23:33:52 -0400
  From: Steve Satterfield <st...@ni...>
  To: Performer Mailing List <inf...@sg...>
  Cc: Steve Satterfield <st...@ni...>
  Subject: Problem with down load page?

  The Performer down load page at

  http://www.sgi.com/products/software/performer/downloads.html

  appears to have a problem. When I click on any of the down load, such as
  the 32 bit Linux RPM, all I get is a blank page.

  Thanks for looing into this.
  -Steve

[diverse-devel] SGI Downloads

[Patrick S. <psh...@ad...>]

Has anyone tried downloading SGI Performer lately? I've tried various links
with the same result - a blank page instead of access to a file.

Let me know if any of you have any luck.

Pat

[diverse-devel] DTK cygwin support

[Patrick S. <shp...@vt...>]

Support for Cygwin has been added to DTK. It is available from the =
subversion repositories at opentech. It uses system V IPC but does not =
support pthreads as pthreads-win32 does not fully support =
PTHREAD_PROCESS_SHARED attribute (sharing across processes). I expect =
that it will be ready for release along with the improved Mac OS X port =
as dtk-2.4.14

The README or INSTALL file will be updated with some Cygwin specific =
install info and more testing is required before it is ready for =
release.

RE: [diverse-devel] Results of the Tuesday meeting

[Panar, T. <pa...@ct...>]

 Andrew, that is unkind, mud-slinging is not a way to resolve the issue.
Lance, you do seem hung up on semantics. All of you, why is this in the
diverse-devel mailing list? I subscribed to hear about new developments,
not be a observer of what has basically become a flame war.

Unsubscribing-ly,
-Tammie

-----Original Message-----
From: div...@li...
[mailto:div...@li...] On Behalf Of Andrew
A. Ray
Sent: Friday, September 09, 2005 9:15 AM
To: Lance Arsenault
Cc: diverse-devel
Subject: RE: [diverse-devel] Results of the Tuesday meeting

Hi Lance,

Forgive my mud slinging, but you are really sounding like a drama queen.

Your points are valid to a certain degree, but you are blowing things
out of proportion.

>You claim to the public (on diverse.sf.net) that you are the only=20
>source for DTK, and you maintain it.
Note 1:  Check the contributions page.  You are listed as a maintainer
for DTK.

> You do not acknowledge to the public that there is any other >source
to DTK.
 Input from me on the website and
>sourceforge is rejected, not all, just some things that are >important
to me.
Check the documentation link for DTK, it points to your page.  And we
don't always get everything we want in life.  I know I don't get
everything I want when it comes to DIVERSE.

Also, it is rather annoying to try to explain to everyone the specific
details of a project when most of the time all they want to do is use
it, not figure out where to go for all of the different parts to make it
work and why you want to use those parts.

To me diverse is a unified project and should all be on one site.

>Sounds forked to me, given that I will not work with you any >more....
I've always tried to keep you in the loop with making decisions.  I've
never heard anything bad about the way I've been doing things until now.

>There are many ways to distribute tarballs in a non-confusing >manner,=20
>that
don't exclude credit to other parties.
You are credited properly for DTK.  My name or OpenTech's name is not in
the DTK source anywhere.  If you ask me, having to goto a separate site
that looks dramatically different, and does not have the same goals as
diverse.sf.net to download part of diverse IS confusing.  I'm pretty
sure this is a majority viewpoint also, but I could be wrong.

>You take all the publicity, money, and control; and I can to work >for=20
>you
for nothing.  That's a deal I can refuse.
You've made probably 10 times more off of working on DIVERSE than I have
so be quiet on the money issue.  I'm a grad student and get paid in
ramen noodles whereas you get steak in comparison.  Also, I don't get
paid by the company due to non-compete agreements with VT so don't use
that argument either.

As for publicity my name isn't plastered all over the place, and neither
is yours.  This is a public project and we are all credited rather
equally if you ask me.

As for control...if we really wanted to control DTK, would we even ask
you to be a part of this process?  Would we send you bug fixes?  Would
we even send you email?  No, we wouldn't.

Stop being a conspiracy theorist and realize that things aren't always
right in life, but as long as people are working to change things then
the situation normally improves.

>I didn't ask any questions, and there are none here in this email=20
>either.
You were questioning our process of operation, and I was explaining
that.
>
>Clearly you don't want to work with me, so there's no need to respond.
If I didn't want to work with you, do you really think I would spend
time trying to iron these issues out?

>You are the master now.  Good luck with that.
There is no one person in charge of DIVERSE, get used to that.

Sincerely,

Andrew A. Ray



-------------------------------------------------------
SF.Net email is Sponsored by the Better Software Conference & EXPO
September 19-22, 2005 * San Francisco, CA * Development Lifecycle
Practices Agile & Plan-Driven Development * Managing Projects & Teams *
Testing & QA Security * Process Improvement & Measurement *
http://www.sqe.com/bsce5sf
_______________________________________________
diverse-devel mailing list
div...@li...
https://lists.sourceforge.net/lists/listinfo/diverse-devel

RE: [diverse-devel] Results of the Tuesday meeting

[Andrew A. R. <an...@vt...>]

Hi Lance,

Forgive my mud slinging, but you are really sounding like a drama queen.

Your points are valid to a certain degree, but you are blowing things out of 
proportion.

>You claim to the public (on diverse.sf.net) that you are the only source
>for DTK, and you maintain it.
Note 1:  Check the contributions page.  You are listed as a maintainer for 
DTK.

> You do not acknowledge to the public that there is any other >source to DTK.
 Input from me on the website and
>sourceforge is rejected, not all, just some things that are >important to me.
Check the documentation link for DTK, it points to your page.  And we don't 
always get everything we want in life.  I know I don't get everything I want 
when it comes to DIVERSE.

Also, it is rather annoying to try to explain to everyone the specific details 
of a project when most of the time all they want to do is use it, not figure 
out where to go for all of the different parts to make it work and why you 
want to use those parts.

To me diverse is a unified project and should all be on one site.

>Sounds forked to me, given that I will not work with you any >more....
I've always tried to keep you in the loop with making decisions.  I've never 
heard anything bad about the way I've been doing things until now.

>There are many ways to distribute tarballs in a non-confusing >manner, that 
don't exclude credit to other parties.
You are credited properly for DTK.  My name or OpenTech's name is not in the 
DTK source anywhere.  If you ask me, having to goto a separate site that looks 
dramatically different, and does not have the same goals as diverse.sf.net to 
download part of diverse IS confusing.  I'm pretty sure this is a majority 
viewpoint also, but I could be wrong.

>You take all the publicity, money, and control; and I can to work >for you 
for nothing.  That's a deal I can refuse.
You've made probably 10 times more off of working on DIVERSE than I have so be 
quiet on the money issue.  I'm a grad student and get paid in ramen noodles 
whereas you get steak in comparison.  Also, I don't get paid by the company 
due to non-compete agreements with VT so don't use that argument either.

As for publicity my name isn't plastered all over the place, and neither is 
yours.  This is a public project and we are all credited rather equally if you 
ask me.

As for control...if we really wanted to control DTK, would we even ask you to 
be a part of this process?  Would we send you bug fixes?  Would we even send 
you email?  No, we wouldn't.

Stop being a conspiracy theorist and realize that things aren't always right 
in life, but as long as people are working to change things then the situation 
normally improves.

>I didn't ask any questions, and there are none here in this email
>either.
You were questioning our process of operation, and I was explaining that.
>
>Clearly you don't want to work with me, so there's no need to respond.
If I didn't want to work with you, do you really think I would spend time 
trying to iron these issues out?

>You are the master now.  Good luck with that.
There is no one person in charge of DIVERSE, get used to that.

Sincerely,

Andrew A. Ray

Re: [diverse-devel] Results of the Tuesday meeting

[Lance A. <lan...@ph...>]

Hi Andrew,

It sounds to me like you forked.

You claim to the public (on diverse.sf.net) that you are the only source 
for DTK, and you maintain it.  You do not acknowledge to the public that 
there is any other source to DTK.  Input from me on the website and 
sourceforge is rejected, not all, just some things that are important to 
me.

Sounds forked to me, given that I will not work with you any more....


There are many ways to distribute tarballs in a non-confusing manner, that 
don't exclude credit to other parties.


You take all the publicity, money, and control; and I can to work for you 
for nothing.  That's a deal I can refuse.


>
> Does this resolve your questions?
>
I didn't ask any questions, and there are none here in this email 
either.


Clearly you don't want to work with me, so there's no need to respond. 
You are the master now.  Good luck with that.

cheers
lance



On Thu, 8 Sep 2005 an...@vt... wrote:

> Hi all,
>
> I thought I said this before, but I'll reiterate this point again.  The only
> reason why we have dtk releases on diverse.sourceforge.net instead of linking
> to diversetoolkit.sourceforge.net is because when you release a dtk tarball
> you normally do not test it on Mac, IRIX, and possibly Windows.  You also
> normally do not test it with DPF, DGL, or DADS either from what I know.  We
> do all of this testing for you in order to make sure that everyone works
> together.  When a tarball has passed the test and works with all of the other
> DIVERSE components then we put it on diverse.sourceforge.net to signify that
> it works with everything.  Remember the prime directive of works by default.
> Without testing we can't make that happen.
>
> To me this is not forking DTK.  It is a testing process where we take what you
> have and rubber stamp it for everything else.  This process probably needs to
> be added to the downloads page so that everyone is clear why there are two
> DTK sources out there.
>
> Does this resolve your questions?
>
> Lastly, your original idea of having a dtk.sourceforge.net,
> dpf.sourceforge.net, dgl.sourceforge.net, and diverse.sourceforge.net is too
> complicated in my opinion.  DIVERSE is one project with several different
> components.  Having one location where you can download everything DIVERSE
> related is important in my opinion.  Packages we do not test / maintain
> should not be linked on the DIVERSE website.  I am pretty sure that is true
> now.
>
> Sincerely,
>
> Andrew A. Ray
> On Thursday 08 September 2005 9:26 am, Lance Arsenault wrote:
>>>> I'm currently optimistic, but testy about opentech taking the lead
>>>> here.
>>>
>>> This is going to be controversial, but I think we need to have this
>>> discussion.  Who do you want to take the lead on this then?  We are all
>>> trying to help DIVERSE.  As far as I know OTI isn't trying to brand
>>> DIVERSE as their product.  From my point of view OTI has tried to make
>>> DIVERSE more professional and has gotten grief for just about everything
>>> they've done with no thanks for what they have done.
>>
>> It's interesting how views and things evolve.
>>
>> I'd like to make one thing very clear:  If you display yourself to the
>> public as the source of DTK, you have made yourself independent of me and
>> you have made it very clear that you do not work with me.  This has not
>> been fixed yet.  So I guess I'm still not working with you yet.
>>
>> I call this professional courtesy.   It's okay to fork DTK, but not if you
>> want me to work with you.
>>
>> You call professional, what I call fluffy.  It's just a difference of
>> opinion.
>>
>> You (used to) redistribute FLTK, but you do not work with anyone that does
>> any FLTK development, so that's different.  You're not claiming that you
>> are the source of FLTK and I see now you link to the offical FLTK site, so
>> there is more professional courtesy there now.
>>
>>
>> cheers
>> lance
>>
>> On Wed, 7 Sep 2005, Andrew A. Ray wrote:
>>> Hi all,
>>>
>>>> Hi all,
>>>>
>>>> 1.
>>>>
>>>> Andrew is saying something that is misleading: I'd be willing to bet
>>>> that I could make doxygen source files that could generate the current
>>>> diverse.fs.net pages as they are when your browser views them.  Unless
>>>> I'm missing something, PHP does not generate anything on the current
>>>> pages that could not be in an auto-pre-generated static page.
>>>
>>> I agree with Dans reply on this message.  It may be possible, but the
>>> overall maintenance on it is probably much greater than what is currently
>>> there.
>>>
>>>>> -Style (should we keep current style or goto a doxygen generated
>>>>> website)
>>>>
>>>> Doxygen does not impose much on style.  To list this as -Style is a
>>>> little misleading.  Doxygen lets you use any stylesheet you like.  But
>>>> it does restrict a lot of the structure of the auto-generated things,
>>>> which would not exist otherwise.
>>>>
>>>> Adding:  I think you could do some, in a sense, "client-side include"
>>>> using small pieces of javascript.  That is if you don't like all the
>>>> repeated file content in the html docs from doxygen. But that may be bad
>>>> because it hoses browsers like lynx. What else can do dynamic client
>>>> side html content?  I don't know off hand.
>>>
>>> I see a big difference between web pages and documentation.  I think we
>>> do need to keep all documentation up to date via doxygen.  By using
>>> doxygen we can keep up the documentation auto generated and up to date.
>>> This should take care of the website issues that we have.
>>>
>>>> Not necessarily quickly, but I'm hoping that they don't disappear
>>>> without explanation.
>>>
>>> Understood, this is a problem.  It seems that it is fixed though.
>>>
>>>> I'm currently optimistic, but testy about opentech taking the lead here.
>>>
>>> This is going to be controversial, but I think we need to have this
>>> discussion.  Who do you want to take the lead on this then?  We are all
>>> trying to help DIVERSE.  As far as I know OTI isn't trying to brand
>>> DIVERSE as their product.  From my point of view OTI has tried to make
>>> DIVERSE more professional and has gotten grief for just about everything
>>> they've done with no thanks for what they have done.
>>>
>>> I know everything that hasn't been done is perfect and there are issues,
>>> such as the website isn't that up to date.  However, no one seems to look
>>> at the positive fact that it is a professional website.  Also, the
>>> services for repository management and web site management were meant to
>>> make peoples lives easier.  The biggest issue in all of this is that
>>> there is a .com in the address.  Other than that there isn't an issue
>>> from what I've seen.
>>>
>>> I think if we get a diversevr.org address and have it hosted on the OTI
>>> servers it will allow OTI to provide state of the art solutions to help
>>> keep DIVERSE alive and still give it a completely open source feel.
>>>
>>> Just so you all know.  OTI does not have the resources to do much work on
>>> DIVERSE outside of what they get paid to do.  Some individuals in the
>>> company such as myself put time into doing DIVERSE work outside of what
>>> we get paid for.  We are all working to improve DIVERSE, let us start
>>> working together effectively.
>>>
>>> Sincerely,
>>>
>>> Andrew A. Ray
>>>
>>>> ===== Original Message From Lance Arsenault <lan...@ph...> =====
>>>> Hi all,
>>>>
>>>> 1.
>>>>
>>>> Andrew is saying something that is misleading: I'd be willing to bet
>>>> that I could make doxygen source files that could generate the current
>>>> diverse.fs.net pages as they are when your browser views them.  Unless
>>>> I'm missing something, PHP does not generate anything on the current
>>>> pages that could not be in an auto-pre-generated static page.
>>>>
>>>> Any bet takers?  I'm up for it.
>>>>
>>>>> -Style (should we keep current style or goto a doxygen generated
>>>>> website)
>>>>
>>>> Doxygen does not impose much on style.  To list this as -Style is a
>>>> little misleading.  Doxygen lets you use any stylesheet you like.  But
>>>> it does restrict a lot of the structure of the auto-generated things,
>>>> which would not exist otherwise.
>>>>
>>>> Adding:  I think you could do some, in a sense, "client-side include"
>>>> using small pieces of javascript.  That is if you don't like all the
>>>> repeated file content in the html docs from doxygen. But that may be bad
>>>> because it hoses browsers like lynx. What else can do dynamic client
>>>> side html content?  I don't know off hand.
>>>>
>>>>
>>>> In general I think Doxygen is only half way there, but I beats anything
>>>> else I know of.
>>>>
>>>>
>>>> 2.
>>>>
>>>>> The issuses in Bugzilla put in by Lance need to be resolved quickly.
>>>>> The only one that may take some time is investigating how to obtain
>>>>> diverse.org
>>>>
>>>> Not necessarily quickly, but I'm hoping that they don't disappear
>>>> without explanation.  I must admit some bug records can just be due to
>>>> my misconceptions.  I got unhappy when I noticed that one of my bugs
>>>> went away without a response, but that may be because I didn't have my
>>>> bugzilla email preferences set verbose enough. I think I have it as
>>>> verbose as possible now.   I'll be adding more.
>>>>
>>>> I'm currently optimistic, but testy about opentech taking the lead here.
>>>> Before I was just pissed off, because of Dan's half baked responses (in
>>>> my fatheaded opinion, of course) to my concerns.  I guess I love debate.
>>>>
>>>>
>>>> cheers
>>>> lance
>>>>
>>>> On Tue, 6 Sep 2005 an...@vt... wrote:
>>>>> Hello everyone,
>>>>>
>>>>> Here are the results from the latest meeting.  John Kelso, Lance
>>>>> Arsenault, Patrick Shinpaugh, Ron Kriz, Steve Satterfield (by
>>>>> conference phone), Denis Gracanin, and Andrew A. Ray were present at
>>>>> the meeting.
>>>>>
>>>>> There is a big need to do something about the website.  Here are a list
>>>>> of
>>>
>>> a
>>>
>>>>> few of the issues that were raised.
>>>>> 	-Timely updates
>>>>> 	-Updated information
>>>>> 	-Style (should we keep current style or goto a doxygen generated
>>>>> website) -Adding information to diverse.opentechinc.com to say it is
>>>>> just a testing ground for the diverse.sourceforge.net website and not a
>>>>> second site that seems similar but has no information about why it
>>>>> exists.  People didn't
>>>
>>> seem
>>>
>>>>> to understand the idea behind having SVN and the web page on OT.
>>>>> 	-How do people update the website manually?
>>>>> 	-Readding the prime directives to the website
>>>>> 	-Add history of NIST and perhaps weave the DTK history into the
>>>>> DIVERSE history
>>>>> 	-Have links pointing to everything (not exactly sure what Lance wants
>>>
>>> here)
>>>
>>>>> The idea of s and u added to the tarballs name was approved.  Does
>>>>> everyone that is a developer have the permissions and ability to branch
>>>>> and merge
>>>
>>> code
>>>
>>>>> in the subversion repository?
>>>>>
>>>>> The issuses in Bugzilla put in by Lance need to be resolved quickly.
>>>>> The
>>>
>>> only
>>>
>>>>> one that may take some time is investigating how to obtain diverse.org
>>>>>
>>>>> Let me know if I missed anything or misreported something.
>>>>>
>>>>> Sincerely,
>>>>>
>>>>> Andrew A. Ray
>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> diverse-devel mailing list
> div...@li...
> https://lists.sourceforge.net/lists/listinfo/diverse-devel
>

[diverse-devel] dtkTime

[Daniel L. <dla...@op...>]

All,
     I would like to make a suggestion for a new feature to add to  
dtkTime.  Because time is relative dtkTime should be configurable  
such that it can either use the system time, or a time set  
programatically each frame.  In this way all applications that use  
dtkTime can operate in a simulated time environment that can be  
consistent across all of the machines in the cluster or for  
artificially slowing down or speeding up time-based calculations.

     The change I propose would add two static functions and two  
static variables dtkTime().  The first variable would be a boolean  
that determines whether to use system time or simulation/frame time.   
The second would be used to set the simulation time.

     This shouldn't affect any code unless it attempts to measure  
time within the same frame.  If there is any code that does this I  
would have to question why?

     After we add these two functions the rest of the functions would  
be modified to read either system time or simulation time.

     This would be one small step toward getting better cluster  
support for DIVERSE & VEWL.

     What are your thoughts?

     I have posted this to bugzilla.opentechinc.com as bug 22: http:// 
bugzilla.opentechinc.com:8888/show_bug.cgi?id=22

Dan

Re: [diverse-devel] Results of the Tuesday meeting

[<an...@vt...>]

Hi all,

I thought I said this before, but I'll reiterate this point again.  The only 
reason why we have dtk releases on diverse.sourceforge.net instead of linking 
to diversetoolkit.sourceforge.net is because when you release a dtk tarball 
you normally do not test it on Mac, IRIX, and possibly Windows.  You also 
normally do not test it with DPF, DGL, or DADS either from what I know.  We 
do all of this testing for you in order to make sure that everyone works 
together.  When a tarball has passed the test and works with all of the other 
DIVERSE components then we put it on diverse.sourceforge.net to signify that 
it works with everything.  Remember the prime directive of works by default.  
Without testing we can't make that happen.

To me this is not forking DTK.  It is a testing process where we take what you 
have and rubber stamp it for everything else.  This process probably needs to 
be added to the downloads page so that everyone is clear why there are two 
DTK sources out there.

Does this resolve your questions?

Lastly, your original idea of having a dtk.sourceforge.net, 
dpf.sourceforge.net, dgl.sourceforge.net, and diverse.sourceforge.net is too 
complicated in my opinion.  DIVERSE is one project with several different 
components.  Having one location where you can download everything DIVERSE 
related is important in my opinion.  Packages we do not test / maintain 
should not be linked on the DIVERSE website.  I am pretty sure that is true 
now.

Sincerely,

Andrew A. Ray
On Thursday 08 September 2005 9:26 am, Lance Arsenault wrote:
> >> I'm currently optimistic, but testy about opentech taking the lead
> >> here.
> >
> >This is going to be controversial, but I think we need to have this
> >discussion.  Who do you want to take the lead on this then?  We are all
> >trying to help DIVERSE.  As far as I know OTI isn't trying to brand
> >DIVERSE as their product.  From my point of view OTI has tried to make
> >DIVERSE more professional and has gotten grief for just about everything
> >they've done with no thanks for what they have done.
>
> It's interesting how views and things evolve.
>
> I'd like to make one thing very clear:  If you display yourself to the
> public as the source of DTK, you have made yourself independent of me and
> you have made it very clear that you do not work with me.  This has not
> been fixed yet.  So I guess I'm still not working with you yet.
>
> I call this professional courtesy.   It's okay to fork DTK, but not if you
> want me to work with you.
>
> You call professional, what I call fluffy.  It's just a difference of
> opinion.
>
> You (used to) redistribute FLTK, but you do not work with anyone that does
> any FLTK development, so that's different.  You're not claiming that you
> are the source of FLTK and I see now you link to the offical FLTK site, so
> there is more professional courtesy there now.
>
>
> cheers
> lance
>
> On Wed, 7 Sep 2005, Andrew A. Ray wrote:
> > Hi all,
> >
> >> Hi all,
> >>
> >> 1.
> >>
> >> Andrew is saying something that is misleading: I'd be willing to bet
> >> that I could make doxygen source files that could generate the current
> >> diverse.fs.net pages as they are when your browser views them.  Unless
> >> I'm missing something, PHP does not generate anything on the current
> >> pages that could not be in an auto-pre-generated static page.
> >
> > I agree with Dans reply on this message.  It may be possible, but the
> > overall maintenance on it is probably much greater than what is currently
> > there.
> >
> >>> -Style (should we keep current style or goto a doxygen generated
> >>> website)
> >>
> >> Doxygen does not impose much on style.  To list this as -Style is a
> >> little misleading.  Doxygen lets you use any stylesheet you like.  But
> >> it does restrict a lot of the structure of the auto-generated things,
> >> which would not exist otherwise.
> >>
> >> Adding:  I think you could do some, in a sense, "client-side include"
> >> using small pieces of javascript.  That is if you don't like all the
> >> repeated file content in the html docs from doxygen. But that may be bad
> >> because it hoses browsers like lynx. What else can do dynamic client
> >> side html content?  I don't know off hand.
> >
> > I see a big difference between web pages and documentation.  I think we
> > do need to keep all documentation up to date via doxygen.  By using
> > doxygen we can keep up the documentation auto generated and up to date. 
> > This should take care of the website issues that we have.
> >
> >> Not necessarily quickly, but I'm hoping that they don't disappear
> >> without explanation.
> >
> > Understood, this is a problem.  It seems that it is fixed though.
> >
> >> I'm currently optimistic, but testy about opentech taking the lead here.
> >
> > This is going to be controversial, but I think we need to have this
> > discussion.  Who do you want to take the lead on this then?  We are all
> > trying to help DIVERSE.  As far as I know OTI isn't trying to brand
> > DIVERSE as their product.  From my point of view OTI has tried to make
> > DIVERSE more professional and has gotten grief for just about everything
> > they've done with no thanks for what they have done.
> >
> > I know everything that hasn't been done is perfect and there are issues,
> > such as the website isn't that up to date.  However, no one seems to look
> > at the positive fact that it is a professional website.  Also, the
> > services for repository management and web site management were meant to
> > make peoples lives easier.  The biggest issue in all of this is that
> > there is a .com in the address.  Other than that there isn't an issue
> > from what I've seen.
> >
> > I think if we get a diversevr.org address and have it hosted on the OTI
> > servers it will allow OTI to provide state of the art solutions to help
> > keep DIVERSE alive and still give it a completely open source feel.
> >
> > Just so you all know.  OTI does not have the resources to do much work on
> > DIVERSE outside of what they get paid to do.  Some individuals in the
> > company such as myself put time into doing DIVERSE work outside of what
> > we get paid for.  We are all working to improve DIVERSE, let us start
> > working together effectively.
> >
> > Sincerely,
> >
> > Andrew A. Ray
> >
> >> ===== Original Message From Lance Arsenault <lan...@ph...> =====
> >> Hi all,
> >>
> >> 1.
> >>
> >> Andrew is saying something that is misleading: I'd be willing to bet
> >> that I could make doxygen source files that could generate the current
> >> diverse.fs.net pages as they are when your browser views them.  Unless
> >> I'm missing something, PHP does not generate anything on the current
> >> pages that could not be in an auto-pre-generated static page.
> >>
> >> Any bet takers?  I'm up for it.
> >>
> >>> -Style (should we keep current style or goto a doxygen generated
> >>> website)
> >>
> >> Doxygen does not impose much on style.  To list this as -Style is a
> >> little misleading.  Doxygen lets you use any stylesheet you like.  But
> >> it does restrict a lot of the structure of the auto-generated things,
> >> which would not exist otherwise.
> >>
> >> Adding:  I think you could do some, in a sense, "client-side include"
> >> using small pieces of javascript.  That is if you don't like all the
> >> repeated file content in the html docs from doxygen. But that may be bad
> >> because it hoses browsers like lynx. What else can do dynamic client
> >> side html content?  I don't know off hand.
> >>
> >>
> >> In general I think Doxygen is only half way there, but I beats anything
> >> else I know of.
> >>
> >>
> >> 2.
> >>
> >>> The issuses in Bugzilla put in by Lance need to be resolved quickly.
> >>> The only one that may take some time is investigating how to obtain
> >>> diverse.org
> >>
> >> Not necessarily quickly, but I'm hoping that they don't disappear
> >> without explanation.  I must admit some bug records can just be due to
> >> my misconceptions.  I got unhappy when I noticed that one of my bugs
> >> went away without a response, but that may be because I didn't have my
> >> bugzilla email preferences set verbose enough. I think I have it as
> >> verbose as possible now.   I'll be adding more.
> >>
> >> I'm currently optimistic, but testy about opentech taking the lead here.
> >> Before I was just pissed off, because of Dan's half baked responses (in
> >> my fatheaded opinion, of course) to my concerns.  I guess I love debate.
> >>
> >>
> >> cheers
> >> lance
> >>
> >> On Tue, 6 Sep 2005 an...@vt... wrote:
> >>> Hello everyone,
> >>>
> >>> Here are the results from the latest meeting.  John Kelso, Lance
> >>> Arsenault, Patrick Shinpaugh, Ron Kriz, Steve Satterfield (by
> >>> conference phone), Denis Gracanin, and Andrew A. Ray were present at
> >>> the meeting.
> >>>
> >>> There is a big need to do something about the website.  Here are a list
> >>> of
> >
> > a
> >
> >>> few of the issues that were raised.
> >>> 	-Timely updates
> >>> 	-Updated information
> >>> 	-Style (should we keep current style or goto a doxygen generated
> >>> website) -Adding information to diverse.opentechinc.com to say it is
> >>> just a testing ground for the diverse.sourceforge.net website and not a
> >>> second site that seems similar but has no information about why it
> >>> exists.  People didn't
> >
> > seem
> >
> >>> to understand the idea behind having SVN and the web page on OT.
> >>> 	-How do people update the website manually?
> >>> 	-Readding the prime directives to the website
> >>> 	-Add history of NIST and perhaps weave the DTK history into the
> >>> DIVERSE history
> >>> 	-Have links pointing to everything (not exactly sure what Lance wants
> >
> > here)
> >
> >>> The idea of s and u added to the tarballs name was approved.  Does
> >>> everyone that is a developer have the permissions and ability to branch
> >>> and merge
> >
> > code
> >
> >>> in the subversion repository?
> >>>
> >>> The issuses in Bugzilla put in by Lance need to be resolved quickly. 
> >>> The
> >
> > only
> >
> >>> one that may take some time is investigating how to obtain diverse.org
> >>>
> >>> Let me know if I missed anything or misreported something.
> >>>
> >>> Sincerely,
> >>>
> >>> Andrew A. Ray

RE: [diverse-devel] Results of the Tuesday meeting

[Lance A. <lan...@ph...>]

>> I'm currently optimistic, but testy about opentech taking the lead 
>> here.

>This is going to be controversial, but I think we need to have this 
>discussion.  Who do you want to take the lead on this then?  We are all 
>trying to help DIVERSE.  As far as I know OTI isn't trying to brand 
>DIVERSE as their product.  From my point of view OTI has tried to make 
>DIVERSE more professional and has gotten grief for just about everything 
>they've done with no thanks for what they have done.

It's interesting how views and things evolve.

I'd like to make one thing very clear:  If you display yourself to the 
public as the source of DTK, you have made yourself independent of me and 
you have made it very clear that you do not work with me.  This has not 
been fixed yet.  So I guess I'm still not working with you yet.

I call this professional courtesy.   It's okay to fork DTK, but not if you 
want me to work with you.

You call professional, what I call fluffy.  It's just a difference of 
opinion.

You (used to) redistribute FLTK, but you do not work with anyone that does 
any FLTK development, so that's different.  You're not claiming that you 
are the source of FLTK and I see now you link to the offical FLTK site, so 
there is more professional courtesy there now.


cheers
lance


On Wed, 7 Sep 2005, Andrew A. Ray wrote:

> Hi all,
>>
>> Hi all,
>>
>> 1.
>>
>> Andrew is saying something that is misleading: I'd be willing to bet
>> that I could make doxygen source files that could generate the current
>> diverse.fs.net pages as they are when your browser views them.  Unless I'm
>> missing something, PHP does not generate anything on the current pages
>> that could not be in an auto-pre-generated static page.
>
> I agree with Dans reply on this message.  It may be possible, but the overall
> maintenance on it is probably much greater than what is currently there.
>
>>> -Style (should we keep current style or goto a doxygen generated website)
>>
>> Doxygen does not impose much on style.  To list this as -Style is a little
>> misleading.  Doxygen lets you use any stylesheet you like.  But it does
>> restrict a lot of the structure of the auto-generated things, which would
>> not exist otherwise.
>>
>> Adding:  I think you could do some, in a sense, "client-side include"
>> using small pieces of javascript.  That is if you don't like all the
>> repeated file content in the html docs from doxygen. But that may be bad
>> because it hoses browsers like lynx. What else can do dynamic client side
>> html content?  I don't know off hand.
>
> I see a big difference between web pages and documentation.  I think we do
> need to keep all documentation up to date via doxygen.  By using doxygen we
> can keep up the documentation auto generated and up to date.  This should take
> care of the website issues that we have.
>
>>
>> Not necessarily quickly, but I'm hoping that they don't disappear without
>> explanation.
> Understood, this is a problem.  It seems that it is fixed though.
>
>> I'm currently optimistic, but testy about opentech taking the lead here.
>
> This is going to be controversial, but I think we need to have this
> discussion.  Who do you want to take the lead on this then?  We are all trying
> to help DIVERSE.  As far as I know OTI isn't trying to brand DIVERSE as their
> product.  From my point of view OTI has tried to make DIVERSE more
> professional and has gotten grief for just about everything they've done with
> no thanks for what they have done.
>
> I know everything that hasn't been done is perfect and there are issues, such
> as the website isn't that up to date.  However, no one seems to look at the
> positive fact that it is a professional website.  Also, the services for
> repository management and web site management were meant to make peoples lives
> easier.  The biggest issue in all of this is that there is a .com in the
> address.  Other than that there isn't an issue from what I've seen.
>
> I think if we get a diversevr.org address and have it hosted on the OTI
> servers it will allow OTI to provide state of the art solutions to help keep
> DIVERSE alive and still give it a completely open source feel.
>
> Just so you all know.  OTI does not have the resources to do much work on
> DIVERSE outside of what they get paid to do.  Some individuals in the company
> such as myself put time into doing DIVERSE work outside of what we get paid
> for.  We are all working to improve DIVERSE, let us start working together
> effectively.
>
> Sincerely,
>
> Andrew A. Ray
>> ===== Original Message From Lance Arsenault <lan...@ph...> =====
>> Hi all,
>>
>> 1.
>>
>> Andrew is saying something that is misleading: I'd be willing to bet
>> that I could make doxygen source files that could generate the current
>> diverse.fs.net pages as they are when your browser views them.  Unless I'm
>> missing something, PHP does not generate anything on the current pages
>> that could not be in an auto-pre-generated static page.
>>
>> Any bet takers?  I'm up for it.
>>
>>
>>> -Style (should we keep current style or goto a doxygen generated website)
>>
>> Doxygen does not impose much on style.  To list this as -Style is a little
>> misleading.  Doxygen lets you use any stylesheet you like.  But it does
>> restrict a lot of the structure of the auto-generated things, which would
>> not exist otherwise.
>>
>> Adding:  I think you could do some, in a sense, "client-side include"
>> using small pieces of javascript.  That is if you don't like all the
>> repeated file content in the html docs from doxygen. But that may be bad
>> because it hoses browsers like lynx. What else can do dynamic client side
>> html content?  I don't know off hand.
>>
>>
>> In general I think Doxygen is only half way there, but I beats anything
>> else I know of.
>>
>>
>> 2.
>>
>>> The issuses in Bugzilla put in by Lance need to be resolved quickly.
>>> The only one that may take some time is investigating how to obtain
>>> diverse.org
>>
>> Not necessarily quickly, but I'm hoping that they don't disappear without
>> explanation.  I must admit some bug records can just be due to my
>> misconceptions.  I got unhappy when I noticed that one of my bugs went
>> away without a response, but that may be because I didn't have my bugzilla
>> email preferences set verbose enough. I think I have it as verbose as
>> possible now.   I'll be adding more.
>>
>> I'm currently optimistic, but testy about opentech taking the lead here.
>> Before I was just pissed off, because of Dan's half baked responses (in my
>> fatheaded opinion, of course) to my concerns.  I guess I love debate.
>>
>>
>> cheers
>> lance
>>
>>
>> On Tue, 6 Sep 2005 an...@vt... wrote:
>>
>>> Hello everyone,
>>>
>>> Here are the results from the latest meeting.  John Kelso, Lance Arsenault,
>>> Patrick Shinpaugh, Ron Kriz, Steve Satterfield (by conference phone), Denis
>>> Gracanin, and Andrew A. Ray were present at the meeting.
>>>
>>> There is a big need to do something about the website.  Here are a list of
> a
>>> few of the issues that were raised.
>>> 	-Timely updates
>>> 	-Updated information
>>> 	-Style (should we keep current style or goto a doxygen generated website)
>>> 	-Adding information to diverse.opentechinc.com to say it is just a testing
>>> ground for the diverse.sourceforge.net website and not a second site that
>>> seems similar but has no information about why it exists.  People didn't
> seem
>>> to understand the idea behind having SVN and the web page on OT.
>>> 	-How do people update the website manually?
>>> 	-Readding the prime directives to the website
>>> 	-Add history of NIST and perhaps weave the DTK history into the DIVERSE
>>> history
>>> 	-Have links pointing to everything (not exactly sure what Lance wants
> here)
>>>
>>> The idea of s and u added to the tarballs name was approved.  Does everyone
>>> that is a developer have the permissions and ability to branch and merge
> code
>>> in the subversion repository?
>>>
>>> The issuses in Bugzilla put in by Lance need to be resolved quickly.  The
> only
>>> one that may take some time is investigating how to obtain diverse.org
>>>
>>> Let me know if I missed anything or misreported something.
>>>
>>> Sincerely,
>>>
>>> Andrew A. Ray
>>>
>

RE: [diverse-devel] Results of the Tuesday meeting

[Andrew A. R. <an...@vt...>]

Hi all,
>
> Hi all,
>
> 1.
>
> Andrew is saying something that is misleading: I'd be willing to bet
> that I could make doxygen source files that could generate the current
> diverse.fs.net pages as they are when your browser views them.  Unless I'm
> missing something, PHP does not generate anything on the current pages
> that could not be in an auto-pre-generated static page.

I agree with Dans reply on this message.  It may be possible, but the overall 
maintenance on it is probably much greater than what is currently there.

>>-Style (should we keep current style or goto a doxygen generated website)
>
> Doxygen does not impose much on style.  To list this as -Style is a little
> misleading.  Doxygen lets you use any stylesheet you like.  But it does
> restrict a lot of the structure of the auto-generated things, which would
> not exist otherwise.
>
> Adding:  I think you could do some, in a sense, "client-side include"
> using small pieces of javascript.  That is if you don't like all the
> repeated file content in the html docs from doxygen. But that may be bad
> because it hoses browsers like lynx. What else can do dynamic client side
> html content?  I don't know off hand.

I see a big difference between web pages and documentation.  I think we do 
need to keep all documentation up to date via doxygen.  By using doxygen we 
can keep up the documentation auto generated and up to date.  This should take 
care of the website issues that we have.

>
> Not necessarily quickly, but I'm hoping that they don't disappear without
> explanation.  
Understood, this is a problem.  It seems that it is fixed though.

> I'm currently optimistic, but testy about opentech taking the lead here.

This is going to be controversial, but I think we need to have this 
discussion.  Who do you want to take the lead on this then?  We are all trying 
to help DIVERSE.  As far as I know OTI isn't trying to brand DIVERSE as their 
product.  From my point of view OTI has tried to make DIVERSE more 
professional and has gotten grief for just about everything they've done with 
no thanks for what they have done.

I know everything that hasn't been done is perfect and there are issues, such 
as the website isn't that up to date.  However, no one seems to look at the 
positive fact that it is a professional website.  Also, the services for 
repository management and web site management were meant to make peoples lives 
easier.  The biggest issue in all of this is that there is a .com in the 
address.  Other than that there isn't an issue from what I've seen.

I think if we get a diversevr.org address and have it hosted on the OTI 
servers it will allow OTI to provide state of the art solutions to help keep 
DIVERSE alive and still give it a completely open source feel.

Just so you all know.  OTI does not have the resources to do much work on 
DIVERSE outside of what they get paid to do.  Some individuals in the company 
such as myself put time into doing DIVERSE work outside of what we get paid 
for.  We are all working to improve DIVERSE, let us start working together 
effectively.

Sincerely,

Andrew A. Ray
>===== Original Message From Lance Arsenault <lan...@ph...> =====
>Hi all,
>
>1.
>
>Andrew is saying something that is misleading: I'd be willing to bet
>that I could make doxygen source files that could generate the current
>diverse.fs.net pages as they are when your browser views them.  Unless I'm
>missing something, PHP does not generate anything on the current pages
>that could not be in an auto-pre-generated static page.
>
>Any bet takers?  I'm up for it.
>
>
>>-Style (should we keep current style or goto a doxygen generated website)
>
>Doxygen does not impose much on style.  To list this as -Style is a little
>misleading.  Doxygen lets you use any stylesheet you like.  But it does
>restrict a lot of the structure of the auto-generated things, which would
>not exist otherwise.
>
>Adding:  I think you could do some, in a sense, "client-side include"
>using small pieces of javascript.  That is if you don't like all the
>repeated file content in the html docs from doxygen. But that may be bad
>because it hoses browsers like lynx. What else can do dynamic client side
>html content?  I don't know off hand.
>
>
>In general I think Doxygen is only half way there, but I beats anything
>else I know of.
>
>
>2.
>
>> The issuses in Bugzilla put in by Lance need to be resolved quickly.
>> The only one that may take some time is investigating how to obtain
>> diverse.org
>
>Not necessarily quickly, but I'm hoping that they don't disappear without
>explanation.  I must admit some bug records can just be due to my
>misconceptions.  I got unhappy when I noticed that one of my bugs went
>away without a response, but that may be because I didn't have my bugzilla
>email preferences set verbose enough. I think I have it as verbose as
>possible now.   I'll be adding more.
>
>I'm currently optimistic, but testy about opentech taking the lead here.
>Before I was just pissed off, because of Dan's half baked responses (in my
>fatheaded opinion, of course) to my concerns.  I guess I love debate.
>
>
>cheers
>lance
>
>
>On Tue, 6 Sep 2005 an...@vt... wrote:
>
>> Hello everyone,
>>
>> Here are the results from the latest meeting.  John Kelso, Lance Arsenault,
>> Patrick Shinpaugh, Ron Kriz, Steve Satterfield (by conference phone), Denis
>> Gracanin, and Andrew A. Ray were present at the meeting.
>>
>> There is a big need to do something about the website.  Here are a list of 
a
>> few of the issues that were raised.
>> 	-Timely updates
>> 	-Updated information
>> 	-Style (should we keep current style or goto a doxygen generated website)
>> 	-Adding information to diverse.opentechinc.com to say it is just a testing
>> ground for the diverse.sourceforge.net website and not a second site that
>> seems similar but has no information about why it exists.  People didn't 
seem
>> to understand the idea behind having SVN and the web page on OT.
>> 	-How do people update the website manually?
>> 	-Readding the prime directives to the website
>> 	-Add history of NIST and perhaps weave the DTK history into the DIVERSE
>> history
>> 	-Have links pointing to everything (not exactly sure what Lance wants 
here)
>>
>> The idea of s and u added to the tarballs name was approved.  Does everyone
>> that is a developer have the permissions and ability to branch and merge 
code
>> in the subversion repository?
>>
>> The issuses in Bugzilla put in by Lance need to be resolved quickly.  The 
only
>> one that may take some time is investigating how to obtain diverse.org
>>
>> Let me know if I missed anything or misreported something.
>>
>> Sincerely,
>>
>> Andrew A. Ray
>>

Re: [diverse-devel] Results of the Tuesday meeting

[Lance A. <lan...@ph...>]

Hi all,

1.

Andrew is saying something that is misleading: I'd be willing to bet 
that I could make doxygen source files that could generate the current 
diverse.fs.net pages as they are when your browser views them.  Unless I'm 
missing something, PHP does not generate anything on the current pages 
that could not be in an auto-pre-generated static page.

Any bet takers?  I'm up for it.


>-Style (should we keep current style or goto a doxygen generated website)

Doxygen does not impose much on style.  To list this as -Style is a little 
misleading.  Doxygen lets you use any stylesheet you like.  But it does 
restrict a lot of the structure of the auto-generated things, which would 
not exist otherwise.

Adding:  I think you could do some, in a sense, "client-side include" 
using small pieces of javascript.  That is if you don't like all the 
repeated file content in the html docs from doxygen. But that may be bad 
because it hoses browsers like lynx. What else can do dynamic client side 
html content?  I don't know off hand.


In general I think Doxygen is only half way there, but I beats anything 
else I know of.


2.

> The issuses in Bugzilla put in by Lance need to be resolved quickly. 
> The only one that may take some time is investigating how to obtain 
> diverse.org

Not necessarily quickly, but I'm hoping that they don't disappear without 
explanation.  I must admit some bug records can just be due to my 
misconceptions.  I got unhappy when I noticed that one of my bugs went 
away without a response, but that may be because I didn't have my bugzilla 
email preferences set verbose enough. I think I have it as verbose as 
possible now.   I'll be adding more.

I'm currently optimistic, but testy about opentech taking the lead here. 
Before I was just pissed off, because of Dan's half baked responses (in my 
fatheaded opinion, of course) to my concerns.  I guess I love debate.


cheers
lance


On Tue, 6 Sep 2005 an...@vt... wrote:

> Hello everyone,
>
> Here are the results from the latest meeting.  John Kelso, Lance Arsenault,
> Patrick Shinpaugh, Ron Kriz, Steve Satterfield (by conference phone), Denis
> Gracanin, and Andrew A. Ray were present at the meeting.
>
> There is a big need to do something about the website.  Here are a list of a
> few of the issues that were raised.
> 	-Timely updates
> 	-Updated information
> 	-Style (should we keep current style or goto a doxygen generated website)
> 	-Adding information to diverse.opentechinc.com to say it is just a testing
> ground for the diverse.sourceforge.net website and not a second site that
> seems similar but has no information about why it exists.  People didn't seem
> to understand the idea behind having SVN and the web page on OT.
> 	-How do people update the website manually?
> 	-Readding the prime directives to the website
> 	-Add history of NIST and perhaps weave the DTK history into the DIVERSE
> history
> 	-Have links pointing to everything (not exactly sure what Lance wants here)
>
> The idea of s and u added to the tarballs name was approved.  Does everyone
> that is a developer have the permissions and ability to branch and merge code
> in the subversion repository?
>
> The issuses in Bugzilla put in by Lance need to be resolved quickly.  The only
> one that may take some time is investigating how to obtain diverse.org
>
> Let me know if I missed anything or misreported something.
>
> Sincerely,
>
> Andrew A. Ray
>

[diverse-devel] DADS-1.2.2 released

[Patrick S. <psh...@vt...>]

Released dads-1.2.2 to fix bug with IRIX dtk-masterServer not
configuring environment properly during boot.

-- 
Patrick Shinpaugh
Virginia Tech
UVAG System Administrator/Programmer
540-231-2054

[diverse-devel] Results of the Tuesday meeting

[<an...@vt...>]

Hello everyone,

Here are the results from the latest meeting.  John Kelso, Lance Arsenault, 
Patrick Shinpaugh, Ron Kriz, Steve Satterfield (by conference phone), Denis 
Gracanin, and Andrew A. Ray were present at the meeting.

There is a big need to do something about the website.  Here are a list of a 
few of the issues that were raised.
	-Timely updates
	-Updated information
	-Style (should we keep current style or goto a doxygen generated website)
	-Adding information to diverse.opentechinc.com to say it is just a testing 
ground for the diverse.sourceforge.net website and not a second site that 
seems similar but has no information about why it exists.  People didn't seem 
to understand the idea behind having SVN and the web page on OT.
	-How do people update the website manually?
	-Readding the prime directives to the website
	-Add history of NIST and perhaps weave the DTK history into the DIVERSE 
history
	-Have links pointing to everything (not exactly sure what Lance wants here)
	
The idea of s and u added to the tarballs name was approved.  Does everyone 
that is a developer have the permissions and ability to branch and merge code 
in the subversion repository?

The issuses in Bugzilla put in by Lance need to be resolved quickly.  The only 
one that may take some time is investigating how to obtain diverse.org

Let me know if I missed anything or misreported something.

Sincerely,

Andrew A. Ray

[diverse-devel] Bugzilla integration with Subversion

[Daniel L. <dla...@op...>]

All,
     Open Tech has integrated subversion with bugzilla such that when  
you commit a change via subversion your log entry will automatically  
be posted as a comment to the proper bug along with the list of files  
you changed to fix that bug.

     To use this feature simply use the following line in your svn  
commit comment:

"bug BUG_NUMBER:  You comment goes here"

     We can configure the system to require that you specify a bug  
number if you all think it is a good idea.  In this way every feature  
enhancement is documented as a "bug" and commits/changes are made  
against that bug.  What do you all think?  For now it is optional to  
specify a bug.

     To see an example of a comment posted this way see:

http://bugzilla.opentechinc.com:8888/show_bug.cgi?id=12

     The last comment was entered when I made a change within  
subversion.

      Lastly, if you have not signed up to diverse- 
de...@li... you should.

Dan

[diverse-devel] Re: [diverse] Results from the Tuesday meeting

[Daniel L. <dla...@op...>]

I did remove the links (they are now just generic descriptions of the  
components).  I also had the DTK Documentation link directed at  
diversetoolkit.sf.net; however, because I didn't have a ton of time  
to check the rest of the site for old content.

I believe that I have removed all traces of "modly" DTK documentation  
from the site and have linked it instead to diversetoolkit.sf.net.

If there is anything still wrong with the site please let me know in  
detail and report a bug on bugzilla.opentechinc.com so that we can  
track its progress toward completion.

Dan


On Sep 2, 2005, at 9:29 PM, Lance Arsenault wrote:

>
> Dan,
>
>
>> As per the DIVERSE meeting's outcome I have removed the direct  
>> links to the downloads.
>>
>
> What changed?  I don't see it.
>
>
>
>> being an "external" link to diversetoolkit.sf.net which is not  
>> maintained by the community.
>>
>
> What community!
>
> Three years ago it was my intent when John and I (mostly I) setup  
> diverse on sourceforge to have every diverse package be a different  
> sourceforge project, because sourceforge does not give adequate  
> control over the projects when they are all in one sourceforge  
> project.  DPF was supposed to be a separate sourceforge project  
> (like dpf.sf.net), and so was DGL. The diverse.sf.net was to be the  
> central hub/master project of all diverse projects.  As you can see  
> after I left 3 years ago this idea never caught on.  I never got  
> anybody to use the sourceforge repositories either.  It looks like  
> you are making that happen now with subversion.
>
> I guess DTK become external when it was replaced in DIVERSE 3.  At  
> that point I had no choose, but to make it all the more external.   
> From what I read it was being replaced.  For quite some time I had  
> no idea that DTK was being used by DIVERSE, other than John's DPF.
>
> There are requirements that must be satisfied in order to get  
> access to diversetoolkit.sf.net.  Like with any project.  And trust  
> is needed too. Pat has access, and John has been offered access,  
> but turned it down. Andrew was not interested in satisfying the  
> requirements that I imposed. Of course Andrew just thinks I'm being  
> a shit. That is all the parties that I know that have interest in  
> developing DTK.
>
> I'm the keeper of DTK because it just makes sense.  I built it, I  
> keep it. All good open source projects work this way.  The Linux  
> kernel for example.  You can decide that it's yours and then you  
> have forked. Which in the case of DTK isn't that much work,  
> compared to say apache.  Do a good job and I'll have the  
> diversetoolkit.sf.net web pages link to yours. Oh, how about that,  
> it does already.  Wouldn't it be nice if other people were that  
> courteous.
>
>
>
>> If you have problems with the website please offer to help by  
>> fixing it
>> yourself instead of complaining to Open Tech.
>>
>
> Okay now this email is sent to div...@li...,  
> not
> Open Tech.
>
> Who am I to fix the communities web pages, I had them fixed 3 years  
> ago and some one else came along and fixed them after me and put  
> them in a form that I don't like for many reasons.  What your  
> suggesting is crazy. If I fix them that would really piss off  
> people, even more than this email.
>
>
> I gather from your reply email (below) that you don't wish to  
> comply with my demands.  Your way of side stepping my demands  
> doesn't work this time.
>
> I'm done.
>
>
> cheers
> lance
>
>
> On Fri, 2 Sep 2005, Daniel Larimer wrote:
>
>
>> Lance,
>>
>> As per the DIVERSE meeting's outcome I have removed the direct  
>> links to the downloads.
>> I have redirected the DTK Documentation link to point to  
>> diversetoolkit.sf.net so Lance can keep it up to date.
>>
>> I would really prefer to give Lance (and anyone else who wants it)  
>> svn access to the site.  Then Lance or others can update the  
>> documentation in a manner that looks good within the style sheet  
>> of the rest of the page instead of being an "external" link to  
>> diversetoolkit.sf.net which is not maintained by the community.
>>
>> If you have problems with the website please offer to help by  
>> fixing it yourself instead of complaining to Open Tech.  We are  
>> more than willing to comply with requests.
>>
>> I am sorry that we were not able to remove the "moldy"  
>> documentation before now.  This is the first I have heard of the  
>> request.  In the future send all requests to  
>> di...@op... or div...@li...  
>> that way they are well documented and everyone who could answer  
>> the request has an opportunity to do so.  Better yet, file a bug  
>> report and CC the relevant people.  In the future we may want to  
>> have all change requests go through bugzilla to have a more formal  
>> process.
>>
>> Dan
>>
>>
>>
>> On Sep 2, 2005, at 11:43 AM, Lance Arsenault wrote:
>>
>>
>>> Hi All,
>>> Before I put in any more work I'd like you guys put links to the  
>>> DTK home page on your pages and remove the dtk-2.4.13-r10.tar.gz  
>>> links on http://diverse.sourceforge.net/index.php?page=download  
>>> and http://diverse.opentechinc.com/index.php?page=download or  
>>> better yet setup the downloads on the sourceforge server farm, or  
>>> let me hear better ideas. Otherwise I'll stop working.  Also  
>>> please remove all the moldy DTK documentation on  
>>> diverse.sourceforge.net and diverse.opentechinc.com. I've been  
>>> asking you guys to do this for years, and now I'm not playing  
>>> nice guy anymore.  If you have a particular dtk tarball that is  
>>> not available on https://sourceforge.net/project/showfiles.php? 
>>> group_id=70210 let me or Pat know about it and we can add it.
>>> Please comply or lose my help.
>>> On Next DTK Release: I'd say the biggest hold-up is getting  
>>> dtkConditional to work on windows.  The biggest thing I'd be  
>>> shooting for is fairly complete windows self-installing binary  
>>> release, corresponding source releases, and web page updates.   
>>> DTK has most of it's web pages in the DTK source, including the  
>>> homepage.  I know it all needs some work.  I may be inclined to  
>>> do it if you guys comply with my demands, otherwise I've got  
>>> other stuff I can do.
>>> cheers
>>> lance
>>> On Fri, 2 Sep 2005, Daniel Larimer wrote:
>>>
>>>> Now that we have a versioning scheme what is the plan for the  
>>>> next release of DTK, DGL and DPF?
>>>> Dan
>>>> On Sep 1, 2005, at 10:32 PM, ar...@op... wrote:
>>>>
>>>>> Hi Lance,
>>>>> What I meant by my statement was that I am trying to make sure  
>>>>> that people
>>>>> realize that the SVN repository is for developers and may not  
>>>>> always work.
>>>>>  If people want something that "just works" then they should  
>>>>> download the
>>>>> releases.
>>>>> I agree with your s and u arguments.  I don't think the s and u  
>>>>> should
>>>>> ever be allowed on the regular release tarballs though.  That  
>>>>> is just to
>>>>> much complexity for the end user.
>>>>> Sincerely,
>>>>> Andrew A. Ray
>>>>>
>>>>>> Hi all,
>>>>>> I was just reading a little closer:
>>>>>>
>>>>>>> 4)  SVN on Open Tech's servers will be used for development  
>>>>>>> and will be
>>>>>>> considered the unstable codebase.  The stable codebase will  
>>>>>>> be the
>>>>>>> release tarballs that we make and test from SVN.  I.e. SVN is  
>>>>>>> for
>>>>>>> developers only, not for people who want stable and tested code.
>>>>>>>
>>>>>> I don't think this has to be the case, in general.  I get  
>>>>>> stuff from CVS
>>>>>> on sourceforge all the time.  Stuff like OpenSceneGraph, and  
>>>>>> doxygen. How
>>>>>> else can you comfirm that a bug is still there?
>>>>>> Release tarballs are just well defined snapshots of the  
>>>>>> repository. It's
>>>>>> got nothing to do with stabity!!!!!!  By well defined I mean for
>>>>>> example you have a method (could be a script) that can get a  
>>>>>> particular
>>>>>> tarball from the repository at any time after it was made.  So  
>>>>>> you need to
>>>>>> know the repository version numbers of all files in a release  
>>>>>> tarball. I
>>>>>> can't say that I've done that, but it sounds good.  I'll bet that
>>>>>> subversion has this built in.  It's too obvious.  I'll look  
>>>>>> into it.
>>>>>> http://en.wikipedia.org/wiki/Codebase
>>>>>> "Codebase" is a term used in software development to refer to  
>>>>>> the whole
>>>>>> collection of all source code used to build a particular  
>>>>>> application or
>>>>>> component.
>>>>>> This is one thing that I could not following in the meeting,  
>>>>>> but I didn't
>>>>>> want to hold up things.
>>>>>> cheers
>>>>>> lance
>>>>>> On Thu, 1 Sep 2005 ar...@op... wrote:
>>>>>>
>>>>>>> Hello everyone,
>>>>>>> Here are the results from the DIVERSE meeting on Tuesday.   
>>>>>>> Sorry for
>>>>>>> taking a while to send this out, but I've been busy.
>>>>>>> The meeting was attended by:
>>>>>>> Ron Kriz
>>>>>>> John Kelso
>>>>>>> Lance Arsenault
>>>>>>> Patrick Shinpaugh
>>>>>>> Andrew A. Ray
>>>>>>> This is a majority of the people on this list, and represents  
>>>>>>> every
>>>>>>> organization involved on the list.
>>>>>>> We had a productive meeting and several decisions were made.   
>>>>>>> One item
>>>>>>> still needs discussion.
>>>>>>> 1)  The mailing list needs to be moved to sourceforge.  There  
>>>>>>> is no
>>>>>>> advantage to using Open Tech's email list, and it could send  
>>>>>>> the wrong
>>>>>>> message to the community.  After discussion on this thread  
>>>>>>> has finished
>>>>>>> I'll send out a message to the diverse-devel list on  
>>>>>>> sourceforge letting
>>>>>>> everyone know we are going to start using it again.
>>>>>>> 2)  The download page needs to have a link straight to the  
>>>>>>> source forge
>>>>>>> downloads page.  No specific releases should be mentioned on  
>>>>>>> this page.
>>>>>>> The  only information on this page is a short description of  
>>>>>>> what
>>>>>>> DTK,DPF,DGL, DADS, etc... are.
>>>>>>> 3)  Versioning numbers will stay at the X.Y.Z convention for  
>>>>>>> all user
>>>>>>> downloads.  Internally we will use X.Y.Z-rA to separate  
>>>>>>> tarballs that
>>>>>>> are
>>>>>>> being tested for a potential release.
>>>>>>> 4)  SVN on Open Tech's servers will be used for development  
>>>>>>> and will be
>>>>>>> considered the unstable codebase.  The stable codebase will  
>>>>>>> be the
>>>>>>> release
>>>>>>> tarballs that we make and test from SVN.  I.e. SVN is for  
>>>>>>> developers
>>>>>>> only,
>>>>>>> not for people who want stable and tested code.
>>>>>>> 5)  All of the latest releases will work with each other.   
>>>>>>> I.e. the
>>>>>>> latest
>>>>>>> DADS must be tested and work against DTK,DPF, and DGL.  DGL  
>>>>>>> must be
>>>>>>> tested
>>>>>>> and working against DTK and its dependencies.
>>>>>>> 6)  Potential addition to the developer naming schema.  An sX  
>>>>>>> may be
>>>>>>> added
>>>>>>> to the developer tarballs.  For example dtk-2.4.13- 
>>>>>>> s1.tar.gz.  This
>>>>>>> would
>>>>>>> represent branch 1 of dtk-2.4.13.  -s0 would represent the  
>>>>>>> original
>>>>>>> stable
>>>>>>> branch.  This will allow for some flexibility on  
>>>>>>> experimentation of
>>>>>>> DIVERSE packages.
>>>>>>> What do you all think of adding a DIVERSE development tarball  
>>>>>>> section on
>>>>>>> sourceforge and using this for release test tarballs and the sX
>>>>>>> tarballs?
>>>>>>> Let me know if I forgot anything or if I reported anything  
>>>>>>> incorrectly.
>>>>>>> Have a good evening.
>>>>>>> Sincerely,
>>>>>>> Andrew A. Ray
>>>>>>> ---------------------------------------------------------------- 
>>>>>>> -----
>>>>>>> To unsubscribe, e-mail: div...@op...
>>>>>>> For additional commands, e-mail: div...@op...
>>>>>>>
>>>>>> ----------------------------------------------------------------- 
>>>>>> ----
>>>>>> To unsubscribe, e-mail: div...@op...
>>>>>> For additional commands, e-mail: div...@op...
>>>>>>
>>>>> ------------------------------------------------------------------ 
>>>>> ---
>>>>> To unsubscribe, e-mail: div...@op...
>>>>> For additional commands, e-mail: div...@op...
>>>>>
>>>> ------------------------------------------------------------------- 
>>>> --
>>>> To unsubscribe, e-mail: div...@op...
>>>> For additional commands, e-mail: div...@op...
>>>>
>>> -------------------------------------------------------------------- 
>>> -
>>> To unsubscribe, e-mail: div...@op...
>>> For additional commands, e-mail: div...@op...
>>>
>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: div...@op...
>> For additional commands, e-mail: div...@op...
>>
>>
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle  
> Practices
> Agile & Plan-Driven Development * Managing Projects & Teams *  
> Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/ 
> bsce5sf
> _______________________________________________
> diverse-devel mailing list
> div...@li...
> https://lists.sourceforge.net/lists/listinfo/diverse-devel
>

Re: [diverse-devel] Re: [diverse] Results from the Tuesday meeting

[Lance A. <lan...@ph...>]

Yes.  Just lost interest in working with Dan.

--lance


On Sat, 3 Sep 2005, John Kelso wrote:

> Great!  I'm glad you're still willing to help.
>
> -John
>
> On Sat, 3 Sep 2005, Lance Arsenault wrote:
>
>>
>> Hi John,
>>
>> I'll see ya Tueday, at 10am.
>>
>> cheers
>> lance
>>
>>
>> On Sat, 3 Sep 2005, John Kelso wrote:
>>
>>> Hi,
>>>
>>> It would be nice to get this straightened out.  It's dragged on long
>>> enough.  We made a good start on it last Tuesday.  I hope you'll be
>>> willing to give it another shot next Tuesday too.  I don't think that
>>> these problems are all that intractable.
>>>
>>> If someone from OpenTech who is involved in these issues could come to the
>>> meeting it might help too, so their viewpoint can be heard.  We meet every
>>> Tuesday at 10:00 in the CAVE conference room.
>>>
>>> Thanks,
>>>
>>> -John
>

Re: [diverse-devel] Re: [diverse] Results from the Tuesday meeting

[John K. <ke...@be...>]

Great!  I'm glad you're still willing to help.

-John

On Sat, 3 Sep 2005, Lance Arsenault wrote:

>
> Hi John,
>
> I'll see ya Tueday, at 10am.
>
> cheers
> lance
>
>
> On Sat, 3 Sep 2005, John Kelso wrote:
>
> > Hi,
> >
> > It would be nice to get this straightened out.  It's dragged on long
> > enough.  We made a good start on it last Tuesday.  I hope you'll be
> > willing to give it another shot next Tuesday too.  I don't think that
> > these problems are all that intractable.
> >
> > If someone from OpenTech who is involved in these issues could come to the
> > meeting it might help too, so their viewpoint can be heard.  We meet every
> > Tuesday at 10:00 in the CAVE conference room.
> >
> > Thanks,
> >
> > -John

Re: [diverse-devel] Re: [diverse] Results from the Tuesday meeting

[Lance A. <lan...@ph...>]

Hi John,

I'll see ya Tueday, at 10am.

cheers
lance


On Sat, 3 Sep 2005, John Kelso wrote:

> Hi,
>
> It would be nice to get this straightened out.  It's dragged on long
> enough.  We made a good start on it last Tuesday.  I hope you'll be
> willing to give it another shot next Tuesday too.  I don't think that
> these problems are all that intractable.
>
> If someone from OpenTech who is involved in these issues could come to the
> meeting it might help too, so their viewpoint can be heard.  We meet every
> Tuesday at 10:00 in the CAVE conference room.
>
> Thanks,
>
> -John
>
> On Fri, 2 Sep 2005, Lance Arsenault wrote:
>
>>
>> Dan,
>>
>>> As per the DIVERSE meeting's outcome I have removed the direct links to
>>> the downloads.
>>
>> What changed?  I don't see it.
>>
>>
>>> being an "external" link to diversetoolkit.sf.net which is not
>>> maintained by the community.
>>
>> What community!
>>
>> Three years ago it was my intent when John and I (mostly I) setup diverse
>> on sourceforge to have every diverse package be a different sourceforge
>> project, because sourceforge does not give adequate control over the
>> projects when they are all in one sourceforge project.  DPF was supposed
>> to be a separate sourceforge project (like dpf.sf.net), and so was DGL.
>> The diverse.sf.net was to be the central hub/master project of all diverse
>> projects.  As you can see after I left 3 years ago this idea never caught
>> on.  I never got anybody to use the sourceforge repositories either.  It
>> looks like you are making that happen now with subversion.
>>
>> I guess DTK become external when it was replaced in DIVERSE 3.  At that
>> point I had no choose, but to make it all the more external.  From what I
>> read it was being replaced.  For quite some time I had no idea that DTK
>> was being used by DIVERSE, other than John's DPF.
>>
>> There are requirements that must be satisfied in order to get access to
>> diversetoolkit.sf.net.  Like with any project.  And trust is needed too.
>> Pat has access, and John has been offered access, but turned it down.
>> Andrew was not interested in satisfying the requirements that I imposed.
>> Of course Andrew just thinks I'm being a shit. That is all the parties
>> that I know that have interest in developing DTK.
>>
>> I'm the keeper of DTK because it just makes sense.  I built it, I keep it.
>> All good open source projects work this way.  The Linux kernel for
>> example.  You can decide that it's yours and then you have forked. Which
>> in the case of DTK isn't that much work, compared to say apache.  Do a
>> good job and I'll have the diversetoolkit.sf.net web pages link to yours.
>> Oh, how about that, it does already.  Wouldn't it be nice if other people
>> were that courteous.
>>
>>
>>> If you have problems with the website please offer to help by fixing it
>>> yourself instead of complaining to Open Tech.
>>
>> Okay now this email is sent to div...@li..., not
>> Open Tech.
>>
>> Who am I to fix the communities web pages, I had them fixed 3 years ago
>> and some one else came along and fixed them after me and put them in a
>> form that I don't like for many reasons.  What your suggesting is crazy.
>> If I fix them that would really piss off people, even more than this
>> email.
>>
>>
>> I gather from your reply email (below) that you don't wish to comply with
>> my demands.  Your way of side stepping my demands doesn't work this time.
>>
>> I'm done.
>>
>>
>> cheers
>> lance
>>
>>
>> On Fri, 2 Sep 2005, Daniel Larimer wrote:
>>
>>> Lance,
>>>
>>> As per the DIVERSE meeting's outcome I have removed the direct links to the
>>> downloads.
>>> I have redirected the DTK Documentation link to point to
>>> diversetoolkit.sf.net so Lance can keep it up to date.
>>>
>>> I would really prefer to give Lance (and anyone else who wants it) svn access
>>> to the site.  Then Lance or others can update the documentation in a manner
>>> that looks good within the style sheet of the rest of the page instead of
>>> being an "external" link to diversetoolkit.sf.net which is not maintained by
>>> the community.
>>>
>>> If you have problems with the website please offer to help by fixing it
>>> yourself instead of complaining to Open Tech.  We are more than willing to
>>> comply with requests.
>>>
>>> I am sorry that we were not able to remove the "moldy" documentation before
>>> now.  This is the first I have heard of the request.  In the future send all
>>> requests to di...@op... or div...@li...
>>> that way they are well documented and everyone who could answer the request
>>> has an opportunity to do so.  Better yet, file a bug report and CC the
>>> relevant people.  In the future we may want to have all change requests go
>>> through bugzilla to have a more formal process.
>>>
>>> Dan
>>>
>>>
>>>
>>> On Sep 2, 2005, at 11:43 AM, Lance Arsenault wrote:
>>>
>>>>
>>>> Hi All,
>>>>
>>>> Before I put in any more work I'd like you guys put links to the DTK home
>>>> page on your pages and remove the dtk-2.4.13-r10.tar.gz links on
>>>> http://diverse.sourceforge.net/index.php?page=download and
>>>> http://diverse.opentechinc.com/index.php?page=download or better yet setup
>>>> the downloads on the sourceforge server farm, or let me hear better ideas.
>>>> Otherwise I'll stop working.  Also please remove all the moldy DTK
>>>> documentation on diverse.sourceforge.net and diverse.opentechinc.com. I've
>>>> been asking you guys to do this for years, and now I'm not playing nice guy
>>>> anymore.  If you have a particular dtk tarball that is not available on
>>>> https://sourceforge.net/project/showfiles.php?group_id=70210 let me or Pat
>>>> know about it and we can add it.
>>>>
>>>> Please comply or lose my help.
>>>>
>>>>
>>>> On Next DTK Release: I'd say the biggest hold-up is getting dtkConditional
>>>> to work on windows.  The biggest thing I'd be shooting for is fairly
>>>> complete windows self-installing binary release, corresponding source
>>>> releases, and web page updates.  DTK has most of it's web pages in the DTK
>>>> source, including the homepage.  I know it all needs some work.  I may be
>>>> inclined to do it if you guys comply with my demands, otherwise I've got
>>>> other stuff I can do.
>>>>
>>>>
>>>> cheers
>>>> lance
>>>>
>>>>
>>>>
>>>> On Fri, 2 Sep 2005, Daniel Larimer wrote:
>>>>
>>>>
>>>>> Now that we have a versioning scheme what is the plan for the next release
>>>>> of DTK, DGL and DPF?
>>>>>
>>>>> Dan
>>>>>
>>>>>
>>>>> On Sep 1, 2005, at 10:32 PM, ar...@op... wrote:
>>>>>
>>>>>
>>>>>> Hi Lance,
>>>>>> What I meant by my statement was that I am trying to make sure that
>>>>>> people
>>>>>> realize that the SVN repository is for developers and may not always
>>>>>> work.
>>>>>>  If people want something that "just works" then they should download the
>>>>>> releases.
>>>>>> I agree with your s and u arguments.  I don't think the s and u should
>>>>>> ever be allowed on the regular release tarballs though.  That is just to
>>>>>> much complexity for the end user.
>>>>>> Sincerely,
>>>>>> Andrew A. Ray
>>>>>>
>>>>>>> Hi all,
>>>>>>> I was just reading a little closer:
>>>>>>>
>>>>>>>> 4)  SVN on Open Tech's servers will be used for development and will be
>>>>>>>> considered the unstable codebase.  The stable codebase will be the
>>>>>>>> release tarballs that we make and test from SVN.  I.e. SVN is for
>>>>>>>> developers only, not for people who want stable and tested code.
>>>>>>>>
>>>>>>> I don't think this has to be the case, in general.  I get stuff from CVS
>>>>>>> on sourceforge all the time.  Stuff like OpenSceneGraph, and doxygen.
>>>>>>> How
>>>>>>> else can you comfirm that a bug is still there?
>>>>>>> Release tarballs are just well defined snapshots of the repository.
>>>>>>> It's
>>>>>>> got nothing to do with stabity!!!!!!  By well defined I mean for
>>>>>>> example you have a method (could be a script) that can get a particular
>>>>>>> tarball from the repository at any time after it was made.  So you need
>>>>>>> to
>>>>>>> know the repository version numbers of all files in a release tarball.
>>>>>>> I
>>>>>>> can't say that I've done that, but it sounds good.  I'll bet that
>>>>>>> subversion has this built in.  It's too obvious.  I'll look into it.
>>>>>>> http://en.wikipedia.org/wiki/Codebase
>>>>>>> "Codebase" is a term used in software development to refer to the whole
>>>>>>> collection of all source code used to build a particular application or
>>>>>>> component.
>>>>>>> This is one thing that I could not following in the meeting, but I
>>>>>>> didn't
>>>>>>> want to hold up things.
>>>>>>> cheers
>>>>>>> lance
>>>>>>> On Thu, 1 Sep 2005 ar...@op... wrote:
>>>>>>>
>>>>>>>> Hello everyone,
>>>>>>>> Here are the results from the DIVERSE meeting on Tuesday.  Sorry for
>>>>>>>> taking a while to send this out, but I've been busy.
>>>>>>>> The meeting was attended by:
>>>>>>>> Ron Kriz
>>>>>>>> John Kelso
>>>>>>>> Lance Arsenault
>>>>>>>> Patrick Shinpaugh
>>>>>>>> Andrew A. Ray
>>>>>>>> This is a majority of the people on this list, and represents every
>>>>>>>> organization involved on the list.
>>>>>>>> We had a productive meeting and several decisions were made.  One item
>>>>>>>> still needs discussion.
>>>>>>>> 1)  The mailing list needs to be moved to sourceforge.  There is no
>>>>>>>> advantage to using Open Tech's email list, and it could send the wrong
>>>>>>>> message to the community.  After discussion on this thread has finished
>>>>>>>> I'll send out a message to the diverse-devel list on sourceforge
>>>>>>>> letting
>>>>>>>> everyone know we are going to start using it again.
>>>>>>>> 2)  The download page needs to have a link straight to the source forge
>>>>>>>> downloads page.  No specific releases should be mentioned on this page.
>>>>>>>> The  only information on this page is a short description of what
>>>>>>>> DTK,DPF,DGL, DADS, etc... are.
>>>>>>>> 3)  Versioning numbers will stay at the X.Y.Z convention for all user
>>>>>>>> downloads.  Internally we will use X.Y.Z-rA to separate tarballs that
>>>>>>>> are
>>>>>>>> being tested for a potential release.
>>>>>>>> 4)  SVN on Open Tech's servers will be used for development and will be
>>>>>>>> considered the unstable codebase.  The stable codebase will be the
>>>>>>>> release
>>>>>>>> tarballs that we make and test from SVN.  I.e. SVN is for developers
>>>>>>>> only,
>>>>>>>> not for people who want stable and tested code.
>>>>>>>> 5)  All of the latest releases will work with each other.  I.e. the
>>>>>>>> latest
>>>>>>>> DADS must be tested and work against DTK,DPF, and DGL.  DGL must be
>>>>>>>> tested
>>>>>>>> and working against DTK and its dependencies.
>>>>>>>> 6)  Potential addition to the developer naming schema.  An sX may be
>>>>>>>> added
>>>>>>>> to the developer tarballs.  For example dtk-2.4.13-s1.tar.gz.  This
>>>>>>>> would
>>>>>>>> represent branch 1 of dtk-2.4.13.  -s0 would represent the original
>>>>>>>> stable
>>>>>>>> branch.  This will allow for some flexibility on experimentation of
>>>>>>>> DIVERSE packages.
>>>>>>>> What do you all think of adding a DIVERSE development tarball section
>>>>>>>> on
>>>>>>>> sourceforge and using this for release test tarballs and the sX
>>>>>>>> tarballs?
>>>>>>>> Let me know if I forgot anything or if I reported anything incorrectly.
>>>>>>>> Have a good evening.
>>>>>>>> Sincerely,
>>>>>>>> Andrew A. Ray
>>>>>>>> ---------------------------------------------------------------------
>>>>>>>> To unsubscribe, e-mail: div...@op...
>>>>>>>> For additional commands, e-mail: div...@op...
>>>>>>>>
>>>>>>> ---------------------------------------------------------------------
>>>>>>> To unsubscribe, e-mail: div...@op...
>>>>>>> For additional commands, e-mail: div...@op...
>>>>>>>
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: div...@op...
>>>>>> For additional commands, e-mail: div...@op...
>>>>>>
>>>>>
>>>>>
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: div...@op...
>>>>> For additional commands, e-mail: div...@op...
>>>>>
>>>>>
>>>>
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: div...@op...
>>>> For additional commands, e-mail: div...@op...
>>>>
>>>>
>>>
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: div...@op...
>>> For additional commands, e-mail: div...@op...
>>>
>>
>>
>> -------------------------------------------------------
>> SF.Net email is Sponsored by the Better Software Conference & EXPO
>> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
>> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
>> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
>> _______________________________________________
>> diverse-devel mailing list
>> div...@li...
>> https://lists.sourceforge.net/lists/listinfo/diverse-devel
>>
>

Re: [diverse-devel] Re: [diverse] Results from the Tuesday meeting

[John K. <ke...@be...>]

Hi,

It would be nice to get this straightened out.  It's dragged on long
enough.  We made a good start on it last Tuesday.  I hope you'll be
willing to give it another shot next Tuesday too.  I don't think that
these problems are all that intractable.

If someone from OpenTech who is involved in these issues could come to the
meeting it might help too, so their viewpoint can be heard.  We meet every
Tuesday at 10:00 in the CAVE conference room.

Thanks,

-John

On Fri, 2 Sep 2005, Lance Arsenault wrote:

>
> Dan,
>
> > As per the DIVERSE meeting's outcome I have removed the direct links to
> > the downloads.
>
> What changed?  I don't see it.
>
>
> > being an "external" link to diversetoolkit.sf.net which is not
> > maintained by the community.
>
> What community!
>
> Three years ago it was my intent when John and I (mostly I) setup diverse
> on sourceforge to have every diverse package be a different sourceforge
> project, because sourceforge does not give adequate control over the
> projects when they are all in one sourceforge project.  DPF was supposed
> to be a separate sourceforge project (like dpf.sf.net), and so was DGL.
> The diverse.sf.net was to be the central hub/master project of all diverse
> projects.  As you can see after I left 3 years ago this idea never caught
> on.  I never got anybody to use the sourceforge repositories either.  It
> looks like you are making that happen now with subversion.
>
> I guess DTK become external when it was replaced in DIVERSE 3.  At that
> point I had no choose, but to make it all the more external.  From what I
> read it was being replaced.  For quite some time I had no idea that DTK
> was being used by DIVERSE, other than John's DPF.
>
> There are requirements that must be satisfied in order to get access to
> diversetoolkit.sf.net.  Like with any project.  And trust is needed too.
> Pat has access, and John has been offered access, but turned it down.
> Andrew was not interested in satisfying the requirements that I imposed.
> Of course Andrew just thinks I'm being a shit. That is all the parties
> that I know that have interest in developing DTK.
>
> I'm the keeper of DTK because it just makes sense.  I built it, I keep it.
> All good open source projects work this way.  The Linux kernel for
> example.  You can decide that it's yours and then you have forked. Which
> in the case of DTK isn't that much work, compared to say apache.  Do a
> good job and I'll have the diversetoolkit.sf.net web pages link to yours.
> Oh, how about that, it does already.  Wouldn't it be nice if other people
> were that courteous.
>
>
> > If you have problems with the website please offer to help by fixing it
> > yourself instead of complaining to Open Tech.
>
> Okay now this email is sent to div...@li..., not
> Open Tech.
>
> Who am I to fix the communities web pages, I had them fixed 3 years ago
> and some one else came along and fixed them after me and put them in a
> form that I don't like for many reasons.  What your suggesting is crazy.
> If I fix them that would really piss off people, even more than this
> email.
>
>
> I gather from your reply email (below) that you don't wish to comply with
> my demands.  Your way of side stepping my demands doesn't work this time.
>
> I'm done.
>
>
> cheers
> lance
>
>
> On Fri, 2 Sep 2005, Daniel Larimer wrote:
>
> > Lance,
> >
> > As per the DIVERSE meeting's outcome I have removed the direct links to the
> > downloads.
> > I have redirected the DTK Documentation link to point to
> > diversetoolkit.sf.net so Lance can keep it up to date.
> >
> > I would really prefer to give Lance (and anyone else who wants it) svn access
> > to the site.  Then Lance or others can update the documentation in a manner
> > that looks good within the style sheet of the rest of the page instead of
> > being an "external" link to diversetoolkit.sf.net which is not maintained by
> > the community.
> >
> > If you have problems with the website please offer to help by fixing it
> > yourself instead of complaining to Open Tech.  We are more than willing to
> > comply with requests.
> >
> > I am sorry that we were not able to remove the "moldy" documentation before
> > now.  This is the first I have heard of the request.  In the future send all
> > requests to di...@op... or div...@li...
> > that way they are well documented and everyone who could answer the request
> > has an opportunity to do so.  Better yet, file a bug report and CC the
> > relevant people.  In the future we may want to have all change requests go
> > through bugzilla to have a more formal process.
> >
> > Dan
> >
> >
> >
> > On Sep 2, 2005, at 11:43 AM, Lance Arsenault wrote:
> >
> >>
> >> Hi All,
> >>
> >> Before I put in any more work I'd like you guys put links to the DTK home
> >> page on your pages and remove the dtk-2.4.13-r10.tar.gz links on
> >> http://diverse.sourceforge.net/index.php?page=download and
> >> http://diverse.opentechinc.com/index.php?page=download or better yet setup
> >> the downloads on the sourceforge server farm, or let me hear better ideas.
> >> Otherwise I'll stop working.  Also please remove all the moldy DTK
> >> documentation on diverse.sourceforge.net and diverse.opentechinc.com. I've
> >> been asking you guys to do this for years, and now I'm not playing nice guy
> >> anymore.  If you have a particular dtk tarball that is not available on
> >> https://sourceforge.net/project/showfiles.php?group_id=70210 let me or Pat
> >> know about it and we can add it.
> >>
> >> Please comply or lose my help.
> >>
> >>
> >> On Next DTK Release: I'd say the biggest hold-up is getting dtkConditional
> >> to work on windows.  The biggest thing I'd be shooting for is fairly
> >> complete windows self-installing binary release, corresponding source
> >> releases, and web page updates.  DTK has most of it's web pages in the DTK
> >> source, including the homepage.  I know it all needs some work.  I may be
> >> inclined to do it if you guys comply with my demands, otherwise I've got
> >> other stuff I can do.
> >>
> >>
> >> cheers
> >> lance
> >>
> >>
> >>
> >> On Fri, 2 Sep 2005, Daniel Larimer wrote:
> >>
> >>
> >>> Now that we have a versioning scheme what is the plan for the next release
> >>> of DTK, DGL and DPF?
> >>>
> >>> Dan
> >>>
> >>>
> >>> On Sep 1, 2005, at 10:32 PM, ar...@op... wrote:
> >>>
> >>>
> >>>> Hi Lance,
> >>>> What I meant by my statement was that I am trying to make sure that
> >>>> people
> >>>> realize that the SVN repository is for developers and may not always
> >>>> work.
> >>>>  If people want something that "just works" then they should download the
> >>>> releases.
> >>>> I agree with your s and u arguments.  I don't think the s and u should
> >>>> ever be allowed on the regular release tarballs though.  That is just to
> >>>> much complexity for the end user.
> >>>> Sincerely,
> >>>> Andrew A. Ray
> >>>>
> >>>>> Hi all,
> >>>>> I was just reading a little closer:
> >>>>>
> >>>>>> 4)  SVN on Open Tech's servers will be used for development and will be
> >>>>>> considered the unstable codebase.  The stable codebase will be the
> >>>>>> release tarballs that we make and test from SVN.  I.e. SVN is for
> >>>>>> developers only, not for people who want stable and tested code.
> >>>>>>
> >>>>> I don't think this has to be the case, in general.  I get stuff from CVS
> >>>>> on sourceforge all the time.  Stuff like OpenSceneGraph, and doxygen.
> >>>>> How
> >>>>> else can you comfirm that a bug is still there?
> >>>>> Release tarballs are just well defined snapshots of the repository.
> >>>>> It's
> >>>>> got nothing to do with stabity!!!!!!  By well defined I mean for
> >>>>> example you have a method (could be a script) that can get a particular
> >>>>> tarball from the repository at any time after it was made.  So you need
> >>>>> to
> >>>>> know the repository version numbers of all files in a release tarball.
> >>>>> I
> >>>>> can't say that I've done that, but it sounds good.  I'll bet that
> >>>>> subversion has this built in.  It's too obvious.  I'll look into it.
> >>>>> http://en.wikipedia.org/wiki/Codebase
> >>>>> "Codebase" is a term used in software development to refer to the whole
> >>>>> collection of all source code used to build a particular application or
> >>>>> component.
> >>>>> This is one thing that I could not following in the meeting, but I
> >>>>> didn't
> >>>>> want to hold up things.
> >>>>> cheers
> >>>>> lance
> >>>>> On Thu, 1 Sep 2005 ar...@op... wrote:
> >>>>>
> >>>>>> Hello everyone,
> >>>>>> Here are the results from the DIVERSE meeting on Tuesday.  Sorry for
> >>>>>> taking a while to send this out, but I've been busy.
> >>>>>> The meeting was attended by:
> >>>>>> Ron Kriz
> >>>>>> John Kelso
> >>>>>> Lance Arsenault
> >>>>>> Patrick Shinpaugh
> >>>>>> Andrew A. Ray
> >>>>>> This is a majority of the people on this list, and represents every
> >>>>>> organization involved on the list.
> >>>>>> We had a productive meeting and several decisions were made.  One item
> >>>>>> still needs discussion.
> >>>>>> 1)  The mailing list needs to be moved to sourceforge.  There is no
> >>>>>> advantage to using Open Tech's email list, and it could send the wrong
> >>>>>> message to the community.  After discussion on this thread has finished
> >>>>>> I'll send out a message to the diverse-devel list on sourceforge
> >>>>>> letting
> >>>>>> everyone know we are going to start using it again.
> >>>>>> 2)  The download page needs to have a link straight to the source forge
> >>>>>> downloads page.  No specific releases should be mentioned on this page.
> >>>>>> The  only information on this page is a short description of what
> >>>>>> DTK,DPF,DGL, DADS, etc... are.
> >>>>>> 3)  Versioning numbers will stay at the X.Y.Z convention for all user
> >>>>>> downloads.  Internally we will use X.Y.Z-rA to separate tarballs that
> >>>>>> are
> >>>>>> being tested for a potential release.
> >>>>>> 4)  SVN on Open Tech's servers will be used for development and will be
> >>>>>> considered the unstable codebase.  The stable codebase will be the
> >>>>>> release
> >>>>>> tarballs that we make and test from SVN.  I.e. SVN is for developers
> >>>>>> only,
> >>>>>> not for people who want stable and tested code.
> >>>>>> 5)  All of the latest releases will work with each other.  I.e. the
> >>>>>> latest
> >>>>>> DADS must be tested and work against DTK,DPF, and DGL.  DGL must be
> >>>>>> tested
> >>>>>> and working against DTK and its dependencies.
> >>>>>> 6)  Potential addition to the developer naming schema.  An sX may be
> >>>>>> added
> >>>>>> to the developer tarballs.  For example dtk-2.4.13-s1.tar.gz.  This
> >>>>>> would
> >>>>>> represent branch 1 of dtk-2.4.13.  -s0 would represent the original
> >>>>>> stable
> >>>>>> branch.  This will allow for some flexibility on experimentation of
> >>>>>> DIVERSE packages.
> >>>>>> What do you all think of adding a DIVERSE development tarball section
> >>>>>> on
> >>>>>> sourceforge and using this for release test tarballs and the sX
> >>>>>> tarballs?
> >>>>>> Let me know if I forgot anything or if I reported anything incorrectly.
> >>>>>> Have a good evening.
> >>>>>> Sincerely,
> >>>>>> Andrew A. Ray
> >>>>>> ---------------------------------------------------------------------
> >>>>>> To unsubscribe, e-mail: div...@op...
> >>>>>> For additional commands, e-mail: div...@op...
> >>>>>>
> >>>>> ---------------------------------------------------------------------
> >>>>> To unsubscribe, e-mail: div...@op...
> >>>>> For additional commands, e-mail: div...@op...
> >>>>>
> >>>> ---------------------------------------------------------------------
> >>>> To unsubscribe, e-mail: div...@op...
> >>>> For additional commands, e-mail: div...@op...
> >>>>
> >>>
> >>>
> >>> ---------------------------------------------------------------------
> >>> To unsubscribe, e-mail: div...@op...
> >>> For additional commands, e-mail: div...@op...
> >>>
> >>>
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: div...@op...
> >> For additional commands, e-mail: div...@op...
> >>
> >>
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: div...@op...
> > For additional commands, e-mail: div...@op...
> >
>
>
> -------------------------------------------------------
> SF.Net email is Sponsored by the Better Software Conference & EXPO
> September 19-22, 2005 * San Francisco, CA * Development Lifecycle Practices
> Agile & Plan-Driven Development * Managing Projects & Teams * Testing & QA
> Security * Process Improvement & Measurement * http://www.sqe.com/bsce5sf
> _______________________________________________
> diverse-devel mailing list
> div...@li...
> https://lists.sourceforge.net/lists/listinfo/diverse-devel
>

[diverse-devel] Re: [diverse] Results from the Tuesday meeting

[Lance A. <lan...@ph...>]

Dan,

> As per the DIVERSE meeting's outcome I have removed the direct links to 
> the downloads.

What changed?  I don't see it.


> being an "external" link to diversetoolkit.sf.net which is not 
> maintained by the community.

What community!

Three years ago it was my intent when John and I (mostly I) setup diverse 
on sourceforge to have every diverse package be a different sourceforge 
project, because sourceforge does not give adequate control over the 
projects when they are all in one sourceforge project.  DPF was supposed 
to be a separate sourceforge project (like dpf.sf.net), and so was DGL. 
The diverse.sf.net was to be the central hub/master project of all diverse 
projects.  As you can see after I left 3 years ago this idea never caught 
on.  I never got anybody to use the sourceforge repositories either.  It 
looks like you are making that happen now with subversion.

I guess DTK become external when it was replaced in DIVERSE 3.  At that 
point I had no choose, but to make it all the more external.  From what I 
read it was being replaced.  For quite some time I had no idea that DTK 
was being used by DIVERSE, other than John's DPF.

There are requirements that must be satisfied in order to get access to 
diversetoolkit.sf.net.  Like with any project.  And trust is needed too. 
Pat has access, and John has been offered access, but turned it down. 
Andrew was not interested in satisfying the requirements that I imposed. 
Of course Andrew just thinks I'm being a shit. That is all the parties 
that I know that have interest in developing DTK.

I'm the keeper of DTK because it just makes sense.  I built it, I keep it. 
All good open source projects work this way.  The Linux kernel for 
example.  You can decide that it's yours and then you have forked. Which 
in the case of DTK isn't that much work, compared to say apache.  Do a 
good job and I'll have the diversetoolkit.sf.net web pages link to yours. 
Oh, how about that, it does already.  Wouldn't it be nice if other people 
were that courteous.


> If you have problems with the website please offer to help by fixing it
> yourself instead of complaining to Open Tech.

Okay now this email is sent to div...@li..., not
Open Tech.

Who am I to fix the communities web pages, I had them fixed 3 years ago 
and some one else came along and fixed them after me and put them in a 
form that I don't like for many reasons.  What your suggesting is crazy. 
If I fix them that would really piss off people, even more than this 
email.


I gather from your reply email (below) that you don't wish to comply with 
my demands.  Your way of side stepping my demands doesn't work this time.

I'm done.


cheers
lance


On Fri, 2 Sep 2005, Daniel Larimer wrote:

> Lance,
>
> As per the DIVERSE meeting's outcome I have removed the direct links to the 
> downloads.
> I have redirected the DTK Documentation link to point to 
> diversetoolkit.sf.net so Lance can keep it up to date.
>
> I would really prefer to give Lance (and anyone else who wants it) svn access 
> to the site.  Then Lance or others can update the documentation in a manner 
> that looks good within the style sheet of the rest of the page instead of 
> being an "external" link to diversetoolkit.sf.net which is not maintained by 
> the community.
>
> If you have problems with the website please offer to help by fixing it 
> yourself instead of complaining to Open Tech.  We are more than willing to 
> comply with requests.
>
> I am sorry that we were not able to remove the "moldy" documentation before 
> now.  This is the first I have heard of the request.  In the future send all 
> requests to di...@op... or div...@li... 
> that way they are well documented and everyone who could answer the request 
> has an opportunity to do so.  Better yet, file a bug report and CC the 
> relevant people.  In the future we may want to have all change requests go 
> through bugzilla to have a more formal process.
>
> Dan
>
>
>
> On Sep 2, 2005, at 11:43 AM, Lance Arsenault wrote:
>
>> 
>> Hi All,
>> 
>> Before I put in any more work I'd like you guys put links to the DTK home 
>> page on your pages and remove the dtk-2.4.13-r10.tar.gz links on 
>> http://diverse.sourceforge.net/index.php?page=download and 
>> http://diverse.opentechinc.com/index.php?page=download or better yet setup 
>> the downloads on the sourceforge server farm, or let me hear better ideas. 
>> Otherwise I'll stop working.  Also please remove all the moldy DTK 
>> documentation on diverse.sourceforge.net and diverse.opentechinc.com. I've 
>> been asking you guys to do this for years, and now I'm not playing nice guy 
>> anymore.  If you have a particular dtk tarball that is not available on 
>> https://sourceforge.net/project/showfiles.php?group_id=70210 let me or Pat 
>> know about it and we can add it.
>> 
>> Please comply or lose my help.
>> 
>> 
>> On Next DTK Release: I'd say the biggest hold-up is getting dtkConditional 
>> to work on windows.  The biggest thing I'd be shooting for is fairly 
>> complete windows self-installing binary release, corresponding source 
>> releases, and web page updates.  DTK has most of it's web pages in the DTK 
>> source, including the homepage.  I know it all needs some work.  I may be 
>> inclined to do it if you guys comply with my demands, otherwise I've got 
>> other stuff I can do.
>> 
>> 
>> cheers
>> lance
>> 
>> 
>> 
>> On Fri, 2 Sep 2005, Daniel Larimer wrote:
>> 
>> 
>>> Now that we have a versioning scheme what is the plan for the next release 
>>> of DTK, DGL and DPF?
>>> 
>>> Dan
>>> 
>>> 
>>> On Sep 1, 2005, at 10:32 PM, ar...@op... wrote:
>>> 
>>> 
>>>> Hi Lance,
>>>> What I meant by my statement was that I am trying to make sure that 
>>>> people
>>>> realize that the SVN repository is for developers and may not always 
>>>> work.
>>>>  If people want something that "just works" then they should download the
>>>> releases.
>>>> I agree with your s and u arguments.  I don't think the s and u should
>>>> ever be allowed on the regular release tarballs though.  That is just to
>>>> much complexity for the end user.
>>>> Sincerely,
>>>> Andrew A. Ray
>>>> 
>>>>> Hi all,
>>>>> I was just reading a little closer:
>>>>> 
>>>>>> 4)  SVN on Open Tech's servers will be used for development and will be
>>>>>> considered the unstable codebase.  The stable codebase will be the
>>>>>> release tarballs that we make and test from SVN.  I.e. SVN is for
>>>>>> developers only, not for people who want stable and tested code.
>>>>>> 
>>>>> I don't think this has to be the case, in general.  I get stuff from CVS
>>>>> on sourceforge all the time.  Stuff like OpenSceneGraph, and doxygen. 
>>>>> How
>>>>> else can you comfirm that a bug is still there?
>>>>> Release tarballs are just well defined snapshots of the repository. 
>>>>> It's
>>>>> got nothing to do with stabity!!!!!!  By well defined I mean for
>>>>> example you have a method (could be a script) that can get a particular
>>>>> tarball from the repository at any time after it was made.  So you need 
>>>>> to
>>>>> know the repository version numbers of all files in a release tarball. 
>>>>> I
>>>>> can't say that I've done that, but it sounds good.  I'll bet that
>>>>> subversion has this built in.  It's too obvious.  I'll look into it.
>>>>> http://en.wikipedia.org/wiki/Codebase
>>>>> "Codebase" is a term used in software development to refer to the whole
>>>>> collection of all source code used to build a particular application or
>>>>> component.
>>>>> This is one thing that I could not following in the meeting, but I 
>>>>> didn't
>>>>> want to hold up things.
>>>>> cheers
>>>>> lance
>>>>> On Thu, 1 Sep 2005 ar...@op... wrote:
>>>>> 
>>>>>> Hello everyone,
>>>>>> Here are the results from the DIVERSE meeting on Tuesday.  Sorry for
>>>>>> taking a while to send this out, but I've been busy.
>>>>>> The meeting was attended by:
>>>>>> Ron Kriz
>>>>>> John Kelso
>>>>>> Lance Arsenault
>>>>>> Patrick Shinpaugh
>>>>>> Andrew A. Ray
>>>>>> This is a majority of the people on this list, and represents every
>>>>>> organization involved on the list.
>>>>>> We had a productive meeting and several decisions were made.  One item
>>>>>> still needs discussion.
>>>>>> 1)  The mailing list needs to be moved to sourceforge.  There is no
>>>>>> advantage to using Open Tech's email list, and it could send the wrong
>>>>>> message to the community.  After discussion on this thread has finished
>>>>>> I'll send out a message to the diverse-devel list on sourceforge 
>>>>>> letting
>>>>>> everyone know we are going to start using it again.
>>>>>> 2)  The download page needs to have a link straight to the source forge
>>>>>> downloads page.  No specific releases should be mentioned on this page.
>>>>>> The  only information on this page is a short description of what
>>>>>> DTK,DPF,DGL, DADS, etc... are.
>>>>>> 3)  Versioning numbers will stay at the X.Y.Z convention for all user
>>>>>> downloads.  Internally we will use X.Y.Z-rA to separate tarballs that
>>>>>> are
>>>>>> being tested for a potential release.
>>>>>> 4)  SVN on Open Tech's servers will be used for development and will be
>>>>>> considered the unstable codebase.  The stable codebase will be the
>>>>>> release
>>>>>> tarballs that we make and test from SVN.  I.e. SVN is for developers
>>>>>> only,
>>>>>> not for people who want stable and tested code.
>>>>>> 5)  All of the latest releases will work with each other.  I.e. the
>>>>>> latest
>>>>>> DADS must be tested and work against DTK,DPF, and DGL.  DGL must be
>>>>>> tested
>>>>>> and working against DTK and its dependencies.
>>>>>> 6)  Potential addition to the developer naming schema.  An sX may be
>>>>>> added
>>>>>> to the developer tarballs.  For example dtk-2.4.13-s1.tar.gz.  This
>>>>>> would
>>>>>> represent branch 1 of dtk-2.4.13.  -s0 would represent the original
>>>>>> stable
>>>>>> branch.  This will allow for some flexibility on experimentation of
>>>>>> DIVERSE packages.
>>>>>> What do you all think of adding a DIVERSE development tarball section 
>>>>>> on
>>>>>> sourceforge and using this for release test tarballs and the sX
>>>>>> tarballs?
>>>>>> Let me know if I forgot anything or if I reported anything incorrectly.
>>>>>> Have a good evening.
>>>>>> Sincerely,
>>>>>> Andrew A. Ray
>>>>>> ---------------------------------------------------------------------
>>>>>> To unsubscribe, e-mail: div...@op...
>>>>>> For additional commands, e-mail: div...@op...
>>>>>> 
>>>>> ---------------------------------------------------------------------
>>>>> To unsubscribe, e-mail: div...@op...
>>>>> For additional commands, e-mail: div...@op...
>>>>> 
>>>> ---------------------------------------------------------------------
>>>> To unsubscribe, e-mail: div...@op...
>>>> For additional commands, e-mail: div...@op...
>>>> 
>>> 
>>> 
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: div...@op...
>>> For additional commands, e-mail: div...@op...
>>> 
>>> 
>> 
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: div...@op...
>> For additional commands, e-mail: div...@op...
>> 
>> 
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: div...@op...
> For additional commands, e-mail: div...@op...
>

Re: [diverse-devel] Re: [diverse] version control, mail list questions

[John K. <ke...@be...>]

On Fri, 2 Sep 2005, Lance Arsenault wrote:

>
>
> > Here's another one- what version of subversion do you recommend?  I have
> > svn version 1.0.6 on my Linux laptop, which I suspect is fairly moldy.
> > But will it work for my needs?
>
> I've got svn, version 1.1.3 (r12730).  Using gentoo GNU/Linux.
>
> So I'd say you're old.
>
> Look at that it's got the repository version number in it.  So subversion
> uses subversion.
>
> --lance

Interesting.  Make probably uses make, and gcc probably uses gcc.  Down
the rabbit hole!

-John