unofficial mirror of guile-devel@gnu.org 
 help / color / mirror / Atom feed
From: David Kastrup <dak@gnu.org>
To: guile-devel@gnu.org
Subject: Re: And another deprecation joke
Date: Thu, 08 Dec 2011 09:29:18 +0100	[thread overview]
Message-ID: <87pqfzo49t.fsf@fencepost.gnu.org> (raw)
In-Reply-To: 20111208022934.GC1767@shuttle.happyleptic.org

rixed@happyleptic.org writes:

> You seam to believe that there is on one hand the guile developers and
> on another one the guile users, facing each others on the ground of
> some kind of contract that's being somewhat abused by the developers.
> In reality, guile is a project belonging to the commons and such
> demarcation does not exist: we are all using guile as well as
> contributing to it (and you are doing some good contributions by
> reporting all these bugs), and we all stands responsible for its
> flaws.

Projects have guidelines and policies, and development works in
transactions.  Deprecating features without providing a documented
alternative is a half-transaction.  In a sane project, they get finished
or unrolled.

There obviously isn't sufficient awareness that leaving them lying
around in half-finished and broken state is a bad idea.

I am trying to make a point that sticks.  This is not a question about
who should be doing what.  If nothing gets done, that's the way the
cookie crumbles.  It is a free project after all.

But if things get done that do more damage than good by making it
impossible to work with Guile if you are not the one having done the
change, it would be better if nothing got done.

And the more changes get done that make it impossible to work with
Guile, the less people will be found that will work on any aspect of
Guile.

More resources are _destroyed_ than used in that manner.  And you
complain that I try making this a sore point with people.

> I'm also having some ups and downs trying to use guile in a
> "professional" project, having made some promise to my contractors to
> met some objectives; but as far as I remember guile community never
> promised me anything neither contractually nor informally. Users and
> providers are an artificial creation of our times, there is no such
> thing here.

For every change, there is one provider and multiple users.  If the
change is not intended to have the qualities where anybody but the
provider could use it, then it should stay out of the central
repository.  Otherwise, you get dozens of half-baked half-documented
implementations of the same functionality in your code base because
nobody can work with the undocumented half-baked implementation of
somebody else and just commits his own version.  The next one to come
around and look closely finds a heap of things he could almost but not
quite use, and after investing a week of work, throws up his hands in
disgust and chooses a different tool.

This is not a question of available manpower.  It is one of discipline
and policies.  I don't know the control structures of this project.  So
I make this a sore point with anybody bothering enough about it to be
reading the developer list.  That's the best I can do.  Making people
annoyed, incredulous, possibly even ashamed about how they permit their
project get destroyed by sloppiness, because that sloppiness costs them
their user and in following their developer base.

If I wanted an incoherent junk yard of half-features, I would start with
Common Lisp instead of Scheme.

-- 
David Kastrup




  reply	other threads:[~2011-12-08  8:29 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-12-07 12:58 And another deprecation joke David Kastrup
2011-12-07 13:55 ` Noah Lavine
2011-12-07 17:24   ` David Kastrup
2011-12-07 15:01 ` Andy Wingo
2011-12-07 15:30   ` David Kastrup
2011-12-08  2:29     ` rixed
2011-12-08  8:29       ` David Kastrup [this message]
2011-12-08 20:18         ` Andy Wingo
2011-12-08 20:32           ` David Kastrup
2011-12-08 20:55             ` Andy Wingo
2011-12-09  1:58               ` David Kastrup
2011-12-09  2:38                 ` dsmich
2011-12-09  9:23                   ` David Kastrup
2011-12-09 18:23                     ` Andy Wingo

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87pqfzo49t.fsf@fencepost.gnu.org \
    --to=dak@gnu.org \
    --cc=guile-devel@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).