Dear Bram & list, I've tried summarizing the important points and options here: http://vim-wiki.mawercer.de/wiki/vim74/devs-workflows.html
thanks for clarifying. Eventually consider adding such notes along with your notes about how to format code to the src/README.txt reference it somewhere at vim.sf.net -> developping or such. Or allow me to add such a page / lines. > I have two important reasons to want patches to be emailed to me as a > diff: > 1. It shows explicit intent to have the patches included with Vim. Yes - but quite often it happens that others find that some aspects of a patch should be improved before it should be included. > I download something from the internet I have no idea about copyright or > even who wrote it. Why do you know when recievinig an email? You can fake the sender. I could easily send this message so that it looks like having been written by you, unless you require emails to be signed or encrypted. I'm not sure about how lawyers think about this. Technically there is not a big difference. > 2. With an emailed diff we both know (the sender and I) what I'm > including exactly. When pulling from some repository I never know what > state the change is in. I sometimes get an email with "try now", but > it's not clear what "now" is. That's exactly the point. Using git you know - against which revision a patch was written for - whether it still applies cleanly to latest master/tip I think that vim-dev is the only way to make others aware of a patch. So why may using a web interface benefical ? Its because people can comment lines in source code.o Its because whenever you send a patch to the mailinglist, others may think your patch may be rewritten, thus they comment on your patch If this happens, then its no longer clear which state a patch has. Worse - to find out, you have to read a therad, and then you still don't know. Let me show you an example, how this looks like in practise: https://github.com/NixOS/nixpkgs/pull/551 [x] Due to using a template I submitted a superfluous line, and also didn't capitalize another. After getting told I sent an updated patch. The really important thing is: - you and others see exactly which bugs exist (no patch attached) and which patches exist (called pull requests) (code attached). And patches may not only be outdated just because somebody else commented, but also because you comitted some other patches upstream. Updating a pull request is as much work as: git merge master git push my-github-account my-branch --force to get the results shown at [x] Also as I said, I just don't understand how to use mercurial to efficiently have a look at patches others have written - or how to keep track and include it Let's have a second look at the pythonx patch history: - I was told that idea existed - I was old others like the idea - givenv that it prooves correct that you can use python 2.6+ and 3.0 and the same code if you take little care - I was told that plugin/*.py is bad (ZyX) From that I asked whether it makes sense to introduce startup/ directory which then could be used for ruby, perl, python, ... in the future? - I was told that polluting the global namespace is no option (ZyX) So I came up with the idea loading files as module giving them a name. - The patch broke because updates to the documentation were submitted meanwhile. Which is the status of the patch - where to get the latest version? - You said feature requests would be accepted till last Friday - Is the feature ready? I'm not sure. - So even though we used the mailinglist we know nothing. Even if I resubmitted an up to date patch - it would be harder for others to keep track of it IMHO. And of course it looks like only me having those problems - and those knowing github having replied with "+1" (I think) Marc Weber -- -- 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 [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
