Added support for spell checking in runtime/syntax/ocaml.vim

[Dominique Pellé]

Hi

Attached patch adds @Spell to the runtime/syntax/ocaml.vim file
so that Vim only highlights spelling mistakes in comments and
strings when editing an ocaml source file with those settings:

:syntax on
:set spell

Regards
-- Dominique

[Charles Campbell]

Dominique: did you contact the syntax file maintainers? (ditto for the
other two syntax file changes).

Regards,
Chip Campbell

[Dominique Pellé]

Charles Campbell <Charles.E...@nasa.gov> wrote:

Yes. Maintainers were in CC of the emails. But perhaps I should write
to the maintainers only to avoid sending too many emails to vim_dev
(still more of those simple patches to come...)

Regards
-- Dominique

[John Beckett]

Dominique Pellé wrote:
> Yes. Maintainers were in CC of the emails. But perhaps I
> should write to the maintainers only to avoid sending too many
> emails to vim_dev (still more of those simple patches to
> come...)

There is no good way to do this except to email the maintainers
only ... wait, try again ... repeat. If get a positive response,
good. Otherwise, find a volunteer to take over maintenance!

That's too much work for what you are doing, but Bram cannot
take patches like these because the maintainer might later send
an update to Bram, but the maintainer failed to receive, or
failed to process, your email. So the later update could easily
remove your patch.

John

[Dominique Pellé]

I've started to send patches to maintainers. I'll wait for responses.

Some of the emails of maintainers already bounce, at least
for syntax/{bc,expect,vhdl}.vim.

Unless current maintainer sends messages, I volunteer to
maintain bc.vim (last change was in 2001).

I have not used expect or vhdl in years so I'd rather let
someone else volunteer to maintain them.

Regards
-- Dominique

[Thilo Six]

Hello John,


Excerpt from John Beckett:

That is exactlx what i think about the current practice, too.
Really i think instead of that single-point-of-failure modell of maintenance we
should move the a team maintenance of runtimefiles.
Unless that changes it is nearly impossible to get archive wide
features/policies applied.

>
> John
>

--
Regards,
Thilo

4096R/0xC70B1A8F
721B 1BA0 095C 1ABA 3FC6 7C18 89A4 A2A0 C70B 1A8F

[Benjamin R. Haskell]

On Sat, 12 May 2012, Thilo Six wrote:

> Excerpt from John Beckett:
>

>> Dominique Pellé wrote:
>>> Yes. Maintainers were in CC of the emails. But perhaps I should
>>> write to the maintainers only to avoid sending too many emails to
>>> vim_dev (still more of those simple patches to come...)
>>
>> There is no good way to do this except to email the maintainers only
>> ... wait, try again ... repeat. If get a positive response, good.
>> Otherwise, find a volunteer to take over maintenance!
>>
>> That's too much work for what you are doing, but Bram cannot take
>> patches like these because the maintainer might later send an update
>> to Bram, but the maintainer failed to receive, or failed to process,
>> your email. So the later update could easily remove your patch.
>
> That is exactlx what i think about the current practice, too. Really
> i think instead of that single-point-of-failure modell of maintenance
> we should move the a team maintenance of runtimefiles. Unless that
> changes it is nearly impossible to get archive wide features/policies
> applied.

I concur completely that a team of runtime file maintainers sounds
better. Back in January, I started composing an email wondering whether
having maintainers still made sense as a development model.
(Personally, I also find it very odd that even after switching to
Mercurial there are still hundreds of individual patch-files that can be
obtained via FTP, but that's probably a much broader discussion.) In
addition to the issues with maintainership mentioned so far:

- Maintainer might not be responsive, creating more work for Bram and/or
the maintainer later

- Maintainer can't make Vim-wide changes (like the '&cpo' changes from
earlier this year)

My main concerns are that:

- (it seems) Many maintainers are never really all-that committed.

Probably similar to the above concerns, but it makes perfect sense.
Over the past nine years, the main programming language I myself use on
a daily basis has gone from Perl to C# to PHP and now to Ruby. It's
hard to find someone to be a long-term maintainer for {Language X} where
that user is also well-versed enough in Vim to keep the syntax
well-maintained.

- Having a maintainer makes bugs last longer, especially for minor bugs.

Since even minor changes have to go through a maintainer, (it seems)
that changes don't immediately get sent back up to Bram. Often versions
seem to linger until there are enough minor updates that the maintainer.


Just for some data points, at the time I was writing the email in
January (which I never sent), I was able to very quickly find four
instances where having a maintainer made things more difficult:

Date | Subject:

2012-01-31 | ruby.vim does not work with greater than rubygems 1.7
Patch was mailed to maintainer, possibly didn't get back to Bram.

2012-01-17 | [patch] indent/java.vim: the line after @Override should not indent
Java maintainer has resigned.

2012-01-16 | spellcheck in mail: Subject header key is incorrectly underlined
Lech Lorens reported to maintainer long ago, update didn't get to Bram.

2012-01-08 | [patch] vim: runtime/syntax/jam.vim
Email bounced trying to send to maintainer, so sent patch to list.

--
Best,
Ben

[Thilo Six]

Hello Benjamin,


Excerpt from Benjamin R. Haskell:

-- <snip> --

> I concur completely that a team of runtime file maintainers sounds
> better. Back in January, I started composing an email wondering whether
> having maintainers still made sense as a development model.
> (Personally, I also find it very odd that even after switching to
> Mercurial there are still hundreds of individual patch-files that can be
> obtained via FTP, but that's probably a much broader discussion.) In
> addition to the issues with maintainership mentioned so far:
>
> - Maintainer might not be responsive, creating more work for Bram and/or
> the maintainer later

..or a random patch submitter.
confirmed.

> - Maintainer can't make Vim-wide changes (like the '&cpo' changes from
> earlier this year)

confirmed.

>
> My main concerns are that:
>
> - (it seems) Many maintainers are never really all-that committed.

IIRC a maintainer has committed himself to be reachable via email 3 years after
his last change. (I must have read that in vim help somewhere, but need to seek
that out again first where exactly that was).

...but

$ recgrep -c "by Thilo Six" . | grepinvert "0$" | wc -l
28

basically all of those files have been changed last time by their original
maintainer a decade ago!

> Probably similar to the above concerns, but it makes perfect sense.
> Over the past nine years, the main programming language I myself use on
> a daily basis has gone from Perl to C# to PHP and now to Ruby. It's
> hard to find someone to be a long-term maintainer for {Language X} where
> that user is also well-versed enough in Vim to keep the syntax
> well-maintained.
>
> - Having a maintainer makes bugs last longer, especially for minor bugs.
>
> Since even minor changes have to go through a maintainer, (it seems)
> that changes don't immediately get sent back up to Bram. Often versions
> seem to linger until there are enough minor updates that the maintainer.

I know currently patches go lost!

> Just for some data points, at the time I was writing the email in
> January (which I never sent), I was able to very quickly find four
> instances where having a maintainer made things more difficult:
>
> Date | Subject:
>
> 2012-01-31 | ruby.vim does not work with greater than rubygems 1.7
> Patch was mailed to maintainer, possibly didn't get back to Bram.
>
> 2012-01-17 | [patch] indent/java.vim: the line after @Override should not indent
> Java maintainer has resigned.
>
> 2012-01-16 | spellcheck in mail: Subject header key is incorrectly underlined
> Lech Lorens reported to maintainer long ago, update didn't get to Bram.
>
> 2012-01-08 | [patch] vim: runtime/syntax/jam.vim
> Email bounced trying to send to maintainer, so sent patch to list.


--

[Thilo Six]

-- <snip> --

> IIRC a maintainer has committed himself to be reachable via email 3 years after
> his last change. (I must have read that in vim help somewhere, but need to seek
> that out again first where exactly that was).
>

This is a good read:
:h develop.txt

though it does no contain that portion i am seeking
-- <snip> --

[Dominique Pellé]

Benjamin R. Haskell <v...@benizi.com> wrote:

[...]

> On Sat, 12 May 2012, Thilo Six wrote:

[...]

>> That is exactlx what i think about the current practice, too.  Really i
>> think instead of that single-point-of-failure modell of maintenance we
>> should move the a team maintenance of runtimefiles.  Unless that changes it
>> is nearly impossible to get archive wide features/policies applied.
>
>
> I concur completely that a team of runtime file maintainers sounds better.

Yes, a team of runtime file maintainers sounds good to me,
at least for files that have not been touched by the maintainer
in the last x years.

Some statistics: I've contacted the maintainers of 15 syntax files
this weekend to add spelling checker support. The stats so far are:

- 4 responses received from maintainers of awk, forth, ocaml, scheme (thanks!);
- 6 emails without response so far (but it's fair to wait a bit more);
- 5 emails bounced for syntax files: bc, mmix, xpm2, expect, vhdl.

I'll send the proposed patch to Bram after I wait a bit further.

Regards
-- Dominique

[Thilo Six]

Hello Dominique,


Excerpt from Dominique Pell�:

-- <snip> --

> Some statistics: I've contacted the maintainers of 15 syntax files
> this weekend to add spelling checker support. The stats so far are:
>
> - 4 responses received from maintainers of awk, forth, ocaml, scheme (thanks!);
> - 6 emails without response so far (but it's fair to wait a bit more);
> - 5 emails bounced for syntax files: bc, mmix, xpm2, expect, vhdl.

in short 4 to 11.

Some months later that will change to somewhat 10 to 5. piriod.
Sad but true... and nothing else matters!

>
> I'll send the proposed patch to Bram after I wait a bit further.
>
> Regards
> -- Dominique
>

[Thomas Köhler]

Hi all,

Dominique Pellé wrote:
> Benjamin R. Haskell <v...@benizi.com> wrote:
> [...]
> > On Sat, 12 May 2012, Thilo Six wrote:
> [...]
> >> That is exactlx what i think about the current practice, too.  Really i
> >> think instead of that single-point-of-failure modell of maintenance we
> >> should move the a team maintenance of runtimefiles.  Unless that changes it
> >> is nearly impossible to get archive wide features/policies applied.

You may be right here, but there's a reason for the current
model...

> > I concur completely that a team of runtime file maintainers sounds better.

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.
For me, that would be the syntax files for uil (motif user
interface language) and prolog, both of which I used to use at
university. But I left university more than 10 years ago, so I'm
stuck with maintaining something I don't use any longer myself.

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" in the sense that people started maintain runtime files
when they were using the stuff by themselves. Unfortunately, the
only thing I keep using myself today is the koehler.vim
colorscheme :-)

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 :-)

