On 2009-03-13 23:17-0600 Geoffrey Furnish wrote: > Alan W. Irwin writes: > > From my observations of projects that use git (such as the Intel X driver > > stack which includes at least the kernel, drm, mesa, X server and the > > Intel X driver), (3) is a huge issue. > > [...] Carl Worth > > (a well-respected X developer who works for Intel and who is keen as > > mustard on git) is having big problems with this issue just trying to sort > > out what will go into their next release. If he is having trouble sorting > > out the git bits and pieces for the X intel stack, there is little hope > > for the rest of us mere mortals! > > [...]are you saying there are > several separate pieces of software, each with several developers, each > publishing their own publicly accessible git repos, so that end users are > bewildered with trying to figure out what to pull from where to assemble all > the pieces of a working system?
Yep. > [if so] I think it's a bit hyperbolic to apply it to PLplot. More than a bit as I hope I made clear (see the first sentence of what you quoted from me below). > [...] So the picemeil assemblage problem you describe with the Intel X driver > project seems like a distant worry for a git-based PLplot future, to me. Largely, agreed, see the next quoted sentence. >> That stack of software is obviously an extreme case of git development >> gone wild, and I doubt PLplot development will never be that wild. >> Nevertheless, it is a concern if PLplot moves to git because even now we >> have trouble getting users and developers to report back the exact version >> of PLplot they were using when they give bug reports, and it appears the >> possibility of additional git versions would just exacerbate that problem. > I think I agree, except for the extent of my worry about this. Every user > can report their origin, and the git commit identifier. I would suggest > that > unless their origin is our SF-hosted repo, they don't have a reasonable > expectation of getting much help from the PLplot core team. > If one of us were to publish our own PLplot git repo, and some user had > issues with sometehing they pulled from that, then it should be pretty clear > they need to contact that same developer for support. The PLplot team > should > be able to feel pretty relaxed about communicating to users that if they > want > help, they need to be asking about a branch that is available in the project > master repo, if they want support on list. > That doesn't seem at all unreasonable to me, nor would I expect it to be > off-putting or unexpected by the general user community. That seems okay in theory, but in the admittedly extreme case of X that is not working out at all well in practice. Basically git allows complete freedom of development which is all very nice, but my point is there are also some potential drawbacks to be concerned about such as fragmentation of the development and testing effort that turns off many of those (like me in the X situation) that like to help out with bug reports. > > > > 1) SCM systems, particularly centralized ones like cvs/svn, actually > > > discourage some developers from participation, due to the overhead of > > > synchronization. > > > > > > Just look at PLplot trunk activiity. Just during the period where I've > > > been trying to get re-engaged here over the last few weeks, I see two or > > > three roughly completely independent whirlwinds of activity, all > > > swirling around in the code base at the top of trunk. Everytime > > > somebody does something, the "commit" it to trunk. Everybody's got to > > > update, and this causes lots of rerunning cmake, rebuilding, etc. > > > > For a large project that might be an issue, but a rebuild of PLplot takes > > very little time at all (especially with CMake). Also, the various > > components of PLplot are really nicely separated with few side effects so > > you really have to work at it to mess up others who are working on some > > different component of PLplot on the svn trunk. > > [...]I have two different code bases in my professional life that link to > PLplot. > Both of them are locked into years-old versions of PLplot. About a year ago > I made the mistake of bumping one of them up to a modern PLplot release, and > then got flooded by users of my code reporting segfaults which took down the > whole application. > > The problems are mostly apparently something having to do with the Tk widget > (plframe). But the point is, it's been broken for many many releases, it > prevents me from updating to trunk on two professional projects until I find > and fix the bug(s). I agree with you this far; we did not have deep enough testing until the second to last release when I resurrected a fairly comprehensive interactive test script (you can now run this with "make test_interactive" in the installed examples tree). That test script turned up the segfaults for Tk plframe for the first time to my knowledge, but it would have been better if you had communicated knowledge of those segfaults much earlier to me or any of the other active developers. (I am not sure we could have done anything to fix the problem, but at least we could have warned users, turned Tk OFF by default, etc. until you found a fix.) > > I am committed to doing this (find and fix the Tk plframe bugs), as time > allows, and will propagate the fixes to > the PLplot repo (svn or perhaps a git repo if we can get there) when I have > them. Good. That is the best solution since you and Maurice are essentially the only developers of Tk plframe and thus you have the best chance by far of all the PLplot developers to fix it again. I won't answer the rest of your comments in detail because I think you already know from my previous comments where I stand. However, I will comment on your general observation which is that the current PLplot has rather active development. That observation pleased me a lot since I think that is a sign of a really healthy project. Alan __________________________ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __________________________ Linux-powered Science __________________________ ------------------------------------------------------------------------------ Apps built with the Adobe(R) Flex(R) framework and Flex Builder(TM) are powering Web 2.0 with engaging, cross-platform capabilities. Quickly and easily build your RIAs with Flex Builder, the Eclipse(TM)based development software that enables intelligent coding and step-through debugging. Download the free 60 day trial. http://p.sf.net/sfu/www-adobe-com _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
