* Attila Lendvai [2007-02-03 12:34+0100] writes:
- If you really, really can't abide by point 1 then you should create a proper fork. This means choosing a new name and creating a new project with its own mailing list. On your project website you should also try and justify the fork and the inevitable drain on developer resources.
first of all, we could have a long discussion about what exactly a fork is and how people think about it. i don't want to do that, so i just summarize my opinion that it's not a bad thing at all. slime is a tool we use every day, therefore it's natural that there can't be consensus about it - everyone will have needs that others will dislike. darcs (or git or your favourite distributed source control system) helps a great deal in managing branches, and in fact each checked out darcs repo instance is a branch. my suggestion to use darcs was driven exactly by this, btw.
then it slowly turned out that i don't agree with many unwritten rules about elisp/emacs coding. for example at the beginning i wasn't aware that the lack of use of defun* with keywords as opposed to all those many &optionals are not due to historycal reasons - which was my obvious guess. later these things caused many small confrontations that i wasn't at all aware of, until Helmut finally expressed his dislike of them in a quite short mail.
by now looking at his cleanup checkins on my changes i understood it and to be honest i'd be very disappointed if mails like that could change my opinion about technical things in which we don't agree. but there's nothing unusual in that, sometimes people don't agree. without that nothing would ever change in the world, while with that arguments are inevitable.
i honestly tought that the things i was changing (in that relatively short period i was committing to the cvs) are generally useful for everyone. i always missed slime-mode-map in the minibuffer, now it's even gone from the official. i also missed the dwim inspection or the 10-fold (or was it even more?) speedup of the fuzzy completion, just to mention a few.
My recollection of the events is this:
1. Attila sends some patches to mailing list and requests, almost with force, commit rights.
2. Marco commits some patches introducing some bugs along the way. One bug breaks the debugger.
3. On the mailing list, I point out that the patch contained XEmacs specific code. Attila insists that the code in question isn't XEmacs specific. I revert the patch.
4. Some other bug breaks fuzzy completion and Brain Downing, the original author of the fuzzy completion, doesn't seem to like the new features.
5. I give Attila commit rights, so that he can fix the bugs.
6. Attila fixes bugs and suggests Darcs. I say: let's try it. Some people raise concerns. Attila stops pushing Darcs because "he can't read documentation for other people". I request that Attila should remove the Darcs repo from Slime's webspace and Attila moves the repo to cl-wdim.
7. Attila commits lots of changes. Apparently he has nothing else to do than to improve Slime. At a superficial look at the changes I see some good ideas, some bugs, stuff that I don't like, and a lot of disgusting more-than-80-columns code.
8. I request that Attila should write ChangeLog entries and read the HACKING file.
9. Attila reads the HACKING file. He adds a code snippet -- without explanation, but which doesn't seem to do anything in Emacs -- to the HACKING file. He starts to write ChangeLog entries, but not on a per function basis as described in HACKING. He uses the commit messages of his Dars repo instead.
10. Attila commits more stuff. Among other things he changes functions labeled with "interface", completly rewrites the with-output-to-temp-buffer code, changes some functions to defun* while adding losts of new arguments, introduces set-keymap-parents. He changes the default completion function to fuzzy.
11. I think by myself: "This arrogant bloke is destroying all the beauty that Slime ever had. Can't he ask before he makes essential changes." Consider leaving the project. Write "Stupid XEmacs" message.
12. Attila, instead of fixing his changes, announces that he longer commits his stuff in a message with subject line "forked". He writes "those who concentrate on rigid rules [...] can always stick to the old repo."
13. I think: "Well, at least he got the message. His fork will not have much success anyway." Try to clean up the mess that he left behind while keeping the best ideas (not successfully for the repl history code, but at least the code is now a lot simpler).
14. To my surprise, Attila commits some patches from the mailing list to the "old repo". He sends some super-softly formulated messages to the list. I try to ignore him: no tolerance for forks.
15. I commit some changes which are incompatible with his fork. Attila sends the "cutting up slime.el" message. As usual, Gary King loves Attila's ideas. I make it clear that I will leave the project if Attila stays.
16. Attila replies that he is surprised and that he only had the best intentions for the community.
17. I affirm that I don't want to work with him. Attila doesn't reply. I assume he left the project.
to get back to "forking" (which is in fact only a darcs repo caching my (our) changes that we can easily share with my collegues), i suggest to forget about it completly. that thing was created to rise my own _efficiency_ [yeah, i'm selfish, sorry], and then i popped it up so that maybe people will like the idea and then it can be for eveyone's good [or not?], but it turned out that it's not the case. from my point of view and needs, creating a new project with a new name and a new mailing list is the worst idea, so let's just forget that darcs repo ever existed!
in my view slime is just a tool that i'm shaping the way it fits my hands the best and therefore it may not fit the hands of others that well. and i honestly think that it's normal and is part of the way our world works. if you read back my mails about moving to darcs, my most important reason was that using darcs people can very easily manage to keep some of their changes local, while the generally acceptable changes can be put in the official.
Slime may just be a tool, but forcing your ideas on other people might not be the best way to win friends.
Note that forking due to trivialities is highly unlikely to attract other developers.
which makes it obvious how different we think about "branches" or "forks" (or iow, distributed repo instances).
So I think Helmut's position is justified and not an overreaction (although an ultimatum is probably not the most effective course of action). My advice to Attila would be firstly to apologize, then either retract the fork or commit to it, the current situation cannot continue.
you can pretty much have an opinion about me and the way i was acting, but i humbly note that i don't really find it grounded when suggestions are given about projects by people not being contributors of it. (this may not be the case here, in which case i'm sorry and take it back)
Giving to much weight to the opinions of new contributors might be unreasonable too. Many people consider making suggestions a form of contribution.
but i already apolagized for any/all possible misunderstandings about my comment on Helmut's changes. but to be sure i re-phrase again that i don't have bad feelings behind this "fork", i didn't intend to make Helmut (or anybody else) mad with my changes in slime's cvs and i'm sorry if some of my comments were not formulated in the least confrontational way and if they left room for misunderstandings.
I still think I understood most of your messages the way you intended. And I say it again: I don't want to work with you.
but as i already expressed above, i won't apolagize for thinking different about some thechnical terms and that i have different needs from a tool than some of the others. this is just plain natural for me, even when i'm "on the other side" of the argument if there is such thing at all.
Good luck with this strategy.
i tought that my previous mail was the last one to this list, because i find it quite pointless to waste anyone's time with matters like this, and it seemed to me that the situation was clearly stated. but it seems like some things about the status of that other repo needed to be cleared up.
but what other repo are we talking about, anyway? :)
sorry for wasting your time,
I assume this was your last message on this list.
Helmut.