> Yes, a team of runtime file maintainers sounds good to me,
> at least for files that have not been touched by the maintainer
> in the last x years.
>
> Some statistics: I've contacted the maintainers of 15 syntax files
> this weekend to add spelling checker support. The stats so far are:
>
> - 4 responses received from maintainers of awk, forth, ocaml, scheme (thanks!);
> - 6 emails without response so far (but it's fair to wait a bit more);

That should now at least be 5:5 :-)
It's always a good idea to give people a few days time to reply,
especially for their private email which they might not read for
a few days. When I am on vacation, it is possible that I don't
read my mail for two or three weeks - because my vacation tends
to be a no-internet-for-a-while time :)

> - 5 emails bounced for syntax files: bc, mmix, xpm2, expect, vhdl.
>
> I'll send the proposed patch to Bram after I wait a bit further.

That's a good approach for the fallback in any case.

> Regards
> -- Dominique

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!

[Thilo Six]

Hello Thomas,

I answer on list.


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!

> 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.

> both of which I used to use at
> university. But I left university more than 10 years ago, so I'm
> stuck with maintaining something I don't use any longer myself.

see above.

> 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!

> in the sense that people started maintain runtime files
> when they were using the stuff by themselves. Unfortunately, the
> only thing I keep using myself today is the koehler.vim
> colorscheme :-)

;)

> 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.

>> Yes, a team of runtime file maintainers sounds good to me,
>> at least for files that have not been touched by the maintainer
>> in the last x years.
>>
>> Some statistics: I've contacted the maintainers of 15 syntax files
>> this weekend to add spelling checker support. The stats so far are:
>>
>> - 4 responses received from maintainers of awk, forth, ocaml, scheme (thanks!);
>> - 6 emails without response so far (but it's fair to wait a bit more);
>
> That should now at least be 5:5 :-)
> It's always a good idea to give people a few days time to reply,
> especially for their private email which they might not read for
> a few days. When I am on vacation, it is possible that I don't
> read my mail for two or three weeks - because my vacation tends
> to be a no-internet-for-a-while time :)

Personal i gave people now more than 6 months to respond. Without success!
How long should we wait until we expect someone to be MIA?

Personal i think Vim runtimefiles is like Debian without the so called MIA
proses and without Debian policy!

Really Debian had the smae struggles in the past why not learn from their
experience they had in the past?

I hate the not invented here syndrome not only for:
http://koeln.ccc.de/prozesse/writing/artikel/hacker-howto-esr.xml
which is german but it says at top that its english version is at:
http://catb.org/~esr/faqs/hacker-howto.html

but also because of Vim is precision to the byte. It is striving for perfection.

>> - 5 emails bounced for syntax files: bc, mmix, xpm2, expect, vhdl.
>>
>> I'll send the proposed patch to Bram after I wait a bit further.
>
> That's a good approach for the fallback in any case.
>
>> Regards
>> -- Dominique
>
> Ciao,
> Thomas
>

--

[Thomas Köhler]

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?
Well, it's possible I didn't see the mails, as I have to use a
spam filter to be able to follow my private email at all, and you
can never rule out false positives, but if you can tell me when
there were emails that belong to one of my syntax files, I will
have a look in my mail archives.

[...]

> > 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.

> > 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...

> >> Yes, a team of runtime file maintainers sounds good to me,
> >> at least for files that have not been touched by the maintainer
> >> in the last x years.

BTW, some files might not be changed because there is not much need.
I last changed uil.vim and prolog.vim in 2009 to support some new
feature available in vim (and uil.vim yesterday due to
Dominique's patch for @Spell support), and before that, I think I
changed them somewhen back in 2004 or so (I would have to check
my mail archive, as I don't have the syntax files in version
control yet).

> >> Some statistics: I've contacted the maintainers of 15 syntax files
> >> this weekend to add spelling checker support. The stats so far are:
> >>
> >> - 4 responses received from maintainers of awk, forth, ocaml, scheme (thanks!);
> >> - 6 emails without response so far (but it's fair to wait a bit more);
> >
> > That should now at least be 5:5 :-)
> > It's always a good idea to give people a few days time to reply,
> > especially for their private email which they might not read for
> > a few days. When I am on vacation, it is possible that I don't
> > read my mail for two or three weeks - because my vacation tends
> > to be a no-internet-for-a-while time :)
>
> Personal i gave people now more than 6 months to respond. Without success!
> How long should we wait until we expect someone to be MIA?

I'd say 6 months is too long, but please try several times, as
your first mail might have ended up in some spam filter. But if
you don't get a response after two or three months, the runtime
file should be considered orphaned IMHO. I think this point
should be discussed.

> Personal i think Vim runtimefiles is like Debian without the so called MIA
> proses and without Debian policy!
>
> Really Debian had the smae struggles in the past why not learn from their
> experience they had in the past?

There might be some more debian maintainers out there than there
are vim runtime file maintainers, plus there are always some
debian packages being orphaned or completely removed from debian.
Maybe it should be discussed how to handle orphaned runtime files
anyway.
But I don't think we can send orphaned runtime files to Kibaale :)

> I hate the not invented here syndrome not only for:
> http://koeln.ccc.de/prozesse/writing/artikel/hacker-howto-esr.xml
> which is german but it says at top that its english version is at:
> http://catb.org/~esr/faqs/hacker-howto.html
>
> but also because of Vim is precision to the byte. It is striving for perfection.

Perfection will never be reached. There is always something one
could do better :-)

[Benjamin R. Haskell]

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

[Thomas Köhler]

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".

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...

[Ben Fritz]

I like the idea of team maintenance of runtime files. I don't see why we shouldn't just do it for all the runtime files. Just set up a Bitbucket or Github clone (or another Google Code project, but I don't see a good way to relate it back to the main Vim repository, and clones made on the Google Code site can only have a single committer) and give all current runtime maintainers commit access. If a file has a listed maintainer, that person would by default be the person to make the change; but if they become unresponsive and the change is straightforward enough, the team could step in.

[Thilo Six]

Hello Thomas and Benjamin,

Excerpt from Thomas K�hler:
-- <snip> --

>> 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".

When i think of this team i count each current maintainer as a member already.
The idea is to use a mailinglist where anyone who likes can subscribe (think of
vim-dev). All communication about runtimefiles happens openly. Not 99% via
private email where no one can learn from each other and reviewing changes is
left to Bram alone.

So basically the only change for now would then be this line:
" Maintainer: Thilo Six <T Dot Six At gmx dot de>

would change to
" Maintainer: Thilo Six <vimruntime-maintainers at foo dot org>

Still i am the main-maintainer but not the only one. Questions, fixes, additions
would *NOT* go lost just because my mailprovider has changed, or because i lost
interest in it 4 years ago.

No one is anyone blocking to take care of their peeve pets.

I hope that makes my intention of this team a bight easier to understand.

Well what happens now in this case? Someone who is interested in it sit down and
patches it.

>>> 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...

see above my example with the mailling list.

[Gary Johnson]

On 2012-05-15, Thilo Six wrote:

> When i think of this team i count each current maintainer as a member already.
> The idea is to use a mailinglist where anyone who likes can subscribe (think of
> vim-dev). All communication about runtimefiles happens openly. Not 99% via
> private email where no one can learn from each other and reviewing changes is
> left to Bram alone.
>
> So basically the only change for now would then be this line:
> " Maintainer: Thilo Six <T Dot Six At gmx dot de>
>
> would change to
> " Maintainer: Thilo Six <vimruntime-maintainers at foo dot org>
>
> Still i am the main-maintainer but not the only one. Questions, fixes, additions
> would *NOT* go lost just because my mailprovider has changed, or because i lost
> interest in it 4 years ago.
>
> No one is anyone blocking to take care of their peeve pets.
>
> I hope that makes my intention of this team a bight easier to understand.

I like it.

Do you think there would be enough maintenance traffic to justify a
separate runtime-maintainers list or would vim-dev suffice?

Regards,
Gary

[Christian Brabandt]

On Di, 15 Mai 2012, Gary Johnson wrote:
> I like it.
>
> Do you think there would be enough maintenance traffic to justify a
> separate runtime-maintainers list or would vim-dev suffice?

+1

If the traffic isn't too big, I would prefer vim-dev list (since I am
already subscribed) so please add me to the list ;)

regards,
Christian

[Thilo Six]

Hello Gary and Christian,


Excerpt from Christian Brabandt:

Seems we get it moving. Sounds great. :)

Personally i do not have any preference where this list is located. Regarding
using vim-dev i think we should also ask Bram what he thinks about that, cc'ed.

Bram what do you think putting runtimefiles under team maintenance and using
vim-dev for coordination of that group?

> regards,
> Christian

[Ernie Rael]

On 5/15/2012 9:02 AM, Thilo Six wrote:
>
> No one is anyone blocking to take care of their peeve pets.

I'd be hesitant to suggest that people "take care of their pet peeves".
Yes for real bugs or "infrastructure" features (like spell). But since
there is hopefully a main guy for each file, shouldn't random changes be
kept to a minimum?

[Thomas Köhler]

Hello Thilo,

Thilo Six wrote:
> Hello Thomas and Benjamin,

> Excerpt from Thomas Köhler:

> -- <snip> --
> >> 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".
>
> When i think of this team i count each current maintainer as a member already.
> The idea is to use a mailinglist where anyone who likes can subscribe (think of
> vim-dev). All communication about runtimefiles happens openly. Not 99% via
> private email where no one can learn from each other and reviewing changes is
> left to Bram alone.
>
> So basically the only change for now would then be this line:
> " Maintainer: Thilo Six <T Dot Six At gmx dot de>
>
> would change to
> " Maintainer: Thilo Six <vimruntime-maintainers at foo dot org>
>
> Still i am the main-maintainer but not the only one. Questions, fixes, additions
> would *NOT* go lost just because my mailprovider has changed, or because i lost
> interest in it 4 years ago.
>
> No one is anyone blocking to take care of their peeve pets.
>
> I hope that makes my intention of this team a bight easier to understand.

