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.
>
> > 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.
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 -- [email protected] -- 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 ///
--
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
