72207Re: Vim development process is utterly broken (Was: Re: [patch] test98 stops when using gvim)
- Jul 15, 2013
On Jul 15, 2013 11:22 PM, "Ben Fritz" <fritzophrenic@...> wrote:
> On Monday, July 15, 2013 12:27:03 PM UTC-5, ZyX wrote:
> > > > With bundles one still needs to repost each time he has an update (common for emailed bundles and diff).
> > >
> > > I view that as a good thing. You'll need to post anyway when you make an update, otherwise nobody knows about it unless they are following your repository very closely. If Bram has 12 pull requests, he probably won't want to monitor each repository to see if anything changes. So the pull requester must post to say "updated to fix XYZ". If the changes are immediately available in the email, the maintainer has less work left to do to get them.
> > ?! You don’t need to post, you need to push to a proper branch and it will appear in PR automatically. AFAIR github does not bother notifying in this case, dunno about bitbucket, but it would be good thing to do (I mean, notify about push into PR).
> I have so far not been active enough in any open-source project to use the web-based tools for pull requests, so I admit ignorance in regard to how that works. I have so far assumed it is mostly a streamlined way (with a nice interface) to do "please pull revision abc123 from my public repository at example.com/repo to get my changes for feature X". I.e. this is something that COULD be done manually but is more efficient with the GitHub/BitBucket interface.
> I may have overlooked the idea that the maintainer should be looking at their own repository frequently enough to see that there is a pending pull request.
> Nevertheless, I do NOT want to pull a PR which I assume has been reviewed completely, only to have a few recently-pushed changes "sneak in" without review. I do NOT want to monitor for updates to the pull request to know when a fix I request is complete, I want to be told "hey, I fixed that issue you found in review, try again". I do NOT want to do the pull request, then go to publish the result, only to discover that some last-minute changes were made after my pull and need to pull again.
Normally on both sides are reasonable people. One does not say PR is finished and add a new commit after this without notification unless he knows for sure when review is done. Though there also is a problem in github: I have same reasons to expect it to notify about changes, but it does not. Hope bitbucket does, but this needs to be tested.
> Maybe it is just my ignorance showing; maybe the GitHub/BitBucket pull request concept is good enough to handle all that, but it seems like a good way to accomplish these things is a simple email to the list or maintainer saying "I updated pull request with revision abc123def to fix Jane Doe's review findings, it should be ready again".
I did the same by posting to PR if I expected other side to miss changes (normally always after review had happened due to lack of notification). There now seems to be no advantage with github.
Bitbucket has approve button in PR, but pushing new changeset does not alter approval status. It also does not notify about any changes as I run PR from one my repository to the other and as I approve myself and also push changes by myself the actual problem may be that it tries to be smart and thus changes pushed by approver just do not alter approval status. Second person is needed for the test. It did not automatically add changes to PR in my simple test though.
Github does not have support for approving PRs.
> And not everybody has or wants a GitHub account. I think email submissions are still good, for small changes at the very least.
I actually do not want it on github, I would want it on bitbucket assuming it has comparable features. But as it being not so popular I have no experience with collaborative development there and cannot evaluate pros and cons for sure. Issue tracker is much better on bitbucket.
> My point was that it should be just as easy to say "I updated to fix Jane Doe's review findings, see attached bundle". Or even "see attached patch based off version 123fe56 in the main repo". With the bundle there is less opportunity for error than the patch.--
> 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.
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.
- << Previous post in topic Next post in topic >>