On Monday, July 15, 2013 9:31:00 AM UTC-5, ZyX 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.
Since we're using Mercurial, and Bram wants to allow email submissions, a developer can email a "bundle" if he/she doesn't have/want access to a public repository. Then just the commits required for the fix (with some commit also in Bram's repository as a parent) need to be emailed, and he can import or pull from the bundle. I'm not altogether opposed to using patches for an initial solution, but at some point the patch needs to go into a real commit so people can review it BEFORE it gets released officially. I think using rebase risks some of the same problems that patches have, so a completely linear history may be harder to keep. But, Bram can at least keep using a linear set of tagged revisions with nothing in between, by updating the version.c version number and applying a tag after every merge he intends to publish. -- -- 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.
