Re: [Sbcl-devel] Draft of fix for incorrect derivation of (cons integer)

[73budden . <bud...@gm...>]

Thanks Christophe!

My fork is not so "straight".

One can take a look at bugs affecting me
https://bugs.launchpad.net/~budden73/+affectingbugs and see that of
those only one was fixed.

Some of those bugs are severe.

One was initially called "hang running thread.impure backtrace test",
but Stas renamed it to "Consing inside without-gcing on sb-safepoint"
which sound quite innocent simply because no one understands what does
it mean. AFAIR I encountered consequences of this bug when (room)
turned out to be not thread-safe for me. This bug is more than 2 years
old.

Bug currently being discussed was also distorted when reported by
Stas. Complete test case was posted to this mailing list twice, but
Stas replaced it with the code which shows no error. Also the name was
chosen to be unclear. To sum up, this bug report is not a proper bug
report at all: https://bugs.launchpad.net/sbcl/+bug/1732737

I'm sorry, but I can't believe this distortion was without a purpose.
I have no idea what was the actual reason of the distortion, but it
smells.

Hence I reported the bug again as https://bugs.launchpad.net/sbcl/+bug/1733622

Also Stas ignored that I'm not asking for help, but instead I'm giving
a help: I have a draft for the fix. Any review of the fix is welcome
but not necessary.

Observing SBCL development for some years, I noticed the following issues:
- no alpha-beta-release cycle. Good for development, bad for users.
- no stated goals and roadmap
- some "high priority" bugs hanging for 7 years, meanwhile some minor
improvements like "gc is now 5% faster" are released
- ignoring many initiatives from newcomers (e.g. recent wine patch
suggested, my patch for finding the source of encapsulation)
- serious bugs are hidden under names expressed in technical terms
which can be understood by experts only, their priority is lowered and
it looks like no one is going to fix them
- infriendly treatment of list visitors
- no commercial support

In this case one can conclude that it is unclear where SBCL goes, and
that the team is not willing to collaborate (it is quite unfair to put
this blame on me). So, if I want changes, the only reliable option is
"fork and do it yourself". Even then, I sorted my goals in such a way
that SBCL team can pull my code if it finds it suitable.

WBR, Budden



2017-11-21 14:55 GMT+03:00, Stas Boukarev <sta...@gm...>:
> Well, each new project needs a mailing list and a catchy name, which was my
> suggestion.
> Granted, that's not an all embracing welcome.
> But if someone goes straight to forking without submitting patches and
> getting them discussed or rejected, and declares divergent goals like
> disabling structure redefinition and only supporting linux, it's evident
> that there's no desire for collaboration. Which is fine, just that it
> should use its own resources as well. We're not using cmucl-imp@, after
> all.
>
> On Tue, Nov 21, 2017 at 1:44 PM Christophe Rhodes <cs...@ca...> wrote:
>
>> Stas Boukarev <sta...@gm...> writes:
>>
>> > And I can dismiss anything I please.
>>
>> You can of course dismiss anything you like in your own mind.  Please
>> don't make this mailing list an unwelcoming place for discussions about
>> different approaches, different takes, different features, different
>> viewpoints.
>>
>> A large part of SBCL's early development happened with extremely
>> friendly and supportive discussion with CMUCL's maintainers and users;
>> the SBCL project as it is owes them thanks, and I would be sad if a
>> similar spirit of openness weren't available to the next generation of
>> lisp developers.
>>
>> Christophe
>>
>