At 11:57 AM 12/21/2002 -0500, David A. Desrosiers wrote:
My view is that JPluck and PlkrData are inherently Plucker related. To me, PlkrData is really a part of Plucker in the same sense that the Python parser is, or that the Viewer is, in that it forms part of a useful suite of tools for configuring, Plucking, and then viewing Plucked data. And as pler. <g>Not to be the bringer of a "dark cloud", but doesn't SourceForge provide a forum/discussion/mailing list/bugs area for discussing issues related to JPluck and PlkrData?I've noticed that 90% or more of the recent discussions on the Plucker General List and (less on) Plucker Development List seem to be related to JPluck and PlkrData, both of which are third-party developed tools, and do not involve the Plucker viewer, or the Plucker Distiller portions of Plucker directly (and PlkrData only peripherally involves Plucker Desktop). I haven't seen anything related to Plucker itself within the context of these emails and discussions.
This makes sense to me. I would be quite happy to handle bugs on a PlkrData mailing list and will try to nudge people that direction for those issues.Since chasing bugs related to either of these applications has nothing at all to do with Plucker (the viewer/distiller) itself, I would like to try to recommend that these types of issues get moved over there.
This is almost precisely the opposite of what I understood your position to be two months ago, when I asked about the preferred language for some stuff. IIRC, you were/are working on a perl spider (I could be wrong, and apologize if I got the details incorrect)... which is obviously not the Python distiller. The prevailing view was that the functionality was Plucker, not the actual implementation.If you find something that actually affects the viewer, or the current Python distiller, or other Plucker-distributed tools, then I think those are, of course, welcome to be brought up and discussed here.
That would indicate to me that JPluck is every bit as much Plucker as Plucker Desktop or Python distiller is. (I can't make that case for PlkrData, because it's new added functionality intended to help less-technical users leverage Plucker in any form it happens to be taking, including Python distiller, any distiller-INI-compatible form, and JPluck.)
I'm willing to believe that I managed to misunderstand and to draw inappropriate conclusions and extrapolations, but I assure you it was in good faith.
I don't believe that for a moment. The Dev list has had less than six messages a day this month, and the General less than nine messages a day. That's not a whole lot to "weed through", especially when the headers have been accurate. About a quarter of the messages on the General list were JPluck or PlkrData related, most in the last four days. I think it will die way down again quickly, just as Desktop created a slew of new messages for a week or so after a major release and then died down. I'll endevor to move most PlkrData stuff off-list.The reason I am bringing this up (and I'm not the only one, I've had a couple of people email me directly and ask), is because some of us are now finding ourselves weeding through dozens upon dozens of emails related to third-party tools that use Plucker, trying to find the actual Plucker bugs and issues themselves.
Of course off-topic posts can clog the waves quite a bit. For example, somebody recently posted a press release about Sybase acquiring AvantGo to the Plucker-Dev list. <evil grin>
David, your take makes great sense in one context and is confusing in another context. You've been exceptionally attentive to detail on your contexts, so my assumption is that the former context is the correct one, that being that the project is defined exclusively by accepted developers who arbitrarily define it. That would exclude me, for example, because even though I have submitted both Python distiller (feature implementation and bug fixes) and Desktop C++ code that has been accepted into the tree, I have not been granted access to CVS.That's my take on it, anyone else?
The other context, and the one that I had assumed applied, is that the project is defined by stated parameters and what people do with it. In this case, your perl distiller, my PlkrData extension, Robert's Desktop and Laurens' JPluck, are all part of the project because the project leaders (including you) have expressed support for multiple implementations all along. If someone wants a new feature, they merely write it. Sure, it may not make it into the trunk, but it is still part of the "open source project" and can be posted as an available patch. When stuff diverges too far, there may be a schizm so that there can be another trunk supported by the people who wrote the features that were not put on the trunk.
It becomes confusing quickly. Most of my life is in the commercial world (obviously), where chains of control (and ownership) are very clear. In this case I think the problems may be a combination of:
1. Your expectations and ours weren't quite the same.
I figured PlkrData would add to Plucker and be considered a useful addition, eventually becoming part of the Plucker suite. I made it trivial to translate and update specificially because I assume that I won't be controlling it. So my expectation was it's more-or-less on trial before formally becoming part of the Plucker suite. I'm guessing your expectation is that new bits to be discussed on the board (at least in any volume) must first be approved by an internal board, but I'm not clear on that or if it's just the last three days' messages that have annoyed you.
2. Very different cultures at work.
There are regular clashes on email culture here too. The message last week from Ken Stuart on "Bad UI Design" demonstrated a culture-gap between commercial consumers and open source users. (And that was about Desktop, incidentially. Is that Plucker or not?) In this case, asking us to use the SourceForge boards for more of the detail is a good start at re-educating us and nudging us in the right direction. Don't be upset that it's needed; at least people got involved, which is a huge win in today's society.
I guess it's all in what "community" means and how far it extends. I'd like to get most of the PlkrData volume off the board (I expect it will die down real soon anyhow, since the project has nearly all the functionality I figure it should; just gotta build channel files and possibly jxl export. Once it stops moving, the messages will probably drop to one a month like with other features.), but I think announcements about new versions still belong on the list.
On that topic, I will admit to following other probably-bad examples. New features and builds were announced on the general and dev lists when I joined back in September (at which point Desktop took a large volume). Desktop and SlashPuck were both announced on General back in August, and Desktop was announced simultaneously on Dev. JPluck was announced the same way. I was guilty of doing what you suggested, of "stick around awhile, read the previous messages in the archives, follow the threads of discussion, and see where we've been, where we're going, and how each of us works together." The typical example, at least as apparent, was to announce new tools and features on the General and Dev lists. Given the presence of an Announce list, I've always wondered why, but I did precisely as you directed me to and followed example. Let's change it and set a new example, confining ALL announcements to the Announce list. Make sense?
-Tony McNamara-
_______________________________________________
plucker-list mailing list
[EMAIL PROTECTED]
http://lists.rubberchicken.org/mailman/listinfo/plucker-list
