ri...@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