OK, now things are clearer for me. That's basically a good idea,
but:
- URL would also need to change:
http://gott-gehabt.de/800_wer_wir_sind/thomas/Homepage/Computer/vim/syntax/uil.vim
would need to become something different, for example
http://www.vim.org/runtimefiles/syntax/uil.vim
- all the vim runtime file maintainers would need to have
read/write access below http://www.vim.org/runtimefiles/ (or
whereever that is)

The reason is that if another maintainer changes a file, the file
also should be changed at the URL given in the file.

Of course there could be a git repository with all runtime files
included, and all maintainers just send patches to a group of git
maintainers, and the URL would point to where the central git
repository would show the file, which would put down the number
of people that need read/write access from a few hundred to just
a few. What do you think?

[Benjamin R. Haskell]

I took "pet peeves" to mean minor bugs that are annoying on a daily
basis, not random features. Personally, I think "random" (as in, minor)
changes should be maximized. The more items that go directly from bug
report to fixes in a short amount of time, the more pleasant it is to
use Vim.

--
Best,
Ben

[Ben Fritz]

On Wednesday, May 16, 2012 1:14:00 AM UTC-5, Thomas Köhler wrote:
>
> OK, now things are clearer for me. That's basically a good idea,
> but:
> - URL would also need to change:
> http://gott-gehabt.de/800_wer_wir_sind/thomas/Homepage/Computer/vim/syntax/uil.vim
> would need to become something different, for example
> http://www.vim.org/runtimefiles/syntax/uil.vim
> - all the vim runtime file maintainers would need to have
> read/write access below http://www.vim.org/runtimefiles/ (or
> whereever that is)
>
> The reason is that if another maintainer changes a file, the file
> also should be changed at the URL given in the file.
>

Yes, agreed.

> Of course there could be a git repository with all runtime files
> included,

Or, how about just a clone of the main Vim repository? Often runtime file changes are related to changes in the Vim code. If we get going well enough we might even convince Bram to pull runtime file changes directly.

I think the "official" repository should be a Mercurial clone, because that's what Vim's official repository is, but there are extensions to both Hg and git which allow them to work on the other's repository or convert one to the other losslessly. So there could be secondary clones all over in git or Hg if desired.

> and all maintainers just send patches to a group of git
> maintainers, and the URL would point to where the central git
> repository would show the file, which would put down the number
> of people that need read/write access from a few hundred to just
> a few. What do you think?
>

I think I'd rather see it done with push/pull. If not everyone has push access (I don't see why that shouldn't be the goal) each maintainer could easily make their own clone and tell the main repo's maintainer(s) "please pull revXXXXXX from my repository at YYYY".

Periodically Bram could either pull from the runtime repository, or export the latest as a patch against the last merged version from the official repository.

[Ben Fritz]

Yes, I think that would be one of the main benefits of the team approach.

I think how to handle feature additions/big changes might depend on the "main" maintainer. Some might be OK with "big" changes being made, while others might want to reserve those for themselves.

One thing the maintainer might do is be the default reviewer for changes not done by him/herself. But if it hasn't happened in a timely fashion the team can step in.

[Thilo Six]

Hello Ernie,


Excerpt from Ernie Rael:

-- <snip> --

> But since
> there is hopefully a main guy for each file, shouldn't random changes be
> kept to a minimum?

Well i can only speak for myself. Usually i very hardly try to be friendly. That
means the workflow of asking the maintainer for a change first would not change.
The difference would be that this question would happen openly on list instead
of pm.
The intention of team maintenance is to increase cooperation between maintainers
AND to reduce frustration because the person who has the last word is out of reach.

...and as already has been pointed out be me "hopefully a main guy for each
file" is just a hope not reality.
If you would wade through runtime you rather soon discover that fact.

[Thilo Six]

Hi Thomas and Ben,


Excerpt from Ben Fritz:

> On Wednesday, May 16, 2012 1:14:00 AM UTC-5, Thomas K�hler wrote:
>>
>> OK, now things are clearer for me. That's basically a good idea,
>> but:
>> - URL would also need to change:
>> http://gott-gehabt.de/800_wer_wir_sind/thomas/Homepage/Computer/vim/syntax/uil.vim
>> would need to become something different, for example
>> http://www.vim.org/runtimefiles/syntax/uil.vim
>> - all the vim runtime file maintainers would need to have
>> read/write access below http://www.vim.org/runtimefiles/ (or
>> whereever that is)
>>
>> The reason is that if another maintainer changes a file, the file
>> also should be changed at the URL given in the file.
>>
>
> Yes, agreed.

*grin* we are already discussion implementation details. Seems like everyone
agrees this is a good way forward.

Well in my experience each active vim maintainer is rather knowledgeable *and*
friendly. I am sure if one tells an other: "Hey we need to change that url,
too". That asked person will do what he is asked for.
Same with a missing keyword, a suboptimal regex or what ever.
If we communicate we each other we will find a solution or an other. But the
situation that led to this thread was simply no communication, not even
technically possible.
As i said earlier there will be problems. Discuss them on list, think about
them, fix them.

>> Of course there could be a git repository with all runtime files
>> included,
>
> Or, how about just a clone of the main Vim repository? Often runtime file changes are related to changes in the Vim code. If we get going well enough we might even convince Bram to pull runtime file changes directly.
>
> I think the "official" repository should be a Mercurial clone, because that's what Vim's official repository is, but there are extensions to both Hg and git which allow them to work on the other's repository or convert one to the other losslessly. So there could be secondary clones all over in git or Hg if desired.
>
>> and all maintainers just send patches to a group of git
>> maintainers, and the URL would point to where the central git
>> repository would show the file, which would put down the number
>> of people that need read/write access from a few hundred to just
>> a few. What do you think?
>>
>
> I think I'd rather see it done with push/pull. If not everyone has push access (I don't see why that shouldn't be the goal) each maintainer could easily make their own clone and tell the main repo's maintainer(s) "please pull revXXXXXX from my repository at YYYY".
>
> Periodically Bram could either pull from the runtime repository, or export the latest as a patch against the last merged version from the official repository.

I thought about a repo, too. If we will have one i also prefer that it has an
interface to mercurial (probably even must have). No matter what that $VCS (or
%VCS% as some use here) will be.
Hopefully a nice fall-out would be that Bram can spend more time on Vim directly
rather then on runtimefiles. Lets see how that works out.

[Ingo Karkat]

On 16-May-2012 08:35:30 -0700 (PDT), Ben Fritz wrote:

> Or, how about just a clone of the main Vim repository? Often runtime
> file changes are related to changes in the Vim code.

Often? Vim has superb backward compatibility, and the thing that started this
thread is adding @Spell support, something which was introduced years ago with
Vim 7.0.

> If we get going well enough we might even convince Bram to pull
> runtime file changes directly.

I would like to see runtime files treated the same way as all other Vim sources.
Right now, no patches are published, and Bram just occasionally commits them to
the repo. I think Bram is already busy enough with the core sources, so the only
way for this to work without taxing him even more would be opening up the main
repo for a set of long-term, trusted deputies. (Which, assuming there are such
capable and willing volunteers, would be a good thing to avoid a potential
bottleneck, and could eventually offer a faster development speed - also for Vim
core. (Just take a look at the long todo list and patch queue.))

> I think I'd rather see it done with push/pull. If not everyone has
> push access (I don't see why that shouldn't be the goal) each
> maintainer could easily make their own clone and tell the main repo's
> maintainer(s) "please pull revXXXXXX from my repository at YYYY".

Ahem, if this depends on a main maintainer, we're back to where we are today: a
single person point of failure.

-- regards, ingo

[Dominique Pellé]

Ingo Karkat <sw...@ingo-karkat.de> wrote:

> I would like to see runtime files treated the same way as all other Vim sources.
> Right now, no patches are published, and Bram just occasionally commits them to
> the repo.

Aren't you using Mercurial? Runtime files are now updated quite
often in Mercurial. Here are the dates of the last 10 edits of
file runtime/doc/todo.txt in Mercurial for example:

$ hg log runtime/doc/todo.txt| grep '^date:' | head -10
date: Tue May 01 21:14:34 2012 +0200
date: Mon Apr 30 15:56:52 2012 +0200
date: Thu Apr 26 20:17:03 2012 +0200
date: Wed Apr 25 19:07:41 2012 +0200
date: Fri Apr 13 23:04:47 2012 +0200
date: Thu Apr 05 17:33:26 2012 +0200
date: Wed Mar 28 20:51:51 2012 +0200
date: Sun Mar 11 15:57:40 2012 +0100
date: Wed Feb 22 17:30:19 2012 +0100
date: Mon Feb 13 00:05:22 2012 +0100

Besides submitting patches to the vim runtime file, it would
also be good to suggest authors of good syntax files not
already present in the default Vim repository to submit them.
For example, Vim has by default no syntax files for Scala,
Go or Zimbu (among plenty of other syntax files)

-- Dominique

[Ingo Karkat]

On 16-May-2012 21:42, Dominique Pell� wrote:

> Ingo Karkat <sw...@ingo-karkat.de> wrote:
>
>> I would like to see runtime files treated the same way as all other
>> Vim sources. Right now, no patches are published, and Bram just
>> occasionally commits them to the repo.
>
> Aren't you using Mercurial?

Yes, I am, though I'm following vim_dev (and the posted patches) more closely,
but only re-compiling a fresh Vim every few weeks or so.

> Runtime files are now updated quite often in Mercurial. Here are the
> dates of the last 10 edits of file runtime/doc/todo.txt in Mercurial
> for example:
>
> $ hg log runtime/doc/todo.txt| grep '^date:' | head -10
> date: Tue May 01 21:14:34 2012 +0200
> date: Mon Apr 30 15:56:52 2012 +0200
> date: Thu Apr 26 20:17:03 2012 +0200
> date: Wed Apr 25 19:07:41 2012 +0200
> date: Fri Apr 13 23:04:47 2012 +0200
> date: Thu Apr 05 17:33:26 2012 +0200
> date: Wed Mar 28 20:51:51 2012 +0200
> date: Sun Mar 11 15:57:40 2012 +0100
> date: Wed Feb 22 17:30:19 2012 +0100
> date: Mon Feb 13 00:05:22 2012 +0100

