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