I would vote against any development process that uses patches, be it current one, suggested two-eye system or anything else.
The two-eye system looks reasonable, but it should be applied to PR’s (commit series requested for inclusion as a whole) and not patches: This is how we can protect from partial application of the patch and any possible problems with encoding, empty files or whatever which may happen on reviewers machines. Pulling is more predictable, mercurial is known to pull or, in rare cases, not to pull (e.g. when there are problems with plugins, enabled on server, but not on client or too old mercurial version on one side) without any possible states in between. This is how we can protect from false commit messages (like the one where I was blamed for fixing some two problems in python tests while I actually said the opposite: these two problems are the only ones that are still not fixed). Patches do not have messages attached. Messages from Bram are also known to constantly include bits of information which seem not essential for me and omitting essential ones. It does not mean they are always inessential and Bram is completely wrong: e.g. pyeval() has proved to be more useful then I though when writing it, though vim.bindeval seemed more essential. But I have more details for this reason and they are always omitted. Word about keeping context and seeing whether patch can be automatically merged was already said. This also enables normal annotate and log: with current commit messages format almost every bit of useful data is stripped from annotate and log (without -v) output: no user, shortened commit message is useless as it says only about vim version. Problem/solution is too verbose, no summary in the first line. Most developers will write this in their messages thus these features will work regardless of what is written in the merge message. This is also how one can easily see which parts were included by Bram unmodified and which ones were modified (e.g. to fit coding style). This makes me learn about what should I be aware of when writing patches. I cannot say what are the advantages for Bram regarding simplicity of the process without knowing how he does his job, but with PR’s at least problems with omitting parts of the patches and noise about wrong commit messages will go away. In addition to noise about not using DVCS as DVCS and broken development process. I cannot think of any sanely written script that may modify my patch to leave one parenthesis as-is (like it was done recently), thus I assume 1. job of applying patches is done manually and 2. manually taking patches out of the messages is hard enough to apply smaller ones by hand. Do not know about bitbucket (did not ever received PR’s here), but with github (assuming Bram does not want to switch context from mailer to browser) merging basically is “copy command from email message to shell and run it”. Reviewing the diff is “open URL (under ‘Patch links’ section) in Vim and review” (since vim is capable for opening https:// links). I hope bitbucket has something like this. -- -- 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.
