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.
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.
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?
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?
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.
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.
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.
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
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:
I couldn't find anything on Google Code or SourceForge.
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.