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

From: Daniel Skarda <0rfelyus@ucw.cz>
Cc: guile-devel@gnu.org
Subject: Re: Adding stuff to the core distro (was Re: Infix syntax)
Date: 17 Oct 2002 03:25:52 +0200	[thread overview]
Message-ID: <m0wuohdffj.fsf@hobitin.ucw.cz> (raw)
In-Reply-To: <m38z12o1mc.fsf@laruns.ossau.uklinux.net>

Neil Jerram <neil@ossau.uklinux.net> writes:
>     Daniel>  * Read "guile-debugger" thread on guile-devel. Even
>     Daniel>  developers have not known that there is guile-debugger
>     Daniel>  package.
> 
> In this case, though, the package is still new and possibly not ready
> for the core.

  In my opinion it should go to CVS - development HEAD or new branch. 
Inclusion would accelerate both acceptance and development of guile-
debugger (IMHO).

>   etc.  Note that, if this logic is correct, distribution package
>   users will always end up seeing lots of small packages, even if
>   coming from a single Guile distribution.

  Yes, I understand. There are going to be a lot of small packages
anyway. But I still do not see the reason why you also want to scatter and
slow down Guile _development_?

>   It might be fun to have a flexible build that allowed to build all
>   these pieces from a single distribution, but (i) would we just be
>   reinventing the wheel known normally as packages, and (ii) is it
>   worth it just for the ./configure && makers?

  Single distribution (or one big development pot) means for me as a
developer of Guile application many important things:

  * Everything in that distribution works together. Otherwise I have to
    figure out which versions work together. I have to know that
    guile-foo-x.y depends on guile-x.y, guile-bar-a.b depends on
    guile-foo-c.d and guile-e.f. Also I have to remember that guile-x.y does
    not have function scm_foo and I have to write many ifdefs. Also I should
    not forget that somewhere between 1.2 and 1.6 gh_scm2newstr changed
    behaviour ...

  * Everything is released together. Suppose that there is brand-new
    guile-20.0 and Guile-Foo. Latest stable release of Guile-Foo is for
    guile-18.6.1, there is a version of Guile-Foo for guile-20.0, but only
    in Guile-Foo CVS. 

    Now suppose my project depends on Guile and Guile-Foo. If I want to
    release new version with new features that rely on features found in
    Guile-20.0, I have to wait until Guile-Foo maintainer release new
    Guile-Foo. 

  * Everything that is "inside" will not accidentally orphanate. Older
    package gets more "deprecated" warnings than newer package. It would be
    pity to lost some package just because nobody renamed scm_foo to
    scm_c_foo ...  

  May be we should distinguish Guile (as in libguile or guile-core) and GUILE
as a development platform (all guile-foo packages together). Maybe what I am
calling for is not "one big Guile" (Guile == GUILE), but more organised GUILE
- some policy for GUILE development.

  My proposal:

    * release often, release regularly

    * release together. Think GNOME - there are many big packages, but they
      form together one development platform. You develop for GNOME (or
      GNOME2), not for libfoo-x.y, libbar-a.b,....

  Do you think that Guile != GUILE?

  Is GUILE necessary or is it just my crazy dream?

  What do you see as the most needed GUILE policy?

Thank you for your opinions,
0.

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