That doesn't tell the whole picture.

$ hg log runtime/ | grep '^summary:' | head -10
summary: More runtime file fixes for 'compatible' mode.
summary: updated for version 7.3.514
summary: Fixed compatible mode in most runtime files.
summary: Updated runtime files, include fixes for line continuation.
summary: Updated runtime files.
summary: Updated runtime files.
summary: Updated runtime files.
summary: updated for version 7.3.492
summary: updated for version 7.3.490
summary: Updated runtime files.

Call me pedantic, but I'm missing the description of the change plus the actual
author of the patch, and I remember seeing multiple, unrelated changes thrown
into a single commit. It's not nearly as descriptive as the mailed patches, and
(for me) so hard to follow that I don't bother.

That's why I said I want them treated the same (and suggested additional
committers to lift the effort off of Bram's shoulders).

-- regards, ingo

[Bram Moolenaar]

Including patches for runtime files doesn't take much of my time, under
the condition that I can include them as-is. Most time goes into
reviewing the change and making sure it doesn't break anything. Or
omits another change that was submitted before.

So, what we need is a few people who can review patches. And a
procedure that is easy to use for everybody. Especially for
maintainers, so that we make their life easier and get more volunteers
that know a specific language.

It's possible to have a repository that has the "beta-test" version of
the runtime scripts. With a small group of committers. Ideally these
people also have some scripts to check for obvious problems, such as
using line continuation without setting 'cpo'.

I can then pull files from that repository once tested and add them to
the release repository. The group of committers could send me a list of
files to pull weekly (or whenever something important was fixed). Does
that sound like a good solution?

The main repository would continue to have few commits that contain a
bunch of runtime file changes. Someone interested in the details would
have to go to the "beta-test" repository.

--
CART DRIVER: Bring out your dead!
We follow the cart through a wretched, impoverished plague-ridden village.
A few starved mongrels run about in the mud scavenging. In the open
doorway of one house perhaps we jug glimpse a pair of legs dangling from
the ceiling. In another doorway an OLD WOMAN is beating a cat against a
wall rather like one does with a mat. The cart passes round a dead donkey
or cow in the mud. And a MAN tied to a cart is being hammered to death by
four NUNS with huge mallets.
"Monty Python and the Holy Grail" PYTHON (MONTY) PICTURES LTD

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Ben Fritz]

On Wednesday, May 16, 2012 2:15:34 PM UTC-5, Ingo Karkat wrote:
> On 16-May-2012 08:35:30 -0700 (PDT), Ben Fritz wrote:
>
> > Or, how about just a clone of the main Vim repository? Often runtime
> > file changes are related to changes in the Vim code.
>
> Often? Vim has superb backward compatibility, and the thing that started this
> thread is adding @Spell support, something which was introduced years ago with
> Vim 7.0.
>

By "often" I mean, "often the changes to a runtime file are due to new features in Vim", not "often changes in Vim drive changes to runtime files".

As you point out, this thread was started because something was added to the Vim code and the runtime file is finally getting updated for it. While this particular file isn't a good example because it took so long to implement, it would be nice to know from the branch history in Mercurial what version of Vim will definitely work with the runtime file in question.

[Thilo Six]

Hello Bram,


Excerpt from Bram Moolenaar:
-- <snip> --

> Including patches for runtime files doesn't take much of my time, under
> the condition that I can include them as-is. Most time goes into
> reviewing the change and making sure it doesn't break anything. Or
> omits another change that was submitted before.
>
> So, what we need is a few people who can review patches. And a
> procedure that is easy to use for everybody. Especially for
> maintainers, so that we make their life easier and get more volunteers
> that know a specific language.
>
> It's possible to have a repository that has the "beta-test" version of
> the runtime scripts. With a small group of committers. Ideally these
> people also have some scripts to check for obvious problems, such as
> using line continuation without setting 'cpo'.
>
> I can then pull files from that repository once tested and add them to
> the release repository. The group of committers could send me a list of
> files to pull weekly (or whenever something important was fixed). Does
> that sound like a good solution?

To me absolutely yes. Obviously we will need to discuss and decide some more
details/workflows but i think the consensus is broad enough to start getting it
productive.
Are you fine with using vim-dev as our mailinglist for all runtime related
questions?

> The main repository would continue to have few commits that contain a
> bunch of runtime file changes. Someone interested in the details would
> have to go to the "beta-test" repository.
>

--

[Bram Moolenaar]

Thilo Six wrote:

> Excerpt from Bram Moolenaar:
> -- <snip> --
> > Including patches for runtime files doesn't take much of my time, under
> > the condition that I can include them as-is. Most time goes into
> > reviewing the change and making sure it doesn't break anything. Or
> > omits another change that was submitted before.
> >
> > So, what we need is a few people who can review patches. And a
> > procedure that is easy to use for everybody. Especially for
> > maintainers, so that we make their life easier and get more volunteers
> > that know a specific language.
> >
> > It's possible to have a repository that has the "beta-test" version of
> > the runtime scripts. With a small group of committers. Ideally these
> > people also have some scripts to check for obvious problems, such as
> > using line continuation without setting 'cpo'.
> >
> > I can then pull files from that repository once tested and add them to
> > the release repository. The group of committers could send me a list of
> > files to pull weekly (or whenever something important was fixed). Does
> > that sound like a good solution?
>
> To me absolutely yes. Obviously we will need to discuss and decide some more
> details/workflows but i think the consensus is broad enough to start
> getting it productive.
> Are you fine with using vim-dev as our mailinglist for all runtime related
> questions?

Yes, I don't expect too much more discussion than what we already have.

--
CART DRIVER: Bring out your dead!

LARGE MAN: Here's one!
CART DRIVER: Ninepence.
BODY: I'm not dead!

[Thilo Six]

Hello Bram and Ben,

Excerpt from Bram Moolenaar:
-- <snip> --
>>> Including patches for runtime files doesn't take much of my time, under
>>> the condition that I can include them as-is. Most time goes into
>>> reviewing the change and making sure it doesn't break anything. Or
>>> omits another change that was submitted before.
>>>
>>> So, what we need is a few people who can review patches. And a
>>> procedure that is easy to use for everybody. Especially for
>>> maintainers, so that we make their life easier and get more volunteers
>>> that know a specific language.
>>>
>>> It's possible to have a repository that has the "beta-test" version of
>>> the runtime scripts. With a small group of committers. Ideally these
>>> people also have some scripts to check for obvious problems, such as
>>> using line continuation without setting 'cpo'.
>>>
>>> I can then pull files from that repository once tested and add them to
>>> the release repository. The group of committers could send me a list of
>>> files to pull weekly (or whenever something important was fixed). Does
>>> that sound like a good solution?
>>
>> To me absolutely yes. Obviously we will need to discuss and decide some more
>> details/workflows but i think the consensus is broad enough to start
>> getting it productive.
>> Are you fine with using vim-dev as our mailinglist for all runtime related
>> questions?
>
> Yes, I don't expect too much more discussion than what we already have.

Then we have decided that we change current maintenance model of runtimefiles to
be a collaboration one and we use 'vim-dev' for future coordination.

@Ben Fritz
You seem to have some experience with repos. Would you mind to set up one for
us? (It needs to have a mercurial interface)
I would require that we gain at least 7 individuals with commit access.
This is to somewhat grant that always someone is around "who can do the job".
Anyone who is interested to volunteer for this please speak up now.

[Ben Fritz]

On Thursday, May 17, 2012 4:37:35 PM UTC-5, Thilo Six wrote:
>
> @Ben Fritz
> You seem to have some experience with repos. Would you mind to set up one for
> us? (It needs to have a mercurial interface)
> I would require that we gain at least 7 individuals with commit access.
> This is to somewhat grant that always someone is around "who can do the job".
> Anyone who is interested to volunteer for this please speak up now.
>

Actually I have almost no experience setting up a public repository.

I have a clone of Vim on the google code project, and discovered when trying to add another committer that server-side clones on google code don't support this.

I can learn as I go if need be, but somebody else would probably be better.

To set up a clone on Google Code we'll need to create a new project, which is pretty straightforward; I'm not sure whether we can link it back to the main Vim project or not. We'd get consistency and the ability to use a username that many people already have.

I know BitBucket is the usual provider for a public Hg repository, we could go with that, but it's not as popular as Github, and I think it would require another account. Plus it looks like they actually charge money if you have >5 users with write access: https://bitbucket.org/plans

A lot of people know how to use Github. I assume Github only supports Git, so we probably don't want to go with it, but if I'm wrong about that it could also be an option.

And of course there's SourceForge.

I'd probably go with Google Code or SourceForge with the limited information I have right now, but I don't really have much of a preference; those are just the two that I've used in the past, and neither on an active project.

Any I missed?

[Ben Fritz]

On Thursday, May 17, 2012 1:07:52 PM UTC-5, Thilo Six wrote:
>
> To me absolutely yes. Obviously we will need to discuss and decide some more
> details/workflows but i think the consensus is broad enough to start getting it
> productive.
> Are you fine with using vim-dev as our mailinglist for all runtime related
> questions?
>

One person I'd like to see buy into the idea is Dr. Chip, who has been silent so far on the "team maintenance" issue. He maintains some of the most complicated plugin files in the runtime.

Chip, have you been following this thread?

[Gary Johnson]

On 2012-05-17, Thilo Six wrote:

> I would require that we gain at least 7 individuals with commit access.
> This is to somewhat grant that always someone is around "who can do the job".
> Anyone who is interested to volunteer for this please speak up now.

I am interested.

Regards,
Gary

[John Beckett]

Thilo Six wrote:
> This is to somewhat grant that always someone is around "who
> can do the job". Anyone who is interested to volunteer for
> this please speak up now.

I can help with routine matters, but I've never spent any
significant time with syntax files.

John

[Kazunobu Kuriyama]

Hello, Thilo and those who have been actively discussed the runtime file issue.

On May 18, 2012, at 6:37 AM, Thilo Six wrote:

> <snip>

>
> Then we have decided that we change current maintenance model of runtimefiles to
> be a collaboration one and we use 'vim-dev' for future coordination.

