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