On Tue, 15 May 2012, Thomas Köhler wrote:
Hi Thilo,
Thilo Six wrote:
Excerpt from Thomas Köhler:
-- <snip> --
And it would help people like me that used to maintain some runtime
files in the past and now are stuck maintaining something they don't
use any longer.
I think that is exactly the meaning of team maintenance. I commit my
myself NOW for bringing some runtimefile forward BUT do NOT commit
myself the next decade to do the same!
Well, that's fine, as long as someone else picks up the work later.
For me, that would be the syntax files for uil (motif user interface
language) and prolog,
Personally i saw some (some more) patches gone lost.
To my syntax files?
(I'm fairly certain Thilo meant that some have gone lost in general, not
for your specific syntax files.)
[...]
But of course, there once was a reason for the current model, which
is "let people maintain the stuff who know what they are doing"
That exactly will not be broke by team maintenance!
Well, there might be a problem anyway. I expect uil is no longer used
very much, and prolog is still used, but I expect usage to be highest
at universities. It might be that none of the vim users that edit uil
or prolog files today are fluent enough in vim's scripting language to
be able to maintain a syntax file, but they are glad there is a syntax
file at all.
My point is: team maintenance only works well if there are at least
two people that know enough about *each* file type to be able to
actually maintain the file. That might not be true for all of the lots
of file types supported by vim right now.
I think you're misinterpreting what "team maintenance" would mean. It
wouldn't be a team per language, but rather a single team to handle
changes (maintenance) to all syntax files. (Which doesn't preclude
active maintainers from continuing to actively maintain their current
files.)
The hard part of supporting a given language in Vim is the first step:
writing the syntax file in the first place. Once there's a
relatively-complete syntax file (and most of the syntax files included
in Vim are fairly mature), the changes to that syntax file are usually
straightforward.
If a language adds a new keyword, it can often go into the same syntax
group as the other keywords already handled. If a syntax file is
highlighting something incorrectly, there's often an easy fix that can
be applied. The problem is usually Vim-syntax-related rather than
something that requires knowledge of the language being highlighted.
Right now, maintainership requires:
A maintainer who knows about both {non-Vim-language X} and Vim.
A maintainer who knows about both {non-Vim-language Y} and Vim.
A maintainer who knows about both {non-Vim-language Z} and Vim.
...etc.
Very likely, each of those maintainers is a different person. Now,
expand it to 536 (the number of syntax files). As a rough cut, there
appear to be just under 300 distinct first-maintainer lines in those 536
files. -- Nikolai Weibull (with 69 files) skews the numbers quite a bit
(Nice work, 'now').
When a problem arises, even if the change is straightforward and doesn't
really require knowledge of the non-Vim language, the end user has to
contact a maintainer who is somewhat-likely to be absentee.
Team maintenance, on the other hand, would mean that there would be a
group of people who know about Vim and are able to make changes to an
arbitrary syntax file when the need arises. Someone interested in a
given language, with even a passing interest in Vim, can suggest a
change on the Vim list, and if it's straightforward, some member of the
team can go make the change. Even if the change is complicated, if
there's some other user of {language X} on the Vim list, it usually gets
worked out what change would need to be made.
If a group of maintainers was to take over the runtime files, I
would be glad to hand over the uil and prolog syntax files to
someone who is willing to dedicate the time and effort needed, while
I really would keep maintaining the koehler.vim colorscheme myself
:-)
There will be problems! No matter what. But the point is currently
there is no one who is willing to take over some runtimefiles because
currently there is no one willing to dedicate time to it. My
personal hope is that team maintenance will neglect the availability
of individuals compared to the availability of a team member.
The problem is clear: If no one is willing to dedicate time
maintaining runtime files, you will never end up having a team of
maintainers...
It's not that "no one is willing to dedicate time maintaining runtime
files", it's that no one is willing to take over *some* runtime files.
(Java is a prominent current example.) There are plenty of regulars on
the Vim lists who seem to be willing to vet changes.
--
Best,
Ben
--
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