As a maintainer of a few runtime files, I have something to make sure of: Are there any changes for the current maintainers in what they observe--policy, obligations, or something similar to those, to maintain the runtime files they are in charge of?

I think summary and conclusions of the discussion would be quite helpful for those who are possibly interested in the issue.

Best regards,
K.K.

[John Beckett]

Kazunobu Kuriyama wrote:
> As a maintainer of a few runtime files, I have something to
> make sure of: Are there any changes for the current
> maintainers in what they observe--policy, obligations, or
> something similar to those, to maintain the runtime files
> they are in charge of?

Nothing is definite, but I don't think so. What would be
different (I think) is that a maintainer would send updates to
someone or something other than Bram. The group maintainers
would review the change and periodically notify Bram that
updates were available. He would then incorporate them into the
Vim distribution, presumably after his own review.

John

[Dominique Pellé]

Does anybody know if there is something that can easily be
set up for code reviews? I would like to be able to comment
on checkins in a more formal way than emails.

I've personally used Crucible
http://www.atlassian.com/software/crucible/overview
and I found that such code reviews help to catch errors, improve code quality,
learn from others comments and improve awareness of changes happening in
the source tree. I'm not saying that we should use crucible (it's not free) but
something similar.

In this page http://code.google.com/p/support/wiki/GettingStarted
I read "Source subtab -- You can elect to have non-project members
review your code."
I wonder whether this is enabled for the vim project and whether it's the
kind of review that Crucible offers.

Ideally, it should add zero burden to checkins and any checkin could be
automatically reviewed.

Regards
-- Dominique

[Thilo Six]

Hello Dominique,


Excerpt from Dominique Pell�:

> John Beckett <johnb....@gmail.com> wrote:
>
>> Kazunobu Kuriyama wrote:
>>> As a maintainer of a few runtime files, I have something to
>>> make sure of: Are there any changes for the current
>>> maintainers in what they observe--policy, obligations, or
>>> something similar to those, to maintain the runtime files
>>> they are in charge of?
>>
>> Nothing is definite, but I don't think so. What would be
>> different (I think) is that a maintainer would send updates to
>> someone or something other than Bram. The group maintainers
>> would review the change and periodically notify Bram that
>> updates were available. He would then incorporate them into the
>> Vim distribution, presumably after his own review.
>>
>> John
>
> Does anybody know if there is something that can easily be
> set up for code reviews?

I use tortoisehg for that.
http://tortoisehg.bitbucket.org/

> I would like to be able to comment
> on checkins in a more formal way than emails.

How exactly would that work?
The more sophisticated the tools get the higher the bar for participants. Email
is a low level tool which is plus.
By separating communication channels we could end up where we started.

> I've personally used Crucible
> http://www.atlassian.com/software/crucible/overview
> and I found that such code reviews help to catch errors, improve code quality,
> learn from others comments and improve awareness of changes happening in
> the source tree.

I fully agree to this.

> I'm not saying that we should use crucible (it's not free) but
> something similar.
>
> In this page http://code.google.com/p/support/wiki/GettingStarted
> I read "Source subtab -- You can elect to have non-project members
> review your code."
> I wonder whether this is enabled for the vim project and whether it's the
> kind of review that Crucible offers.
>
> Ideally, it should add zero burden to checkins and any checkin could be
> automatically reviewed.

I leave it to those who actually will have commit access to the repo to decide
which tools they use and how they want their workflow.

>
> Regards
> -- Dominique

[Thilo Six]

Hello Kazunobu and John,


Excerpt from John Beckett:

Yes thanks John. That is where we hopefully end up with.

For users nothing changes. They can pull from Brams branch and get the current
stable runtime tree.

For maintainers two important things would change:
1) In future emails with updates go to <vim-dev AT vim dot org> instead to
directly to Bram.

2) Currently each maintainer has the "master branch" of their runtimefiles at
home. That led to the unfortunate situation that a maintainer could have
overwritten previous fixes made to their files.
The important change is in future the "master branch" is the staging repo
under control of the team and you as a maintainer need to check prior to
sending updates to us, that your changes are based on what is currently in
the repo.
This is the only way that others can fix your files, too.

>
> John

[Dominique Pellé]

Thilo Six <T....@gmx.de> wrote:

>> I would like to be able to comment
>> on checkins in a more formal way than emails.
>
> How exactly would that work?

An image is worth a 1000 words. So here is a screenshot
illustrating how code reviews happen in Crucible:

http://www.atlassian.com/en/software/crucible/overview/screenshot-tour/featureItems/0/featureItems/0/imageBinary/crucible-code-review-comments.png

It shows the code changes as a colored diff by default.
By clicking on a line in the code, you can add comments (threaded).

> The more sophisticated the tools get the higher the bar for participants. Email
> is a low level tool which is plus.
> By separating communication channels we could end up where we started.

Yes, that's a risk. I'm thinking aloud here. I also like emails, but a
higher level tool for code reviews can be useful in my experience.

-- Dominique

[Jan Larres]

Dominique Pellé <dominiq...@gmail.com>:

> Thilo Six <T....@gmx.de> wrote:
>>> I would like to be able to comment
>>> on checkins in a more formal way than emails.
>>
>> How exactly would that work?
>
> An image is worth a 1000 words. So here is a screenshot
> illustrating how code reviews happen in Crucible:
>
> http://www.atlassian.com/en/software/crucible/overview/screenshot-tour/featureItems/0/featureItems/0/imageBinary/crucible-code-review-comments.png
>
> It shows the code changes as a colored diff by default.
> By clicking on a line in the code, you can add comments (threaded).

I know someone said it would be better to use Mercurial since that's
what Vim itself is using, but pretty much the exact same comment
functionality is supported in pull requests on GitHub. Maybe BitBucket
has something similar too, though, it might be worth a look.

Jan

--
-[ OpenPGP key ID: 00A0FD5F ]-
The most dangerous phrase in the language is, "We've always done it this
way."
-- Grace Hopper

[Ben Fritz]

I think this could really depend on the maintainer.

We might ask each maintainer to indicate their desired level of involvement:

1. I want to maintain all changes to my file. Please don't touch it beyond what I send you. I commit to be responsive enough for this to work.
2. I want to do all "big" changes and feature additions, but "small" changes and bugfixes can be done by the team. I will maintain my files in a way that changes will not be lost from the runtime repository.
3. I want to remain the official maintainer of the file, but the file belongs to the Vim community. Do what you will with it, I'll submit changes like any other contributor.
4. I do not wish to be the maintainer anymore. Please take it on as a group effort or find someone else.

[Ben Fritz]

I am also interested, but I know practically nothing about most of the filetypes supported by Vim.

I have a suggestion, as well.

While I agree whatever repository Bram pulls from should have a small number of people with push access, people who would review changes before pushing them, I think we should have a secondary "dev" repository with push access given to pretty much any runtime file maintainer who wants it. This repository could then be cloned by each maintainer as their developmental version control, so that submitting changes to the team for review would be as simple as an "hg push" command. The reviewers would review changesets from this "dev" repository and pull them into the "stable" repository which Bram would then pull from.

[Charles E Campbell Jr]

Hello!

I've been on vacation this week, attending my daughter's graduation from
Emory University.

I have several concerns about this proposal:

* vim.vim : there's a large block of code that I generate automatically
in syntax/vim.vim. Any changes made in that block of code, which is
marked in the syntax file, will be wiped out whenever I make an update
there.

* sh.vim : by default it supports borne shell; most (including myself)
use either Korn/Posix or Bash. In my experience there's been a lot of
narrowmindedness on this; folks use bash and complain that its not
supporting bash by default, and those using Korn/Posix complain that its
not supporting Korn/Posix by default. I've left it at Borne to
encourage people to make a choice. There is a potential issue with
maintainers imposing their view about the default.

* tex.vim : I am trying to keep out package support. There are
thousands if not tens of thousands of packages supporting various
optional features in LaTeX; it is impractical to expect vim's
syntax/tex.vim to support them all (and they may not even co-exist
properly). syntax/tex.vim is already quite large enough without lots of
package support. I've encouraged users to write
after/syntax/tex/pkgname.vim files to support their packages, and to
post them on vim.sf.net. I can foresee that we'll have maintainers
imposing their package support into syntax/tex.vim, which is a potential
problem of this approach.

Well, I need to get some gas for my lawnmower.

See you!
Chip Campbell

[Thilo Six]

Hello Ben,


Excerpt from Ben Fritz:

-- <snip> --

>>> As a maintainer of a few runtime files, I have something to
>>> make sure of: Are there any changes for the current
>>> maintainers in what they observe--policy, obligations, or
>>> something similar to those, to maintain the runtime files
>>> they are in charge of?
>>
>> Nothing is definite, but I don't think so. What would be
>> different (I think) is that a maintainer would send updates to
>> someone or something other than Bram. The group maintainers
>> would review the change and periodically notify Bram that
>> updates were available. He would then incorporate them into the
>> Vim distribution, presumably after his own review.
>>
>
> I think this could really depend on the maintainer.
>
> We might ask each maintainer to indicate their desired level of involvement:
>

Actually i haven't yet really thought about how to transition concretely.
But having an official announce and then contacting maintainers on an individual
basis seem natural.
But the announce can only happen after we are set ready to start.

> 1. I want to maintain all changes to my file. Please don't touch it beyond
> what I send you. I commit to be responsive enough for this to work.
> 2. I want to do all "big" changes and feature additions, but "small" changes
> and bugfixes can be done by the team. I will maintain my files in a way
> that changes will not be lost from the runtime repository.
> 3. I want to remain the official maintainer of the file, but the file belongs
> to the Vim community. Do what you will with it, I'll submit changes like
> any other contributor.
> 4. I do not wish to be the maintainer anymore. Please take it on as a group
> effort or find someone else.

5. We need to know who is an active member of the community. If you are still
interested in maintaining your files make sure that the email address that
is shiped with your files is up to date and functional.
If we do not hear from you within the next 3 months or the email we send
to you bounces we consider you to be MIA.
In that case we *regard your files to be without current maintainer* and
put them under the provsion of the vim community.

[Thilo Six]

Hello Dr. chip,


Excerpt from Charles E Campbell Jr:
-- <snip> --

> Hello!
>
> I've been on vacation this week, attending my daughter's graduation from
> Emory University.

