Re: Adding stuff to the core distro (was Re: Infix syntax)

[Daniel Skarda <0rfelyus@ucw.cz>]

> On the other hand...  Rob has raised the question of whether we should
> be adding things to the core distro that don't strictly need to be
> there, so perhaps we should stop for a moment to consider our
> principles on this point.
> 
> I'm not sure what to suggest, myself.  Seems to me that one extreme is
> the Emacs approach - basically bundle everything.  The convenience of
> the opposite extreme depends on what kind of package repository system
> (aka GUMM) we can create.

  I vote for Emacs approach - bundle everything that is mature, documented and
stable. Before you reply that my message was driven by megalomania, I try to
explain my view:

  Scheme is very pretty language, but I think that these days "pretty language"
does not imply success. Also libraries that come with language are important as
well. So we should not see Guile as a single package but rather as a development
platform. The development platform that is not as popular as other (python,
perl) ...

  I my opinion, breaking guile into small (orthogonal) packages is nice from
"pure" developer's view, but it fails in "real world" and builds unnecessary
walls between Guile and Joe Average Programmer, who wants to evaluate Guile:

  "Install guile-x.y, guile-foo-y.z, guile-bar-a.b. Joe, do you want to use
  feature XYZ? than you have to checkout, compile, install guile-CVS, checkout
  guile-foo-CVS, because guile-foo-y.z does not work with guile-CVS... Also
  users of your program must do the same because there are no Debian/RedHat/...
  packages for development versions."
   
  Do you think that Mr Joe A. Programmer will choose Guile because Scheme is
superior language and "Official GNU blah blah blah"?

  I think programmers want to start coding, not to spend their time collecting/
maintaining/upgrading various tiny packages.

Also Guile development would be easier with "one big development pot":

 * Read "guile-debugger" thread on guile-devel. Even developers have not known
   that there is guile-debugger package. "One big pot" means less probability
   you miss some important package, because have not noticed its announcement 
   or reference deep inside the Guile documentation.

 * When somebody changes (read: improves :-) some interface, it is easier to
   spot and fix all places, where the change breaks actual code. Even thought a
   developer, who was responsible for some feature, retires, code from big pot
   will not become orphan (there is always somebody who fixes it).

 * It saves us a lot of time. cvs update -dP, autogen, configure, make, make
   install, cvs update, autoget, configure, make install, ....
  
 * "One big pot" also simplifies dependecies (see Joe's example). And there is
   no need for a lot of #ifdef GUILE_HAS_FOO_FEATURE, #ifdef GUILE_1_x_y,..
   which are hell to maintain.

  So these were my arguments I could think of. Please try to write down your
oppinions. I would also like to hear arguments from "the other side" (break
Guile into small and orthogonal packages), but I can not think of any benefit
that would come from scattered development (except specific "beauty"). IMHO it
is easier to write script, that extracts small subset from guile-core, than to
maintain zillions of small packages (think: guile-core, guile-infix,
guile-srfi-1, guile-srfi-*, guile-readline, guile-.....)

0.

ps: It would be also nice to "release Guile regularly, release Guile often".  
I would like to propose to release Guile development branch monthly (or every
fortnight). At least for some time, so we can find if this approach is an
advantage or not.

Also detailed development roadmap (timeline, schedule) would be very helpful.

ps: Another successful example of "big development pot" is Linux kernel 
(or XFree project).

ps: Example of tools/utils/code I would merge into Guile immediately or ASAP:
g-wrap, build-guile-gtk script or any other tool for making language bindings.
There are plenty of them and it is strange that there is no standard one. 

Also sgtk_flags2scm family of C utils would be helpful. (When I say "merge"
here, I do not mean to merge directly into libguile, but merge into guile-core
as libguiletools or something like that).

ps: Maybe "hybrid" approach would be the best way. Bundle everything possible,
but also provide an easy way for creating/distributing/maintaining Guile
packages (and a repository to archive them).


_______________________________________________
Guile-devel mailing list
Guile-devel@gnu.org
http://mail.gnu.org/mailman/listinfo/guile-devel