On Mon, Jul 15, 2013 at 7:31 AM, ZyX <[email protected]> wrote: > 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.
(It's been a while since I've been an active contributor, but I still lurk here and read some of the threads.) Using a proper DVCS workflow is far superior to having one BDFL manually apply patches. That was the best we could do in the 1990s; we have better choices now. For more than a year at the day job, we've been using Github Pull Requests to manage how features are merged onto the master branch of our various repositories. We get an easy way of code reviewing, automated test results from our continuous integration server, an audit trail, and a rarely-needed mechanism for reverting. Between our various repos, our team of 15 engineers has opened (and closed) almost 1,000 pull requests. It's a successful workflow. Bitbucket also has Pull Requests [1], though I haven't worked with them. Google Code does not [2]. 1: https://confluence.atlassian.com/display/BITBUCKET/Work+with+pull+requests 2: https://code.google.com/p/support/issues/detail?id=4753 -- /George V. Reilly [email protected] Twitter: @georgevreilly http://www.georgevreilly.com/blog http://blogs.cozi.com/tech -- -- 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.
