Ben Fritz wrote: > On Friday, April 5, 2013 1:47:13 PM UTC-5, Ingo Karkat wrote: > > Already reported > > > > (https://groups.google.com/d/msg/vim_dev/H-aMlxlv8PU/48E263UbEd8J), > > probably already fixed; Bram's last runtime update is from Mar 19. > > > > I'd like to use this occasion to plead for more frequent runtime > > updates, ideally one commit per change (as with the patches), not the > > current bulk updates. It would prevent these issues, we would always > > have an up-to-date Todo list, and could effectively use Mercurial > > features like log and blame for the runtime. (I would not send out patch > > emails for these changes, though.) > > I've been sitting on a draft email for a few months now that I haven't > gotten around to finishing and sending. > > I'd like to take this one step further. The runtime files are already > largely maintained by people other than Bram. Bram, would you be > opposed to using Mercurial to PULL changes to runtime files, from a > separate public clone of the main Vim repository? Runtime file > maintainers who like, could then maintain their files directly in a > clone of the Vim repository and push to the "vim-runtime" repository > whenever they have a version ready for release. > > This would also facilitate applying "big" patches that happen to large > groups of runtime files from time to time, it would allow for wider > testing of experimental or cutting-edge runtime updates, and allow for > easy "team maintenance" of runtime files where the maintainer agrees. > > The last time I recall seeing a discussion along these lines was here: > > https://groups.google.com/d/topic/vim_dev/XGz56RXff3g/discussion > > I don't think we ever reached consensus there but there was a lot of > support for such an idea. Bram, if you might be willing to "pull" > runtime updates I think it will work quite well; we can work out the > details in a new thread. I am quite busy but it does not take much > effort to set up a public repository somewhere and periodically pull > changes from a few sources; I'd be willing to help administer a > runtime repository if nobody else steps forward. > > I'm envisioning a full clone of the main Vim repository for the > vim-runtime repository, except that a policy of "no C code changes" > would be strictly enforced. > > Obviously Bram's is the most important voice here, but does anyone > else have input on this?
The current method is working quite well. There is not much overhead for me. Only disadvantage is that you get ten updates at the same time, every two weeks or so. I don't think the version history is interesting enough that someone misses it. A new method with a repository has many new problems: - How to control access to the public repository? Only the actual maintainer must be allowed to check in changes. So we need a small group of people to maintain the access rights. - What if the maintainer can't be reached? This happens a lot. - I still need to pull for changes once in a while, it is unlikely this will happen more often than what happens now. - The version in the public respository will differ from what I have. I often reject new files or new versions of a file because it contains mistakes. - etc. I think the advantage is theoretical only. -- The difference between theory and practice, is that in theory, there is no difference between theory and practice. /// Bram Moolenaar -- b...@moolenaar.net -- 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 --- You received this message because you are subscribed to the Google Groups "vim_dev" group. To unsubscribe from this group and stop receiving emails from it, send an email to vim_dev+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
