I symphatize, but if _you_ have trouble separating the features, the imagine what the effort feels like to someone else...
so, darcs?
Some options to ease things on your end (I have used all of these at one time or another with different projects):
[snip the ways]
we are talking about mostly 3-liner patches! the fuzzy stuff was a standalone diff, later the small fixes to it came boundled due to the discussed reason.
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 always included the relevant ChangeLog entry. well, not a user documentation, but... same story about efficiency.
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
since then i have a gnu emacs set up.
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).
it'll be more effort then keeping a local darcs branch and occasionally darcs send -o the stuff i consider ready for public consumption but a lot less effort then messing with cvs.
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". ;-)
commit rights wouldn't have helped in me not breaking stuff due to the discussed trouble with separating patches with cvs, but the fixes would have been promptly at least (as they were, but on the list in a diff).