On 15/07/13 01:02, Lech Lorens wrote:
On 14-Jul-2013 Bram Moolenaar <[email protected]> wrote:
Ken Takata wrote:
When I run the test 98 with gvim, it stops at the last line of test98a.in.
call feedkeys(":setl scb\n\<C-w>\<C-w>", 't')
It seems that feedkeys() works different on CUI and GUI.
I don't know why the difference occurs, but using feedkeys()
is not necessary for this test. I think using "setl scb" and
"wincmd w" is enough.
Please check the attached patch.
Thanks. I also have no clue why feedkeys() was used here.
Ken: sorry for including you here, even thought only a tiny bit is
a reply for you.
I have been thinking about writing this email for at least a year now.
This patch is the straw that breaks the camel's back, so here it comes.
feedkeys() is essential there.
Try re-running the test without the fix that was introduced along with
the test. Magic: the test succeeds even without the fix!
It took 9 days for the fix to be accepted for inclusion because you,
Bram, asked for a working test (one that would fail without the fix).
Now it takes 40 minutes (!!!) to have a patch included that breaks the
test and makes all my effort (I wrote how I needed to use gdb to come up
with a method that would reproduce the problem in a script) go to
a waste.
I know, my bad for not putting in a comment, but the patches are
micromanaged to the point that the name of the file test96extra.in gets
renamed to test98a.in yet the very point of tests gets lost after only
4 days (!!!) since inclusion! That's less time than it took me to
prepare the bloody test!
Bram, don't get offended, I actually do hope that one day I will become as
competent a programmer as you are, but still I think Vim's development
process is severely broken:
- the single point of failure (Bram),
- how the decision what gets included is made with the community totally
oblivious,
- we don't have a development branch of Vim because we want stability.
Therefore the unaware users are without a single warning presented
with 7.3.970 which breaks half of syntax scripts, makes the rest 10
times slower, breaks regular expressions and introduces random
crashes. Only after a number of patches and becoming stable is the
only branch renamed to 7.4 alpha!
- we manage patches as files (as opposed to the distributed VCS way:
pull requests) because it allegedly "just works". Yet there was
a spell of a few weeks where every single week there was at least one
patch which was either applied twice, applied only partly or applied
to a wrong part of code. How can it "just work" if it so obviously
doesn't work?
All this means that a lot of effort of developers goes to a waste:
- because Bram can't (how could he possibly? He's a man: he needs to
eat, to sleep and to rest) evaluate all the possible patches and they
are added to the mythical todo.txt which means their changes of
getting included drop to almost 0,
- even though a patch got to todo.txt (and therefore will not be
included) people still work on it because they believe it will,
- people prepare a patch to fix something, a fix is published but the
solution has been totally rewritten; not a single word of explanation
is given,
- people prepare a patch, it gets included but for some reason the bug
doesn't go away. I recently had to re-debug Vim after my fix got
included only to discover that a line from my patch was not included.
The funny thing was that I did include a test and this single stable
branch of Vim was published with a failing test.
For some reason how people waste their time is OK because they volunteer
to waste their time, they are the guilty ones. But it also means that
Bram's time gets wasted:
- he needs to update todo.txt,
- he won't explain what was wrong with a patch so people will submit
those incorrect patches which Bram will have to rewrite,
- he needs to fix the problems with the mis-applied patches.
I used the pronoun "we" to mean "community" but the sorry state of Vim
development community is that IT DOES NOT EXIST. "Community" implies
a N-to-M relation between its members where N,M > 1. Here it's
a one-to-many relation between Bram and multiple patch submitters
because Bram has to evaluate every single patch. This means there's very
little incentive to examine each other's work (I will check your patch,
this way you will be more likely to check mine). That's why these
I-would-appreciate-it-if-some-people-tried-it-out emails from Bram get
so little response (and because people know that their work might go to
a waste). People work to scratch their own itches; there's no point in
scratching the itches of others.
I could write more but I think there's no point – this already got quite
long. I believe these things drive people away from Vim development or
make them one-time contributors. There used to be a nice small community
of contributors to vim-extended. We produced a number of stable, well
tested (we – as in more than an I – used them on daily basis!) features,
most of which got abandoned (because there was no change of them going
into mainline Vim. Instead the (still buggy) conceal feature got
included because someone convinced Bram it would be nice to be able turn
a text editor into e.g. a web browser. Some bugs simply got renamed as
features and everyone's happy.
I don't know why I'm writing this. I don't hope this email will change
anything. I *AM SORRY* and perhaps I believe that sharing will somehow
help me. I am a contributor of around 50-100 patches to Vim, I've been
here for 5 years and I don't feel I'm being taken seriously. I know
there are many others that will come and replace me, people whose work
could replace what I have done (I have seen one of the issues in
todo.txt solved 3 times before it got removed from todo.txt) but this
doesn't make it any less wrong. I don't deserve it. And I don't deserve
to have this email ignored.
Lech Lorens
I wouldn't say Vim development is utterly broken. Your rant above raises
some valid points, though others are exaggerated. The conceal feature
had been an unofficial patch since 6.2, maybe earlier, until finally
finally it got included in 7.3. Similarly the second half of the
floating point feature had been an unofficial patch, though not as long,
before it got included. In fact, Vim 7.3 was "enriched" with quite a
number of features which had existed for some time as "unofficial
patches", and been included /à la carte/ by a significant minority of
users. OTOH inclusion of the NFA engine, especially as "enabled by
default", seems to me to have been a hasty decision. This said, when you
say that "the development community does not exist", I think it is a
gross exaggeration. I see a lot more patches being proposed in vim_dev
nowadays than I used to see some ten years ago. Of course they aren't
all 100% perfect from day one, but that's the nature of bug fixing. And
yes, the bug fixing tends to be many-to-one rather than many-to-many but
sending bugs and proposed patches to the list (rather than by
confidential email) leaves the possibility open of having any patch
checked by someone other than Bram before it gets incorporated in the
code. Even so, the process is not strictly unicentric: Björn Winckler
(for the MacVim GUI) and Chip Campbell (for several runtime scripts) are
quite active (especially if you include vim_mac and vim_use in your
activity statistics) and there are "maintainers" for other parts of the
code (e.g. Nadim Shaikli for the Arabic module) who are less active
day-to-day but are still listed as maintainers.
Yes, I think Vim has grown, or will soon grow, to the point where at
least two pairs of eyes on every changes would be a useful development
feature: Here is what we have now (for C modules):
case 1:
- Someone reports a bug.
- Bram writes a patch.
- The patch gets included.
case 1a (variant of the above):
- Someone reports a bug.
- Bram adds it to the TODO list.
- A few years later, Bram writes a patch.
- The patch gets included.
case 2:
- Someone finds a bug, or decides to tackle a TODO list item, and writes
a patch, which he sends to vim_dev.
- Bram reviews the patch, possibly alters it a bit, but does not explain
what was wrong.
- The patch gets included.
The two-pairs-of eyes system has arguments for and against it. Here is a
possible procedure, as an alternative to the above. Vim "developers",
feel free to tear it to shreds:
1. Someone reports a bug and sends it to the vim_dev list.
-- Between steps 1 and 2 some time (years, even) may pass. I guess some
discussion might happen (is it a bug or a feature? Shall it go on the
TODO list? And how high on the list? Probably unclassified until a
consensus emerges.)
2. Someone (the same or another) writes a patch, and sends it to the
same thread of the list, asking (by name) someone known to be
knowledgeable about that part of the code to review it. (For code
written by someone else than Bram, the reviewer would most often be
Bram, but not necessarily. Code written by Bram would ideally still have
to be reviewed by someone else.)
3. The reviewer passes or fails the patch. An r- mark is always
accompanied by an explanation of what is wrong, an r+ may be accompanied
by a remark about something which should be corrected but doesn't need
re-review.
4. If r- the patch author makes the necessary changes (and fixes any
errors that he found himself by rereading or testing) and sends the
corrected patch back to the reviewer. Go to step 3. If r+ the patch
author fixes any remaining small nits and sends the patch to Bram (or to
someone with push permission on the master repo, but at the moment that
means Bram).
5. Bram has a right of "superreview". He doesn't have to spend time
checking every patch in full detail (he checks those where he's been
chosen as "reviewer", or as "additional reviewer" if the first reviewer
feels not fully competent, and any additional bugs which feels like
reviewing) but if he notices something wrong with a patch, it's back to
step 3, with explanations about what is wrong. Otherwise the patch gets
checked in.
This is only an outline. Some parts of the code (mostly in the runtime
files) already have "owners" (the so-called "maintainers"); similarly,
most of the C code is Bram's responsibility (but not all of it, see
above). It might be useful to find people whom Bram can trust (with
review) for some specific parts of the code; similarly, if some existing
maintainers find someone they can trust as "vice-maintainer" if
something happens to them, why not?
The advantage of this procedure is that several pairs of eyes are better
than one to catch bugs. But there are disadvantages:
a) It's slower than what we have now.
b) It floods the vim_dev list with discussions back and forth about each
and every bug, and that might be too much for which some users, even
some "technical" ones.
I think that (a) is inherent in any procedure where more than one pair
of eyes have to see every change; IMHO it's the flip side of trying to
catch more bugs before they get into the code.
About (b), I want to stress that the back-and-forth discussion is
necessary from a pedagogical point of view (people interested in fixing
bugs in some particular part of the code get to learn the ins and outs
of that part "at an elder's knee") and from a redundancy point of view
(everything is checked at least twice, and no change goes in
unreviewed); but I can imagine that it list flooding might become a
problem at some future point; we would then need a "real" bug tracker,
which doesn't send all bug-fixing discussions to the one list, but only
to the reviewer, the patch author (if any), and anyone having expressed
an interest (or been asked for advice) about the bug, or about the part
of the code the bug is in. Maybe (but it doesn't have to be implemented
immediately) something like Bugzilla, which is widely known and much
used (by 1268 companies as of 10 May 2012, according to
http://www.bugzilla.org/installation-list/ ). However I don't know how
heavy Bugzilla is in terms of infrastructure; but I think this is a
long-term evolution.
Best regards,
Tony.
--
If you've done six impossible things before breakfast, why not round it
off with dinner at Milliway's, the restaurant at the end of the universe?
-- Douglas Adams, "The Restaurant at the End of the Universe"
--
--
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php
---
You received this message because you are subscribed to the Google Groups "vim_dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
For more options, visit https://groups.google.com/groups/opt_out.