Congratulations.

> I have several concerns about this proposal:
>
> * vim.vim : there's a large block of code that I generate automatically
> in syntax/vim.vim. Any changes made in that block of code, which is
> marked in the syntax file, will be wiped out whenever I make an update
> there.
>
> * sh.vim : by default it supports borne shell; most (including myself)
> use either Korn/Posix or Bash. In my experience there's been a lot of
> narrowmindedness on this; folks use bash and complain that its not
> supporting bash by default, and those using Korn/Posix complain that its
> not supporting Korn/Posix by default. I've left it at Borne to
> encourage people to make a choice. There is a potential issue with
> maintainers imposing their view about the default.
>
> * tex.vim : I am trying to keep out package support. There are
> thousands if not tens of thousands of packages supporting various
> optional features in LaTeX; it is impractical to expect vim's
> syntax/tex.vim to support them all (and they may not even co-exist
> properly). syntax/tex.vim is already quite large enough without lots of
> package support. I've encouraged users to write
> after/syntax/tex/pkgname.vim files to support their packages, and to
> post them on vim.sf.net. I can foresee that we'll have maintainers
> imposing their package support into syntax/tex.vim, which is a potential
> problem of this approach.

I can assure that your files are all well maintained. I have no reason to change
that.

>
> Well, I need to get some gas for my lawnmower.
>
> See you!
> Chip Campbell
>

[Thilo Six]

Hello Ben,


Excerpt from Ben Fritz:

-- <snip> --

>>> I would require that we gain at least 7 individuals with commit access.
>>> This is to somewhat grant that always someone is around "who can do the job".
>>> Anyone who is interested to volunteer for this please speak up now.
>>
>> I am interested.
>>
>
> I am also interested, but I know practically nothing about most of the filetypes supported by Vim.

Maybe we need to make a difference between what i call infrastructural changes
and functional changes.
Infrastructural changes are things like cpo handling, @Spell, 'b:undo_ftplugin'
and so on. These are usually straight forward and fix real bugs. They only need
knowledge about Vim.
Infrastructural changes are changes where we define policies for all runtimefiles.
Last night i spent some time on those again which i usually enjoy. IMHO we
should make it as easy as possible to get those fixed by anyone.

Functional changes are those that e.g. adapt a syntax file to a new upstream
version. These changes need a lot insight on the specific language at hand and
IMHO should only be done in cooperation with its maintainer.

It could work like this:
1) mail the maintainer, cc vim-dev
wait a reasonable time for an answer (an i won't include this patch probably
counts as answer)
2) with no answer mail the maintainer again, cc vim-dev again
3) with no answer for a reasonable time send the patch again to vim-dev. As a
convenience include links to the archived previous mails. Ask for review and
an following inclusion of the patch.

A "reasonable time" can be e.g. 4 weeks or any other period we define our selfs.

> I have a suggestion, as well.
>
> While I agree whatever repository Bram pulls from should have a small number of people with push access, people who would review changes before pushing them, I think we should have a secondary "dev" repository with push access given to pretty much any runtime file maintainer who wants it. This repository could then be cloned by each maintainer as their developmental version control, so that submitting changes to the team for review would be as simple as an "hg push" command. The reviewers would review changesets from this "dev" repository and pull them into the "stable" repository which Bram would then pull from.

Having an incomming and an outgoing repo sounds reasonable. Did you had time to
look into creating them already?

[Ernie Rael]

On 5/19/2012 2:01 AM, Thilo Six wrote:
> Hello Ben,
>
>
> Excerpt from Ben Fritz:
>
> -- <snip> --
>

>> 1. I want to maintain all changes to my file. Please don't touch it beyond
>> what I send you. I commit to be responsive enough for this to work.
>> 2. I want to do all "big" changes and feature additions, but "small" changes
>> and bugfixes can be done by the team. I will maintain my files in a way
>> that changes will not be lost from the runtime repository.
>> 3. I want to remain the official maintainer of the file, but the file belongs
>> to the Vim community. Do what you will with it, I'll submit changes like
>> any other contributor.
>> 4. I do not wish to be the maintainer anymore. Please take it on as a group
>> effort or find someone else.

(usually a lurker, but for some reason process issues...)

The above "file maintenance levels", which imply maintainer
role/responsibility for a given file, seem about right and should
satisfy Dr. Chips' concerns. (procedural question: should the maintainer
level appear in the header of the file in question? And in general what
is in a file's header? Should header have a particular format so it can
be grep'd for stats/summaries)

In some ways, 3 and 4 are almost the same; they do feel different, but I
don't really see a functional difference. If all discussions of changes
(except possibly for level 1 maintainer) occurs in a public mailing
list, what duties/responsibilities does a level 3 role have compared to
level 4? Maybe there are only two roles, along with "no maintainer".
level 3 might be useful as a "file guru" for questions, especially if
the guru no longer subscribes to vim dev.

IMO, the following should be part of the procedural description of how
this new maintenance model works and not a file maintenance level.

> 5. We need to know who is an active member of the community. If you are still
> interested in maintaining your files make sure that the email address that
> is shiped with your files is up to date and functional.
> If we do not hear from you within the next 3 months or the email we send
> to you bounces we consider you to be MIA.
> In that case we *regard your files to be without current maintainer* and
> put them under the provsion of the vim community.
>

By other mail it looks like the big procedural issue of repository
hierarchy/operation is getting close to agreement. mercurial does have
an ACL extension, http://mercurial.selenic.com/wiki/AclExtension; but
that might be overkill and/or too much maintenance. I have no experience
with it, but I thought I'd bring it up.

[Thilo Six]

Hello Ernie,


Excerpt from Ernie Rael:

-- <snip> --

> By other mail it looks like the big procedural issue of repository
> hierarchy/operation is getting close to agreement.

-- <snip> --

I might not have been explicit enough about this yet. So lets fix that. I wont
create those repos and i do not plan to become any administrator of it.
I never stepped up to rule this community but to fix bugs. A group of people
that consists only of one person is no team.
If you want to become a mate join in and lets start.

[Thilo Six]

Hello Gary,


Excerpt from Gary Johnson:

Would you be willing to set up a repository for us?

>
> Regards,
> Gary

[Gary Johnson]

On 2012-05-20, Thilo Six wrote:
> Hello Gary,
>
>
> Excerpt from Gary Johnson:
>
> > On 2012-05-17, Thilo Six wrote:
> >
> >> I would require that we gain at least 7 individuals with commit access.
> >> This is to somewhat grant that always someone is around "who can do the job".
> >> Anyone who is interested to volunteer for this please speak up now.
> >
> > I am interested.
>
> Would you be willing to set up a repository for us?

I'd be willing if I knew how, but I've never done that.

Regards,
Gary

[John Beckett]

Here are some thoughts for a group-managed repo.

It must be simple for the group managers, and for file
maintainers, and for Bram. It must also be simple for anyone to
report a problem or make a suggestion.

It should be similar to the existing Vim repo, and Mercurial
should be available just as for the Vim repo.

It should not alienate an original maintainer who is responsive
to requests but who might not want to participate in a utopian
group-managed scheme.

Flexibility is required. For example, Chip Campbell might
maintain the master copy of his plugins, and change requests
would be by email request direct to Chip, and he would send
updates to the group (not sure how).

Anyone might send a comment or update to Bram, and he could
handle that by sending it to the group for standard processing.

The Vim repo is (first URL is a 301 redirect to second):
http://vim.googlecode.com/
http://code.google.com/p/vim/

How about setting up an independent repo (not a clone) at
http://vim-runtime.googlecode.com/
Code license: GNU GPL v2

The repo would contain directories like:
vim-runtime
+--plugin
+--syntax

Using 'vim-runtime' for the root might help reduce confusion
with the 'runtime' directory in the Vim distribution.

Subject to what the original file maintainer wants, the email
address in a file would be vim...@vim.org (that could be
instead of the original maintainer, or in front of, or after,
or not present -- as wanted by the original file maintainer).

I assume the above scheme would allow approved members to
use Mercurial to push commits. Has anyone tested that to
see what happens? Each member needs a Google account?

Ben Fritz has pointed out that a second independent repo could
be created (vim-runtime-dev?) where any maintainer or other
interested party could be given access for "hg push". Then
reviewers could pull changes into the stable vim-runtime repo.
Ben mentioned that if a Google code repo is a clone of another,
the clone cannot have a second committer. So, each repo would
have to be fully independent. A second repo could happen later,
when there was a demonstrated need.

John

[John Beckett]

What directories should the group manage?

A possibility is below, although it may be too ambitious. It
shows all first-level directories under runtime, with some to
be managed by a group, and the remainder run directly by Bram.

The files in 'runtime' would NOT be part of the group repo, but
all files in each listed directory (and subdirectories) would be
part of the group repo.

runtime (group)
+--autoload
+--colors
+--compiler
+--ftplugin
+--indent
+--keymap
+--lang
+--plugin
+--syntax

runtime (Bram)
+--doc
+--icons
+--macros
+--print
+--spell
+--tools
+--tutor

John

[Ben Fritz]

On Monday, May 21, 2012 2:11:13 AM UTC-5, JohnBeckett wrote:
>
> Ben Fritz has pointed out that a second independent repo could
> be created (vim-runtime-dev?) where any maintainer or other
> interested party could be given access for "hg push". Then
> reviewers could pull changes into the stable vim-runtime repo.
> Ben mentioned that if a Google code repo is a clone of another,
> the clone cannot have a second committer. So, each repo would
> have to be fully independent. A second repo could happen later,
> when there was a demonstrated need.
>

Perhaps I was not clear. There can be any number people with "push"
access to a project. You can see contributors listed under the
"members" area on the project home page.

What you cannot have more than one committer to, is the server-side
clones listed on the same project. These are the clones created if you
click the "source" tab on the google code page, then hit the "create a
clone" button. You can see a few dozen clones on the Vim project page,
on the "source" tab, under "Clones". These clones can only have a
single contributor. If the runtime repository was a full clone of the
Vim repository, it would make sense to have it listed under this
"Clones" area...except that these clones only get a single committer,
so that's not really an option.

It would be easy enough to create a new project on Google Code which
is really a clone of the Vim repository, but the two projects would
not (as far as I know, and as far as Google Code is concerned) be
linked in any way.

