"Attila Lendvai" attila.lendvai@gmail.com writes:

...

+2006-11-05 Helmut Eller heller@common-lisp.net

•   * slime.el (sldb-sexp-highlight-mode): Remove bloat.
  

iow, removing a feature i've recently added.

Please don't be upset.

We do appreciate your work on improving SLIME.

anyways, i'll set up a darcs repo at common-lisp.net/project/cl-wdim/darcs. feel free to pull whatever you would like to have in the official.

However, this is not how it works.

If you are interested in getting your improvements into SLIME, it would help to send patches that do *one* improvement at a time and to explain what they do.

For instance, your sldb-sexp-highlight-mode came in, without an explanation of the proposed feature, with a patch apparently related to fuzzy completion. This is not a good strategy: For instance, I have committed patches from the mailing list in the past, but I will not touch code that seems to be related to the fuzzy completion -- because I don't use that myself.

Cheers,

"Attila Lendvai" attila.lendvai@gmail.com writes:

belive me i would if managing it didn't take _more_ time then doing the features themselves. i gave up on using cvs a long time ago. of course it could be my lack of expertise, but dealing with separated patches with cvs especially without commit rights is a pita.

sorry for being upset, but cvs diff'ing, hand editing the patches, then keeping track of what changes i've sent and what changes are not meant to be sent at all, and then keeping it in sync with the ChangeLog is way too much effort compared to the effort i spend on actually improving slime.

I symphatize, but if _you_ have trouble separating the features, the imagine what the effort feels like to someone else...

Some options to ease things on your end (I have used all of these at one time or another with different projects):

* Keep a mirror of the CVS using a different VCS, eg. Darcs, and use that to separate the patches to independent changesets: check out the tree with the features you want, using the features of your own VCS system, and then just take a normal diff between that and the CVS tree. Quick and easy.

* Keep several local CVS trees, each with one change only, use them to generate patches which you then apply to a single tree (which you then use locally). Clear, but more time-consuming.

* (Variant of previous one): keep two local trees: "incoming" and "hacking". Incoming gets only small, easy to separate changes, which end up traveling upstream. Hacking is the "real" local tree.

* Use CVS vendor branches (I don't actually recommend this, it is far too easy to mess up, but it can be done).

...

For instance, your sldb-sexp-highlight-mode came in, without an explanation of the proposed feature, with a patch apparently related to fuzzy completion. This is not a good strategy: For instance, I

sorry for that. probably i got tired of going through the cvs diff result and deleting patch hunks by hand the nth time in a way that does not break the diff file.

Even for N-feature patches, and explanation of included features would help. From my POV: when I go "Ok, I'll see if there is something I can quickly deal with on slime-devel!", I pretty automatically skip big patches without clear enumeration & explanation of features.

I think most of the patches you have sent are still "ticked" in my GNUs, but I have not had the kind of chunks of time that they need so far. If there was a clear explanation of the a feature I could at least go "Oh, COOL!", and even if I didn't have the time right then, it would probably happen much sooner just so that I get to play with the feature myself...

I am not a very prolific Slime committer, though, and others may have different priorities -- so YMMV.

all in all, i would suggest moving to a better versioning system like darcs that handles all these issues in a very convenient way including the ChangeLog. but time tought me not to try reforming things that i'm not an original participant of and where i don't see the will without my efforts. i brought up moving to darcs, i asked for commit rights, etc without any answers while meanwhile in some occasions i was spending more time fighting with cvs and editing diffs by hand then actually hacking the features themselves.

No real comment on the VCS change. For something like Slime I have no problem with CVS, but Darcs and SVN would be fine too. (I would otherwise say git!, but git on Windows just isn't there yet, and moving to a non-Windows VCS would be just nasty right now.)

As for commit-rights, I'm not the person to talk to, but I'll still keep blabbing since my mouth is open. I don't have a clear idea of the kind of changes/fixes/improvements to Slime you have been working on, because your patches have not been feature-separated and have not come with explanations, which makes it kind of hard to form any sort of opinion -- and not having an opinion I have remained silent on the subject. Again, I don't know what others think, but I would not be surprised if I was the only one thinking like this.

i may sound [lack of proper english knowledge] but there's no anger

No problem.

least resistance in this given situation... my goal is to have a devenv that doesn't annoy us and currently having a darcs repo to share slime with my collegues and occasionally merging it with the official cvs is way much simpler then the above process.

If this works for you, good (though of course losing future patches is a pity).

If keeping it in sync with the upstream becomes more of a burden, then my advice is to pull out the feature separated patches, send them in, jump up and down till they get either merged or explicitly rejected (instead of hanging in the limbo like so many of your current ones) -- at which point when commit rights come up people will have an opinion and say "yeah". ;-)

(Or, since Slime is not a democracy, but something between a dictatorship and an anarchy, maybe someone will just flip the commit-bit...)

Cheers,

-- Nikodemus Schemer: "Buddha is small, clean, and serious." Lispnik: "Buddha is big, has hairy armpits, and laughs."

...and on retrospect perhaps the time I spend writing this would have been better spent looking at your patches... ;-)

Nikodemus Siivola nikodemus@random-state.net writes:

(Or, since Slime is not a democracy, but something between a dictatorship and an anarchy, maybe someone will just flip the commit-bit...)

i commited attila's broken patch without throughly testing it and then didn't find time to commit his fixup patch. some of the responsibility for this little mine is mine, sorry attila.

attila had asked for commit rights, personally i think most of his stuff is good and even the not 100% perfect stuff is fixable (either removing the bugs or just dropping the features). i certainly don't feel ok about adding another commiter of my own initiative, but, generally speaking, who's the dictator around here?