Loading ...
Sorry, an error occurred while loading the content.

72190Re: Vim development process is utterly broken (Was: Re: [patch] test98 stops when using gvim)

Expand Messages
  • George V. Reilly
    Jul 15, 2013
    • 0 Attachment
      On Mon, Jul 15, 2013 at 7:31 AM, ZyX <zyx.vim@...> 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 george@... 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 vim_dev+unsubscribe@....
      For more options, visit https://groups.google.com/groups/opt_out.
    • Show all 27 messages in this topic