[Ben Fritz]

On Monday, May 21, 2012 2:11:13 AM UTC-5, JohnBeckett wrote:

I thought about this too. I think we may need a new thread to discuss
this at some point...but of course Bram gets the final say since he's
the one pulling changes.

What files go in the repository are in large part determined by how
Bram wants to pull changes.

At a high level, I see a few options:

1. Runtime repository is independent of the Vim repository. Bram pulls
changes by updating to the latest of the runtime repository and
manually copying files into the Vim repository. This would be most
similar to the current method but doesn't provide much context to
the runtime changes in terms of change history or how it ties to
specific version of the C code. On the other hand, the history is
"clean" as Bram is used to releasing.

2. Runtime repository is actually a clone of the full Vim repository.
Bram uses pull/transplant/merge/whatever Mercurial command to just
get the changes. Developers in the runtime repository just know not
to modify the .c source files. Reviewers of the "outgoing"
repository enforce this. I like this idea best. But the history
will then show a steadily advancing main line and a potential
tangle of branches and merges for the runtime files. I don't have a
problem with that, but perhaps Bram wants a steady
one-version-after-the-next "clean" history.

3. Runtime repository is a stand-alone repository with just the
runtime files, but included as one or more subrepositories of the
main Vim repository. This way the runtime maintainers would have
full access to a repository and Bram would not need to worry about
any unauthorized changes to the C code sneaking in. But it would
require some somewhat disruptive changes to the current Vim
repository. Also, if there are runtime files Bram *doesn't* want
under team maintenance (like the stuff you list under "Bram"
above), he'd either need to trust the team not to modify them as in
option (2) above, or split the runtime into separate directories.
On the bright side, to pull changes (or revert them if needed),
Bram just needs to update one file to point to the correct version.

I'm also not sure of the level of support for subrepositories on
the various providers.

There may be other ways of doing this I've not thought of. When
deciding repository layout, unless Bram already has a strong opinion,
it might be wise to ask for advice on Mercurial's "general" mailing
list. See http://mercurial.selenic.com/wiki/MailingLists

[Ben Fritz]

On Saturday, May 19, 2012 4:16:13 PM UTC-5, Ernie Rael wrote:
> >
> >> 1. I want to maintain all changes to my file. Please don't touch it beyond
> >> what I send you. I commit to be responsive enough for this to work.
> >> 2. I want to do all "big" changes and feature additions, but "small" changes
> >> and bugfixes can be done by the team. I will maintain my files in a way
> >> that changes will not be lost from the runtime repository.
> >> 3. I want to remain the official maintainer of the file, but the file belongs
> >> to the Vim community. Do what you will with it, I'll submit changes like
> >> any other contributor.
> >> 4. I do not wish to be the maintainer anymore. Please take it on as a group
> >> effort or find someone else.
> (usually a lurker, but for some reason process issues...)
>
> The above "file maintenance levels", which imply maintainer
> role/responsibility for a given file, seem about right and should
> satisfy Dr. Chips' concerns. (procedural question: should the maintainer
> level appear in the header of the file in question? And in general what
> is in a file's header? Should header have a particular format so it can
> be grep'd for stats/summaries)
>

Yes, I think this would be a good thing to put in the file header. And
sections of a file with special considerations, like the auto-generated
section of the Vim syntax file, could have a prominent comment nearby alerting
any potential contributors.

> In some ways, 3 and 4 are almost the same; they do feel different, but I
> don't really see a functional difference. If all discussions of changes
> (except possibly for level 1 maintainer) occurs in a public mailing
> list, what duties/responsibilities does a level 3 role have compared to
> level 4? Maybe there are only two roles, along with "no maintainer".
> level 3 might be useful as a "file guru" for questions, especially if
> the guru no longer subscribes to vim dev.

I think level 3 has two major differences from level 4:

1. the official maintainer would be the "default" person to make changes from
suggestions on the list, bugfixes, etc.
2. the official maintainer would be a "file guru" as you say, at least until
the team maintainers gain the needed knowledge, which might take years if
it ever happens. Many runtime files change quite infrequently.

>
> IMO, the following should be part of the procedural description of how
> this new maintenance model works and not a file maintenance level.
> > 5. We need to know who is an active member of the community. If you are still
> > interested in maintaining your files make sure that the email address that
> > is shiped with your files is up to date and functional.
> > If we do not hear from you within the next 3 months or the email we send
> > to you bounces we consider you to be MIA.
> > In that case we *regard your files to be without current maintainer* and
> > put them under the provsion of the vim community.
> >
>

