[slime-devel] Re: Daily ChangeLog diff

[Nikodemus Siivola]

"Attila Lendvai" <attila.lendvai at 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... ;-)