DN632861955

Subject: Re: itcl in the core (WAS: Tcl/Tk 8.4a1 release) - DN [1]

dgp@clover.cam.nist.gov (Don Porter) - 09 Jun 2000 - comp.lang.tcl

 Jeffrey Hobbs  <jeff_hobbs@my-deja.com> wrote:
 > It may have been somewhat facetious, but that doesn't mean I'm
 > not always quite serious about the need for more community support
 > rather than community derision.

 Perhaps it's the asynchronous nature of Usenet, or perhaps it's the fact
 that we are monitoring different public forums, but I haven't seen a
 whole lot of what I would call "community derision".

 I've mostly seen people complaining that they feel unable to take part
 in core development because they don't have the access, influence, or
 feedback they need to do so effectively.  For this reason I echo Paul
 Duffin's plea that development of community organizing procedures and
 tools should be top priority right now.  Yet another nifty Tk widget can
 wait.  Byte compiling more Tcl commands can wait.  Whoever sets the
 priorities in core development, please get that message.  It is evident
 that there is more core development work to do than the tiny core team
 at Ajuba can possibly take on themselves.  You must harness community
 efforts, and to do that effectively you need a good set of community
 management tools.  You need this now, before ongoing frustration drives
 people away.

 Constructing these tools and procedures is not work you are doing for a
 lazy community either.  It is the construction of the tools which you,
 the Tcl Ambassador, need to successfully manage the effort of the Tcl
 community.  You're not doing this for us;  you're doing it for you (and
 us).

 That's not to say that the construction of community support needs to
 fall entirely on the shoulders of Ajuba staff.  I'm reminded of the
 effort to get the bug DB online.  For months, various readers of c.l.t.
 pleaded, "Just give us the contents in plain text.  We'll make the
 tools."  But we had to wait for Scriptics to do all the work in-house,
 and then unveil the half-capable system we have now.  I'm grateful that
 we have it, but it's no secret that it has serious shortcomings.  This
 time, I hope that more people will contribute, and will *feel welcome to
 contribute* to a community project, not a Scriptics/Ajuba project.

 As a contrast to Tcl, consider Pike.  It's another interpreted computer
 language.  One week ago, I'd never heard of Pike.  It had zero
 "mind-share" in my head, and I can't imagine it has a very large number
 of users.  However, it does have what appears to be an active community
 gathered at http://pike-community.org/.  I can only guess that the tools
 of that web site (and the Pike-powered web content management system,
 Roxen, which powers them) are what make the difference.  Similarly, the
 Python folks have Zope to manage their collaborations.

 Tcl has dev.scriptics.com, which is a good start, but still has a lot of
 unrealized potential.  How can the community join in the effort of
 realizing that potential?  Is the source code/data for dev.scriptics.com
 available?  Why not?  My understanding is that dev.scriptics.com is
 built on AOLServer and the ArsDigita Community System.  Both Roxen and
 Zope support content editing through the Web, which encourages community
 involvement.  Can ACS support that?  Does ACS provide other means
 through which the community of Tcl users can effectively contribute?  If
 so, open it up and let us do so.  If not, consider building one which
 can.  Tcl has tclhttpd.  Tcl has database extensions.  Tcl has XML.
 Assembling them into a web community server is a large task, but surely
 one within the reach of Tcl and its users.

 >> This is the first invitation I've seen from the core team to contribute
 >> the changes necessary to package [incr Tcl] with the Tcl distribution.

 > Why does the community always need an explicit invitation?

 Because Ajuba holds the keys to the Tcl CVS repository.  I need at least
 a hint that my contribution would be welcome before I'll expend the
 effort to make and submit it.

 From my perspective (more below), the issue of whether or not to bundle
 [incr Tcl] in Tcl 8.4 was still open.  Do you understand why I would be
 reluctant to construct a patch supporting that bundling, only to watch
 Ajuba decide they'd rather bundle Otcl instead?

 > ...It's a little hard to follow,
 > because the discussions jump between here and the itcl mailing
 > list, and in some cases private email.  No, I don't expect people
 > to know what's in my inbox, but that's also why I always encourage
 > people to use the available public channels.

 I'm not a user of [incr Tcl], so I am not subscribed to the itcl mailing
 list.  So, I missed out on that announcement.  In fact, after too many
 minutes searching through the itcl mailing list archives at

     http://dev.scriptics.com/lists/itcl/

 I still haven't found it.  Could an itcl subscriber point me to the
 right place, please?

 The issue of bundling [incr Tcl] with Tcl8.4 is of interest to
 [incr Tcl] users, so it should be discussed on that list.  However, it
 is also of interest to people following core development.  To my
 knowledge, there is no mailing list for Tcl core developers (why not!?),
 but the tclprojects list served in that role for a short time around
 the Tcl 8.3 release.  Could those of you posting on this topic in the
 itcl mailing list please CC: a copy of your messages to
 tclprojects@scriptics.com ?

 >> Ask and ye shall receive.

 > On your mark, get set, go.  We need a clean solution to including
 > cross-platform C-based packages in the core distribution.

 I'll see what I can do.  (And I hope many others are thinking the same
 thing!)  Any prior art or established constraints I can use to measure
 whether or not a solution qualifies as "clean" ?  How bound should one
 feel by the half-completed TEA specs in constructing a solution?

 [ List of great role models and advice on quality patches snipped. ]

 --
 | Don Porter          Mathematical and Computational Sciences Division |
 | donald.porter@nist.gov             Information Technology Laboratory |
 | http://math.nist.gov/~DPorter/                                  NIST |
 |______________________________________________________________________|