Agreed. I think level (1) is the only level appropriate for including only a
personal address in the file. Level (2) could probably list the vim_dev list
as primary contact, and the maintainer as a secondary if at all (in case the
maintainer wants to be CC'd on emails to the list). Level (3) or (4) should
probably just list vim_dev.

I think when we get this underway we'll want to contact all the maintainers
(also to give them access to the "incoming" repository if they want it), and
any who have not responded/could not be contacted in a month or so would
default to "unmaintained" unless we hear otherwise. Without a deadline I'm
pretty sure we'd have at least a few files in a state of limbo for a long time
and I'd not like to see that preventing the transition.

> By other mail it looks like the big procedural issue of repository
> hierarchy/operation is getting close to agreement. mercurial does have
> an ACL extension, http://mercurial.selenic.com/wiki/AclExtension; but
> that might be overkill and/or too much maintenance. I have no experience
> with it, but I thought I'd bring it up.

See my other email; if we use a clone of the main Vim repository, or a
subrepository of all the runtime files, this might be a good way for Bram to
restrict access to places we ought not be modifying. We might also use this to
restrict access on those files under maintenance level (1).

Again, I'm not sure about support for this extension at Google Code,
BitBucket, or SourceForge. I'm pretty sure we don't want to administer our own
server. I'm more doubtful of this one than subrepository support, though. At
least this thread says BitBucket didn't support it back in October 2011:

http://stackoverflow.com/questions/7920634/is-it-possible-to-use-mercurial-acl-extension-in-a-bitbucket-repository

I couldn't find anything on Google Code or SourceForge.

[Thilo Six]

Hello Gary,


Excerpt from Gary Johnson:

-- <snip> --

>> Would you be willing to set up a repository for us?
>
> I'd be willing if I knew how, but I've never done that.

My expertise in this filed isn't large either. But thanks for helping anyway.

[Charles Campbell]

Thomas K�hler wrote:
> Hi Thilo,
<snip>
> BTW, some files might not be changed because there is not much need.
> I last changed uil.vim and prolog.vim in 2009 to support some new
> feature available in vim (and uil.vim yesterday due to
> Dominique's patch for @Spell support), and before that, I think I
> changed them somewhen back in 2004 or so (I would have to check
> my mail archive, as I don't have the syntax files in version
> control yet).
>
>
>>>> Some statistics: I've contacted the maintainers of 15 syntax files
>>>> this weekend to add spelling checker support. The stats so far are:
>>>>
>>>> - 4 responses received from maintainers of awk, forth, ocaml, scheme (thanks!);
>>>> - 6 emails without response so far (but it's fair to wait a bit more);
>>>>
>>> That should now at least be 5:5 :-)
>>> It's always a good idea to give people a few days time to reply,
>>> especially for their private email which they might not read for
>>> a few days. When I am on vacation, it is possible that I don't
>>> read my mail for two or three weeks - because my vacation tends
>>> to be a no-internet-for-a-while time :)
>>>
>> Personal i gave people now more than 6 months to respond. Without success!
>> How long should we wait until we expect someone to be MIA?
>>
> I'd say 6 months is too long, but please try several times, as
> your first mail might have ended up in some spam filter. But if
> you don't get a response after two or three months, the runtime
> file should be considered orphaned IMHO. I think this point
> should be discussed.
>
<snip>

Perhaps there could be an automated annual email such as:

-------------------------------
Hello!

Thank you for your maintaining of <runtimefile.vim>. The Vim community
greatly appreciates your work.
This is an automated annual request: are you still willing to be a
maintainer?

Regards,
The Vim Community
-------------------------------

Actually, I'd prefer it if I only received one such emails for all the
runtime files I maintain, so idealy that <runtimefile.vim> would be
changed to

<runtimefile.vim>
<runtimefile.vim>
...

so I only needed to reply once.

Regards,
Chip Campbell

[Charles Campbell]

Benjamin R. Haskell wrote:
> <snip>
> 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.
In my experience, its often _not_ straightforward (although, admittedly,
sometimes it is). Also, I've received several patches that fixed an
issue, but would have introduced other problems.

Of course, with languages' syntax files that are mostly just keyword
lists would be straightforward to upgrade (if the upgrade only needed
more keywords, that is).

Regards,
Chip Campbell

[Thilo Six]

Hello Ben and John,

Excerpt from Ben Fritz:

-- <snip> --

>> The files in 'runtime' would NOT be part of the group repo, but
>> all files in each listed directory (and subdirectories) would be
>> part of the group repo.
>>
>> runtime (group)
>> +--autoload
>> +--colors
>> +--compiler
>> +--ftplugin
>> +--indent
>> +--keymap
>> +--lang
>> +--plugin
>> +--syntax
>>
>> runtime (Bram)
>> +--doc
>> +--icons
>> +--macros
>> +--print
>> +--spell
>> +--tools
>> +--tutor
>>
>
> I thought about this too. I think we may need a new thread to discuss
> this at some point...but of course Bram gets the final say since he's
> the one pulling changes.

I also had something like the above in mind. But i had not realized that this
also would have consequences for Brams repo. Good Point!

> What files go in the repository are in large part determined by how
> Bram wants to pull changes.
>
> At a high level, I see a few options:
>
> 1. Runtime repository is independent of the Vim repository. Bram pulls
> changes by updating to the latest of the runtime repository and
> manually copying files into the Vim repository. This would be most
> similar to the current method but doesn't provide much context to
> the runtime changes in terms of change history or how it ties to
> specific version of the C code. On the other hand, the history is
> "clean" as Bram is used to releasing.

If i had to do it i probably would use this workflow. It gives a lot control
about what is being changed. But you right we will need to ask Bram.

[Thilo Six]

Hello Charles,


Excerpt from Charles Campbell:

-- <snip> --

> Perhaps there could be an automated annual email such as:
>
> -------------------------------
> Hello!
>
> Thank you for your maintaining of <runtimefile.vim>. The Vim community
> greatly appreciates your work.
> This is an automated annual request: are you still willing to be a
> maintainer?
>
> Regards,
> The Vim Community
> -------------------------------

If understand it correctly this is similar what Debian has developed as "MIA
process". short overview here:
http://wiki.debian.org/qa.debian.org/MIATeam

> Actually, I'd prefer it if I only received one such emails for all the
> runtime files I maintain, so idealy that <runtimefile.vim> would be
> changed to

I think it is already a big step forward that we discuss these issues. I am not
strong minded in all the small details (What to send? When to send? Who is to
send? Sent at all, or use an other approach?) as long as we get some
workflow/policy to handle such things at all.

> <runtimefile.vim>
> <runtimefile.vim>
> ...
>
> so I only needed to reply once.
>
> Regards,
> Chip Campbell

[Thilo Six]

Hello John,


Excerpt from John Beckett:

I am all with you here. I just want to add a note. see below.

> Here are some thoughts for a group-managed repo.
>
> It must be simple for the group managers, and for file
> maintainers, and for Bram. It must also be simple for anyone to
> report a problem or make a suggestion.
>
> It should be similar to the existing Vim repo, and Mercurial
> should be available just as for the Vim repo.
>
> It should not alienate an original maintainer who is responsive
> to requests but who might not want to participate in a utopian
> group-managed scheme.
>
> Flexibility is required. For example, Chip Campbell might
> maintain the master copy of his plugins, and change requests
> would be by email request direct to Chip, and he would send
> updates to the group (not sure how).
>
> Anyone might send a comment or update to Bram, and he could
> handle that by sending it to the group for standard processing.
>
> The Vim repo is (first URL is a 301 redirect to second):
> http://vim.googlecode.com/
> http://code.google.com/p/vim/
>
> How about setting up an independent repo (not a clone) at
> http://vim-runtime.googlecode.com/
> Code license: GNU GPL v2

runtimefiles are all (or better they all should be) licensed under Vim licences.
This is important to note.
Uniform licening in all runtimefiles and make sure they all stay at this level
is one of the todos that our team should take care of.
Their are some more "standardizations" that i would like us to work on.

> The repo would contain directories like:
> vim-runtime
> +--plugin
> +--syntax
>
> Using 'vim-runtime' for the root might help reduce confusion
> with the 'runtime' directory in the Vim distribution.
>
> Subject to what the original file maintainer wants, the email
> address in a file would be vim...@vim.org (that could be
> instead of the original maintainer, or in front of, or after,
> or not present -- as wanted by the original file maintainer).
>
> I assume the above scheme would allow approved members to
> use Mercurial to push commits. Has anyone tested that to
> see what happens? Each member needs a Google account?
>
> Ben Fritz has pointed out that a second independent repo could
> be created (vim-runtime-dev?) where any maintainer or other
> interested party could be given access for "hg push". Then
> reviewers could pull changes into the stable vim-runtime repo.
> Ben mentioned that if a Google code repo is a clone of another,
> the clone cannot have a second committer. So, each repo would
> have to be fully independent. A second repo could happen later,
> when there was a demonstrated need.
>
> John
>

[Ben Fritz]

On Monday, May 21, 2012 12:59:47 PM UTC-5, Thilo Six wrote:
> > How about setting up an independent repo (not a clone) at
> > http://vim-runtime.googlecode.com/
> > Code license: GNU GPL v2
>
> runtimefiles are all (or better they all should be) licensed under Vim licences.

Yeah, but Google Code only has a few allowed licenses. Vim License is not one of them. Bram has dual-licensed Vim under GPL v2 and Vim License to allow putting it on Google Code.

[Bram Moolenaar]

The dual-license wasn't created for that reason :-).

I suppose it's OK to list the work as GPL, since it's the more
restrictive. Thus stays on the safe side.

--
The only way the average employee can speak to an executive is by taking a
second job as a golf caddie.
(Scott Adams - The Dilbert principle)

/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[Benjamin Fritz]

On Wed, May 23, 2012 at 1:52 PM, Bram Moolenaar <Br...@moolenaar.net> wrote:
>
> Ben Fritz wrote:
>
>> On Monday, May 21, 2012 12:59:47 PM UTC-5, Thilo Six wrote:
>> > > How about setting up an independent repo (not a clone) at
>> > > http://vim-runtime.googlecode.com/
>> > > Code license: GNU GPL v2
>> >
>> > runtimefiles are all (or better they all should be) licensed under Vim licences.
>>
>> Yeah, but Google Code only has a few allowed licenses. Vim License is
>> not one of them. Bram has dual-licensed Vim under GPL v2 and Vim
>> License to allow putting it on Google Code.
>
> The dual-license wasn't created for that reason :-).
>
> I suppose it's OK to list the work as GPL, since it's the more
> restrictive.  Thus stays on the safe side.
>

My mistake, I thought that was the reason, since it wasn't
dual-licensed to my knowledge until the Mercurial repo. Can you
enlighten us?

[James McCoy]

The old CVS repository shows that the license text was added to
runtime/doc/uganda.txt back in 2001[0] and it mentioned the GPL dual
licensing then.

[0]: http://vim.cvs.sourceforge.net/viewvc/vim/vim/runtime/doc/uganda.txt?r1=1.53&r2=1.54&
--
James
GPG Key: 4096R/331BA3DB 2011-12-05 James McCoy <jame...@jamessan.com>

[Benjamin Fritz]

I did not realize that. What are the reasons, then, for the dual
license? I feel kind of silly for not noticing until we went to the
Google Code repository. I do remember seeing a big licensing
discussion back around that time, where I learned that Google Code
only allows a limited set of licenses, GPL among them, so the fact
that Vim is dual-licensed allowed it to be in Google Code at all. I
guess the change wasn't made for that purpose though. So what were the
reasons, whenever the change was made (for curiosity's sake)?

[Tony Mechelynck]

On 24/05/12 04:29, Benjamin Fritz wrote:
[...]

> I did not realize that. What are the reasons, then, for the dual
> license? I feel kind of silly for not noticing until we went to the
> Google Code repository. I do remember seeing a big licensing
> discussion back around that time, where I learned that Google Code
> only allows a limited set of licenses, GPL among them, so the fact
> that Vim is dual-licensed allowed it to be in Google Code at all. I
> guess the change wasn't made for that purpose though. So what were the
> reasons, whenever the change was made (for curiosity's sake)?
>

The following is just a guess. Call it an educated guess if you want.

The Vim license goes far back in the history of Vim, and I think Bram
put a lot of thought (over time) into making it exactly what he wanted.
OTOH the GPL is one of a short list of popular licenses and there may
have been requests to allow licensing Vim under "some well-known
license". Too lax a license (by Bram's standards) would definitely not
have suited him as it would have "forced his hand" into things he wasn't
ready to allow. OTOH, too strict a license is acceptable as an
alternative but not as the only possibility.


Best regards,
Tony.
--
They told me you had proven it When they discovered our results
About a month before. Their hair began to curl
The proof was valid, more or less Instead of understanding it
But rather less than more. We'd run the thing through PRL.

He sent them word that we would try Don't tell a soul about all this
To pass where they had failed For it must ever be
And after we were done, to them A secret, kept from all the rest
The new proof would be mailed. Between yourself and me.

My notion was to start again
Ignoring all they'd done
We quickly turned it into code
To see if it would run.

[Thilo Six]

Hello Tony,


Excerpt from Tony Mechelynck:

-- <snip> --

> The Vim license goes far back in the history of Vim, and I think Bram
> put a lot of thought (over time) into making it exactly what he wanted.
> OTOH the GPL is one of a short list of popular licenses and there may
> have been requests to allow licensing Vim under "some well-known
> license". Too lax a license (by Bram's standards) would definitely not
> have suited him as it would have "forced his hand" into things he wasn't
> ready to allow.

The Vim license is even more relaxed then GPL.

> OTOH, too strict a license is acceptable as an
> alternative but not as the only possibility.
>
>
> Best regards,
> Tony.

--

[Ben Fritz]

On Thursday, May 24, 2012 11:37:33 AM UTC-5, Thilo Six wrote:
> Hello Tony,
>
>
> Excerpt from Tony Mechelynck:
>
> -- <snip> --
> > The Vim license goes far back in the history of Vim, and I think Bram
> > put a lot of thought (over time) into making it exactly what he wanted.
> > OTOH the GPL is one of a short list of popular licenses and there may
> > have been requests to allow licensing Vim under "some well-known
> > license". Too lax a license (by Bram's standards) would definitely not
> > have suited him as it would have "forced his hand" into things he wasn't
> > ready to allow.
>
> The Vim license is even more relaxed then GPL.
>

Right, but one that is more relaxed than the Vim license, like the MIT license for example, would not work. The Vim license requires anyone making changes to send those changes to Bram (perhaps if requested, I don't remember off the top of my head). Licensing with the MIT or Berkely-style, this requirement could not be enforced, whereas the GPL requires that the code be made available to anyone, accomplishing the goal of getting the change back to Bram.

[Thilo Six]

Hello Tony and Ben,


Excerpt from Ben Fritz:

-- <snip> --
>>> The Vim license goes far back in the history of Vim, and I think Bram
>>> put a lot of thought (over time) into making it exactly what he wanted.
>>> OTOH the GPL is one of a short list of popular licenses and there may
>>> have been requests to allow licensing Vim under "some well-known
>>> license". Too lax a license (by Bram's standards) would definitely not
>>> have suited him as it would have "forced his hand" into things he wasn't
>>> ready to allow.
>>
>> The Vim license is even more relaxed then GPL.
>>
>
> Right, but one that is more relaxed than the Vim license, like the MIT
> license for example, would not work.

Thanks for the clarification. Sorry for the noise.

[Bram Moolenaar]

There was a specific library that some Linux versions compiled Vim with,
and this library was GPL. A Vim built that way could not be
distributed, because there is a small incompatibility between GPL and
the Vim license. To solve that the dual-license method was introduced.
Richard Stallman was involved in updating the license text, thus it
should be OK for everybody.

--
Imagine a world without hypothetical situations.