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
> 

-- 
Regards,
Thilo

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


-- 
You received this message from the "vim_dev" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

Reply via email to