Hello Benjamin, Benjamin R. Haskell wrote: > On Tue, 15 May 2012, Thomas Köhler wrote: > >Thilo Six wrote: > >>Excerpt from Thomas Köhler: [...] > >>>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.)
I didn't think of "a team per language", but "the team should
have two people who understand the language", as the goal seems
to have been "if one is not available, then another one should be
able to handle the issues".
> 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.
OK, I understand your point. The problem then is: what happens if
the change is not so straight forward, but needed anyway (for
example if the specs of the language change).
> >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.
OK, java might be a problem of its own, but then things end up in
"the maintainer team is willing to take over the following 325
syntax files, leaving another 536-325=211 syntax files in their
current status quo: ..." (numbers may vary, of course...)
But maybe that's better than the current situation, so orphaned
runtime files could automatically end up in the maintainer list
or something like that...
Ciao,
Thomas
--
Thomas Köhler Email: jean-...@picard.franken.de
<>< WWW: http://gott-gehabt.de
IRC: tkoehler Freenode: thkoehler
PGP public key available from Homepage!
signature.asc
Description: Digital signature
