Re: And another deprecation joke

[David Kastrup]

address@hidden 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