Managing patches - proposal

Showing 1-27 of 27 messages
Managing patches - proposal MarcWeber 6/1/13 3:07 PM
I've been thinking about what's causing trouble to me.
Lack of workflows - lack of documentation.

http://vim.sourceforge.net/ -> download -> patch
No hint about how patches should be submitted.
No hinting about release cycles
NO hinting about how to manage vim source and patches.

I'm used to git. So let me explain how I do it for git(hub) based
projects:

1) submitting patches

  1) clone
  2) create topgit based branch which basically means having a command
  to merge upstream changes automatically. I can export this branch as a
    single patch when I feel ready. mercurial has the [pbranch] extension
    which also works perfectly fine
  3) push my patch to github, create pull request

  If I have an updated patch I just "push -f" overriding history,
  and github will tell show to the rest of world "this patch has an
  outdated version people already commented on. Click here to read all
  about the older patch

  This way its easy to react to comments (which on github can be placed
  nearby lines) as well as below the pull request description

2) reviewing patches, applying them
  way 1): curl 'patch' | git am
  way 2): add a remote location
    git add remote contributor github://the-url
    git fetch

  This way works like "hg pull other-repo-url"
  However there is one big difference:
  All branches coming from that repo are prefixed by that repo name,
  in this example contributor/master contributor/feature-X

  Thus its not me having to worry about importing foreign commits into
  my repository - because I can always can identify and drop them again,
  and distinguish them from my own branches

  People can vote for patches by commenting by "+1" (yes, it sucks, but at
  least you can vote). And for release managers it is important to see
  how many people want a patch/feature because resourcese are altways
  limited. This way it can be made transparent.

  Patches even can be labeled such as
  "bram_wants_this_patch_be_patient_till_he_has_reviewed_it"
  or
  "idea_nice_code_quality_should_be_improved"

  Then people know what to do.

This all can be documented nicely, eg that's what we did for nixos:
https://nixos.org/wiki/Contributing

So let me compare this to Vim:
Even the [developing] page stops at "how to get latest version of Vim"
not talking about how to
  - design new proposals
  - submitting them

Summary: Almost all problems would be gone by providing an official
github based mirror using git. Patches which are ready could still be
applied to mercurial.

I know there are many mercurial users on this list, please helsp my mind
change, and tell me how the I can setup a mercurial based workflow which
doesn't get into my way - which is as easy as the git based is I
described above.

If there is no alternative, would other people join and help maintaining
a git based mirror? Bram, would you even eventually consider looking
there for most up to date patches? We could still announce them on the
mailinglist.

People like ZyX should not spend their time on repating lists of patches
which should be included. Such behaviour might be a sign of lack of
infrastructure - and that infrastructure is there, we just have to use
it.

Yes, I know that you can clone repositories on google code, too.
However there is no way for people telling "I'm ready with a patch and I
want that other people discuss and comment on it", thus something like
pull requests.

Thus how many people would be interested in a github based workflow,
because it just solves quite a lot of problem getting out of the way of
devs letting them do what they should do: write code, comment code and
get things done?

So what about using an github based mirror? Who else would be interested
in it?

The mailinglist is not appropriate, because its hard to keep track of
patches/ideas
- to be discussed
- to be reviewed
- closed (merged, rejected?)

Marc Weber

links:
[pbranch]: http://mercurial.selenic.com/wiki/PatchBranchExtension
[developing]: http://vim.sourceforge.net/develop.php
Re: Managing patches - proposal Josh Hoff 6/1/13 6:58 PM
> --
> --
> 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+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

+1 maybe we can get vim on GH and travis-ci!

(Ps please let me know if I'm posting incorrectly to the ml)
Re: Managing patches - proposal Chiel92 6/2/13 3:04 AM

+1 for GH

Re: Managing patches - proposal LCD 47 6/2/13 4:56 AM
On 2 June 2013, Marc Weber <marco-...@gmx.de> wrote:
> I've been thinking about what's causing trouble to me.
> Lack of workflows - lack of documentation.
>
> http://vim.sourceforge.net/ -> download -> patch
> No hint about how patches should be submitted.
> No hinting about release cycles
> NO hinting about how to manage vim source and patches.
>
> I'm used to git.

[...]
> Summary: Almost all problems would be gone by providing an official
> github based mirror using git. Patches which are ready could still be
> applied to mercurial.
>
> I know there are many mercurial users on this list, please helsp my
> mind change, and tell me how the I can setup a mercurial based
> workflow which doesn't get into my way - which is as easy as the git
> based is I described above.

[...]
> People like ZyX should not spend their time on repating lists of
> patches which should be included. Such behaviour might be a sign of
> lack of infrastructure - and that infrastructure is there, we just
> have to use it.
[...]

    Are you trying to solve your own problem, or (your perception of)
somebody else's problem?  If the former, may I suggest the following
workflow:

(1) Get this file, bridging Mercurial to Git:

        https://github.com/felipec/git/blob/fc/master/contrib/remote-helpers/git-remote-hg.py

    Rename it git-remote-hg, make it executable, and copy it to your
    $PATH; see also:

        http://felipec.wordpress.com/2012/11/13/git-remote-hg-bzr-2/

(2) Clone the sources, then go make some coffee:

        git clone hg::https://vim.googlecode.com/hg/ vim

(3) Create a branch for each feature you're working on, then patch,
    test, push to GitHub, whatever;

(4) Update master, then rebase your branches, or merge master to them;

(5) When you have something to show, run

        git diff -r master

    and post the output to the list.

    Would that work for you?

    /lcd
Re: Managing patches - proposal Bram Moolenaar 6/2/13 5:27 AM

Marc Weber wrote:

[...]

> If there is no alternative, would other people join and help maintaining
> a git based mirror? Bram, would you even eventually consider looking
> there for most up to date patches? We could still announce them on the
> mailinglist.

I have two important reasons to want patches to be emailed to me as a
diff:

1. It shows explicit intent to have the patches included with Vim.  When
I download something from the internet I have no idea about copyright or
even who wrote it.  It would require going the way of having the author
or authors sign a form (on paper, email won't do!).  That gets messy.

2. With an emailed diff we both know (the sender and I) what I'm
including exactly.  When pulling from some repository I never know what
state the change is in.  I sometimes get an email with "try now", but
it's not clear what "now" is.

The current method worked very well for me, I don't see a reason to
change.

Note that if people want to distribute (experimental) patches to share
with other users, then using something like github works very well.


--
Never overestimate a man's ability to underestimate a woman.

 /// Bram Moolenaar -- Bram@Moolenaar.net -- http://www.Moolenaar.net   \\\
///        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\  an exciting new programming language -- http://www.Zimbu.org        ///
 \\\            help me help AIDS victims -- http://ICCF-Holland.org    ///
Re: Managing patches - proposal 依云 6/2/13 6:22 AM
On Sun, Jun 02, 2013 at 02:56:42PM +0300, LCD 47 wrote:
> [..]
>
> (1) Get this file, bridging Mercurial to Git:
>
>         https://github.com/felipec/git/blob/fc/master/contrib/remote-helpers/git-remote-hg.py
>
>     Rename it git-remote-hg, make it executable, and copy it to your
>     $PATH; see also:
>
>         http://felipec.wordpress.com/2012/11/13/git-remote-hg-bzr-2/
> [..]

FYI, I find there is already a git repo here: https://github.com/b4winckler/vim

--
Best regards,
lilydjwg

Linux Vim Python 我的博客:
http://lilydjwg.is-programmer.com/
--
A: Because it obfuscates the reading.
Q: Why is top posting so bad?
Re: Managing patches - proposal Kenichi Ito 6/2/13 6:51 AM
Vim-jp is hosting a mirror repo on github.
https://github.com/vim-jp/vim
Re: Managing patches - proposal ZyX 6/2/13 7:23 AM
> I have two important reasons to want patches to be emailed to me as a
> diff:
>
> 1. It shows explicit intent to have the patches included with Vim.  When
> I download something from the internet I have no idea about copyright or
> even who wrote it.  It would require going the way of having the author
> or authors sign a form (on paper, email won't do!).  That gets messy.

Pull request on bitbucket also has an author attached. One also won’t launch a PR if he does not think patch is ready.

(Note: I am assuming vim is moved to bitbucket and managed as usual, not what @Marc Weber suggests.)

> 2. With an emailed diff we both know (the sender and I) what I'm
> including exactly.  When pulling from some repository I never know what
> state the change is in.  I sometimes get an email with "try now", but
> it's not clear what "now" is.

If you receive a PR it means author thinks the patch is ready. There is no difference between this and emailing a patch except for the former is harder to do.

Bitbucket also allows reviewing both specific merges (by checking out specific commit URL) and the overall difference: like this https://bitbucket.org/marcinkuzminski/rhodecode/pull-request/111/pam-authentication-on-linux/diff (repository was chosen randomly).

> The current method worked very well for me, I don't see a reason to
> change.
>
> Note that if people want to distribute (experimental) patches to share
> with other users, then using something like github works very well.

There are reasons:

1. For me it would be easier to merge: 1 button + some text; I hope bitbucket does allow writing custom text in merge commits (it is not  popular enough for me to have experience with incoming bitbucket PR’s). I do not know how you apply patches from emails, but as they are non-standardized it is hard to impossible to create script that works under all circumstances. With PR merging is the only option with the only command which may do this.
2. Merging in mercurial is smarter then patching in patch program.
3. Contributors waste less time on sending PR’s.
4. You keep history as it was created, not the refined version which looses context in which patch was written thus making it sometimes impossible to say why the code looks like it looks.
5. Even though you have to invent message attached to a specific merge commit, author commit messages are left untouched. It is significant as I sometimes see things like in patch 7.3.1003 where you claimed I solved the problems which were listed as the only problems I have *not* solved.

6. (bitbucket) You can discuss specific lines in the patch. It is more convenient then copy-pasting some line and responding with it in the message.
7. (bitbucket) There is fine issue tracker here which allows marking bugs as fixed in commit messages, assigning priorities, searching *and keeping all the related things in one place*. When using todo.txt one has to search mailing list for the item described there.
8. (bitbucket) If patches are replaced with PR’s all you need to check whether patch is up-to-date is the total diff which also shows which files have conflicts and the conflicts themselves. You don’t need to download patch and try to apply it just to find out that patch is outdated. And conflict markers are better when doing conflict resolution then .rej file with failed-to-apply hunks.

AFAIR by the time this is not the only and definitely not the last attempt to convince you to use DVCS in the same fashion other people expect. Most recent I remember: https://groups.google.com/forum/?fromgroups=#!searchin/vim_dev/abuse/vim_dev/78RMC7ajGfE/pewnv_kEjJIJ (“Issue 83 in vim: the changelog indicates that bram is abusing hg making the history a pain to deal with.”).
Re: Managing patches - proposal MarcWeber 6/2/13 10:03 AM
Dear Bram & list,

I've tried summarizing the important points and options here:
http://vim-wiki.mawercer.de/wiki/vim74/devs-workflows.html

thanks for clarifying. Eventually consider adding such notes along with
your notes about how to format code to the src/README.txt reference it
somewhere at vim.sf.net -> developping or such.
Or allow me to add such a page / lines.

> I have two important reasons to want patches to be emailed to me as a
> diff:

> 1. It shows explicit intent to have the patches included with Vim.
Yes - but quite often it happens that others find that some aspects of a
patch should be improved before it should be included.

> I download something from the internet I have no idea about copyright or
> even who wrote it.
Why do you know when recievinig an email? You can fake the sender.
I could easily send this message so that it looks like having been
written by you, unless you require emails to be signed or encrypted.

I'm not sure about how lawyers think about this. Technically there is
not a big difference.

> 2. With an emailed diff we both know (the sender and I) what I'm
> including exactly.  When pulling from some repository I never know what
> state the change is in.  I sometimes get an email with "try now", but
> it's not clear what "now" is.

That's exactly the point. Using git you know
- against which revision a patch was written for
- whether it still applies cleanly to latest master/tip

I think that vim-dev is the only way to make others aware of a patch.
So why may using a web interface benefical ?
Its because people can comment lines in source code.o
Its because whenever you send a patch to the mailinglist, others may
think your patch may be rewritten, thus they comment on your patch
If this happens, then its no longer clear which state a patch has.
Worse - to find out, you have to read a therad, and then you still don't
know. Let me show you an example, how this looks like in practise:

https://github.com/NixOS/nixpkgs/pull/551 [x]
Due to using a template I submitted a superfluous line, and also didn't
capitalize another. After getting told I sent an updated patch.

The really important thing is:
- you and others see exactly which bugs exist (no patch attached)
and which patches exist (called pull requests) (code attached).


And patches may not only be outdated just because somebody else
commented, but also because you comitted some other patches upstream.
Updating a pull request is as much work as:

git merge master
git push my-github-account my-branch --force
to get the results shown at [x]

Also as I said, I just don't understand how to use mercurial to
efficiently have a look at patches others have written - or how to keep
track and include it

Let's have a second look at the pythonx patch history:
- I was told that idea existed
- I was old others like the idea - givenv that it prooves correct that
  you can use python 2.6+ and 3.0 and the same code if you take little
  care
- I was told that plugin/*.py is bad (ZyX)
  From that I asked whether it makes sense to introduce
  startup/ directory which then could be used for ruby, perl, python,
  ... in the future?
- I was told that polluting the global namespace is no option (ZyX)
  So I came up with the idea loading files as module giving them a name.
- The patch broke because updates to the documentation were submitted
  meanwhile.

Which is the status of the patch - where to get the latest version?
- You said feature requests would be accepted till last Friday
- Is the feature ready? I'm not sure.
- So even though we used the mailinglist we know nothing.

Even if I resubmitted an up to date patch - it would be harder for
others to keep track of it IMHO.

And of course it looks like only me having those problems - and those
knowing github having replied with "+1" (I think)

Marc Weber
Re: Managing patches - proposal MarcWeber 6/2/13 12:44 PM
How to continue?

Submit ideas here:
http://vim-wiki.mawercer.de/wiki/vim74/devs-workflows.html

mercurial lovers speak up and tell why you'd prefer keep using
mercurial for exchanging patches. (I'm not talking about changing the
official repository. I'm only talking about preparing patches)

I'd like to document whatever the result will be in about 2 weeks and
make it official if nobody objects.

This will not be a "you must follow this" - it will just be a
recommendation which we document officially.

Marc Weber
Re: Managing patches - proposal UncleBill 6/2/13 7:56 PM
Git/Github will be the perfect dev workflow for Vim and make more developers join  ontribution.
Re: Managing patches - proposal Ben Fritz 6/2/13 8:12 PM

I don't know whether it's common, but mailing "bundles" around might be better than patches. You can actually pull from a bundle as a source, so that not just the changes but the parent they are based off of is in there. Then Bram could rebase and collapse changesets if he wanted to, or just merge. It's not as nice as a pull request, but pretty close, and it can be done by email without Bram's worry about what "now" means because the source is attached to email.

Re: Managing patches - proposal LCD 47 6/3/13 4:25 AM
On 2 June 2013, Marc Weber <marco-...@gmx.de> wrote:
> How to continue?
>
> Submit ideas here:
> http://vim-wiki.mawercer.de/wiki/vim74/devs-workflows.html
[...]

    You mix up a number of mostly unrelated things.

(1) Mercurial and Git are virtually identical to one another in terms of
    features.  There are, of course, differences, but they are largely
    irrelevant to this discussion.

(2) GitHub is not Git, but rather a centralized Git server, plus a bug
    tracker, plus a number of nice "social" tools (other features are,
    again, irrelevant to this discussion).  Bitbucket is essentially the
    same, the main differences being that its "social" tools are less
    polished, it ofers Mercurial along with Git, and at this point it
    seems to have fewer scaling problems than GitHub:

        https://status.github.com/messages
        http://status.bitbucket.org/

(3) Currently, Mercurial is not used as a DVCS for Vim development, but
    rather as a central distribution point for the latest Vim sources,
    with the additional convenience of keeping a history of patches.  It
    could well have been CVS instead with Bram as the only commiter, and
    I beleve this is the gist of your gripe, not Mercurial itself.

    So what you ask for is not a new workflow, but a complete overhaul
of the development process.  You do try to solve somebody else's problem
after all. :)

    About GitHub now.  GitHub project started in ~2008.  Back then, some
of us have been writing code for ~20 years, and we were generally doing
fine in our unenlightened ways. :) Back then GitHub was a Rails app that
shelled out to Git, and, while they do have a number of brilliant people
working at the site now, I'd humbly submit that some of that initial
architecture is still showing through.  It's social features are really
nice these days, yes.  But is it wise to start _depending_ on them?
Maybe not.

    So, to answer your initial question: I'd personally like to see
Mercurial (or Git) used as a real DVCS (that is, people would start
submitting pull requests from their own repos).  I'd also like to see a
more functional issue tracker in place, and people actually using it.
For the social features, I don't really care though.  Things can be
coordinated just fine over a mailing list, like other projects do: see
f.i. Linux kernel, KDE, *BSD.

    As for solving the "this patch" problem, I'd say "please merge my
commit 31bed2d" is pretty much equivalent to "please include the
attached patch".

  Then again, all this rant is just my opinion, and I haven't
contributed anything useful to Vim in a while.  Not sure why you (or
anybody else) would care about it, but since you asked... *shrug*

    /lcd
Re: Managing patches - proposal LCD 47 6/3/13 4:57 AM
On 3 June 2013, LCD 47 <lcd...@gmail.com> wrote:
[...]
> architecture is still showing through.  It's social features are really
[...]

        :s/It's/Its/

    /lcd
Re: Managing patches - proposal Chiel92 6/3/13 5:03 AM
On Monday, June 3, 2013 1:25:59 PM UTC+2, LCD 47 wrote:
> On 2 June 2013, Marc Weber <marco-...@gmx.de> wrote:
>  Things can be
>
> coordinated just fine over a mailing list, like other projects do: see
>
> f.i. Linux kernel, KDE, *BSD.
>

Linux is on github though: https://github.com/torvalds/linux

Re: Managing patches - proposal Josh 6/3/13 5:21 AM

On Jun 3, 2013, at 6:25 AM, LCD 47 <lcd...@gmail.com> wrote:

> On 2 June 2013, Marc Weber <marco-...@gmx.de> wrote:
>> How to continue?
>>
>> Submit ideas here:
>> http://vim-wiki.mawercer.de/wiki/vim74/devs-workflows.html
> [...]
>
>    You mix up a number of mostly unrelated things.
>
> (1) Mercurial and Git are virtually identical to one another in terms of
>    features.  There are, of course, differences, but they are largely
>    irrelevant to this discussion.

I wouldn't say they're completely irrelevant to this discussion.  If we're discussing a shift in how development works, discussing a new dcvs might be a good idea too. +1 to git

>
> (2) GitHub is not Git, but rather a centralized Git server, plus a bug
>    tracker, plus a number of nice "social" tools (other features are,
>    again, irrelevant to this discussion).  Bitbucket is essentially the
>    same, the main differences being that its "social" tools are less
>    polished, it ofers Mercurial along with Git, and at this point it
>    seems to have fewer scaling problems than GitHub:
>
>        https://status.github.com/messages
>        http://status.bitbucket.org/
> (3) Currently, Mercurial is not used as a DVCS for Vim development, but
>    rather as a central distribution point for the latest Vim sources,
>    with the additional convenience of keeping a history of patches.  It
>    could well have been CVS instead with Bram as the only commiter, and
>    I beleve this is the gist of your gripe, not Mercurial itself.
>
>    So what you ask for is not a new workflow, but a complete overhaul
> of the development process.  You do try to solve somebody else's problem
> after all. :)
>
>    About GitHub now.  GitHub project started in ~2008.  Back then, some
> of us have been writing code for ~20 years, and we were generally doing
> fine in our unenlightened ways. :) Back then GitHub was a Rails app that
> shelled out to Git, and, while they do have a number of brilliant people
> working at the site now, I'd humbly submit that some of that initial
> architecture is still showing through.  It's social features are really
> nice these days, yes.  But is it wise to start _depending_ on them?
> Maybe not.

What social features are you talking about depending on? Issues? Pages? Something else?

>    So, to answer your initial question: I'd personally like to see
> Mercurial (or Git) used as a real DVCS (that is, people would start
> submitting pull requests from their own repos).  I'd also like to see a
> more functional issue tracker in place, and people actually using it.
> For the social features, I don't really care though.  Things can be
> coordinated just fine over a mailing list, like other projects do: see
> f.i. Linux kernel, KDE, *BSD.
>
>    As for solving the "this patch" problem, I'd say "please merge my
> commit 31bed2d" is pretty much equivalent to "please include the
> attached patch".
>

Not quite. If you push a commit up I can find it on the web ui, and send people links to it, or I can pull it from your remote repo and play with it by knowing your username and the sha/branch name. However I'd guess finding and using things through the ml would be a bit less elegant, though this is probably my inexperience with mailing lists showing through.

>  Then again, all this rant is just my opinion, and I haven't
> contributed anything useful to Vim in a while.  Not sure why you (or
> anybody else) would care about it, but since you asked... *shrug*
>
>    /lcd
>
Re: Managing patches - proposal LCD 47 6/3/13 7:18 AM
On 3 June 2013, Chiel92 <ctenb...@gmail.com> wrote:
> On Monday, June 3, 2013 1:25:59 PM UTC+2, LCD 47 wrote:
> > Things can be coordinated just fine over a mailing list, like other
> > projects do: see f.i. Linux kernel, KDE, *BSD.
>
> Linux is on github though: https://github.com/torvalds/linux

    Sure, but out of all GitHub's features only the Git server is used.
Patches, bugs, features, etc. are still discussed on the list.

    /lcd
Re: Managing patches - proposal Ben Fritz 6/3/13 7:41 AM
On Monday, June 3, 2013 7:21:04 AM UTC-5, Josh wrote:
> On Jun 3, 2013, at 6:25 AM, LCD 47 <lcd...@gmail.com> wrote:
> > (1) Mercurial and Git are virtually identical to one another in terms of
> >    features.  There are, of course, differences, but they are largely
> >    irrelevant to this discussion.
>
> I wouldn't say they're completely irrelevant to this discussion.  If we're discussing a shift in how development works, discussing a new dcvs might be a good idea too. +1 to git
>

Mercurial has an extension (hg-git) that allows it to push-pull git repositories as well as native Hg repositories. Git probably has something similar. Anybody who wants to use Git can. But I think moving the official repository to a new DVCS because some developers like it better, this soon after adopting Mercurial, would be silly at best.

Re: Managing patches - proposal LCD 47 6/3/13 7:42 AM
On 3 June 2013, Josh Hoff <random...@gmail.com> wrote:
> On Jun 3, 2013, at 6:25 AM, LCD 47 <lcd...@gmail.com> wrote:
[...]
> > About GitHub now.  GitHub project started in ~2008.  Back then, some
> > of us have been writing code for ~20 years, and we were generally
> > doing fine in our unenlightened ways. :) Back then GitHub was a
> > Rails app that shelled out to Git, and, while they do have a number
> > of brilliant people working at the site now, I'd humbly submit that
> > some of that initial architecture is still showing through.  It's
> > social features are really nice these days, yes.  But is it wise to
> > start _depending_ on them?  Maybe not.
>
> What social features are you talking about depending on? Issues?
> Pages? Something else?

    I'm referring to the beginning of this thread: issues, web-based
merges, commenting on particular lines from files, automatically marking
patches as obsolete.  These are all nice and well thought-out.  Some of
them have good equivalents outside GitHub (issues f.i. can be handled
with a bug tracker), others don't (say, commenting on a line from a
patch).  The ones that don't are ultimately locking users to GitHub.

> > So, to answer your initial question: I'd personally like to see
> > Mercurial (or Git) used as a real DVCS (that is, people would start
> > submitting pull requests from their own repos).  I'd also like to
> > see a more functional issue tracker in place, and people actually
> > using it.  For the social features, I don't really care though.
> > Things can be coordinated just fine over a mailing list, like other
> > projects do: see f.i. Linux kernel, KDE, *BSD.
> >
> > As for solving the "this patch" problem, I'd say "please merge my
> > commit 31bed2d" is pretty much equivalent to "please include the
> > attached patch".
> >
>
> Not quite. If you push a commit up I can find it on the web ui, and
> send people links to it, or I can pull it from your remote repo and
> play with it by knowing your username and the sha/branch name. However
> I'd guess finding and using things through the ml would be a bit less
> elegant, though this is probably my inexperience with mailing lists
> showing through.
[...]

    What I'm suggesting is something like this: I push a change to some
publicly available repo (on my own server, or GitHub, or whatever), then
send the link to the list, and also to Bram personally if he prefers so.
This keeps the repo decentralised, as  opposed to tied to a central
GitHub / BitBucket.  But yes, the price you have to pay for this is that
in order to find my patch you'll have to read the list (or search the
group archives).

    /lcd
Re: Managing patches - proposal LCD 47 6/3/13 7:48 AM
On 3 June 2013, Ben Fritz <fritzo...@gmail.com> wrote:
> On Monday, June 3, 2013 7:21:04 AM UTC-5, Josh wrote:
> > On Jun 3, 2013, at 6:25 AM, LCD 47 <lcd...@gmail.com> wrote:
> > > (1) Mercurial and Git are virtually identical to one another in
> > > terms of features.  There are, of course, differences, but they
> > > are largely irrelevant to this discussion.
> >
> > I wouldn't say they're completely irrelevant to this discussion.  If
> > we're discussing a shift in how development works, discussing a new
> > dcvs might be a good idea too. +1 to git
> >
>
> Mercurial has an extension (hg-git) that allows it to push-pull git
> repositories as well as native Hg repositories. Git probably has
> something similar. Anybody who wants to use Git can.

    Yup, there are bridges both ways.  They do have a few quirks, but
they generally work well.

> But I think moving the official repository to a new DVCS because some
> developers like it better, this soon after adopting Mercurial, would
> be silly at best.

    Absolutely.  As I said, the main problem is not that Mercurial
doesn't have enough feature, but rather that right now Mercurial's
features are not used.

    /lcd
Re: Managing patches - proposal ZyX 6/3/13 7:50 AM


On Jun 3, 2013 6:42 PM, "LCD 47" <lcd...@gmail.com> wrote:
>
> On 3 June 2013, Josh Hoff <random...@gmail.com> wrote:
> > On Jun 3, 2013, at 6:25 AM, LCD 47 <lcd...@gmail.com> wrote:
> [...]
> > > About GitHub now.  GitHub project started in ~2008.  Back then, some
> > > of us have been writing code for ~20 years, and we were generally
> > > doing fine in our unenlightened ways. :) Back then GitHub was a
> > > Rails app that shelled out to Git, and, while they do have a number
> > > of brilliant people working at the site now, I'd humbly submit that
> > > some of that initial architecture is still showing through.  It's
> > > social features are really nice these days, yes.  But is it wise to
> > > start _depending_ on them?  Maybe not.
> >
> > What social features are you talking about depending on? Issues?
> > Pages? Something else?
>
>     I'm referring to the beginning of this thread: issues, web-based
> merges, commenting on particular lines from files, automatically marking
> patches as obsolete.  These are all nice and well thought-out.  Some of
> them have good equivalents outside GitHub (issues f.i. can be handled
> with a bug tracker), others don't (say, commenting on a line from a
> patch).  The ones that don't are ultimately locking users to GitHub.

There are line comments in bitbucket.

> --
> --
> 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+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

Re: Managing patches - proposal Mike Williams 6/3/13 9:11 AM
On 02/06/2013 20:44, Marc Weber wrote:
> How to continue?
>
> Submit ideas here:
> http://vim-wiki.mawercer.de/wiki/vim74/devs-workflows.html

Some comments on your notes:

o git staging area.

Yep, there is no equivalent to that in mercurial, but recent versions of
mercurial have `hg commit --amend` that provides similar functionality -
it picks up subsequent changes and rolling them into the working
directory's parent changeset.

o remotes and tracking anonymous branches

The equivalent to remotes would be to add new path aliases to the repo's
.hgrc file under [paths].  See `hg help paths` for more details on that.

The simplest approach to track new heads introduced by remotes is to add
a bookmark to the new tip head after the pull.  See `hg help bookmark`
for more details.  There is also a nice introduction to them here -
http://mercurial.aragost.com/kick-start/en/bookmarks/  Bookmarks are to
mercurial as branches are to git, mercurial named branches are something
else and you don't want to use them for patch development.

o github pull requests just work.

As they do with mercurial repos in bitbucket or kiln.  The workflow is
more a function of the supporting ecosystem than because it is using
git.  And the reverse holds, using git does not require you to do the
clone, update, push, pull request dance.

o patches by email

The advantage of patches being provided by email is that list members
can review them before loading them into their local repo first.
Patches can be easily imported into a repo.  If the patch is not an
output from `hg diff` (which identifies the parent changeset) then you
can use the patch queue extension to quickly try it out and remove it
again without littering your repo with incomplete work.

And like git you can get mercurial to generate patch emails from a line
of changesets off the mainline of development, as some have started to do.

o centralised distribution

Using any dvcs (git, mercurial, bzr, fossil, etc.) usually requires one
repo to be deemed the master.  There may be a few mirrors, or ones with
known good mainline development heads that can be fallen back on.  The
fact that anyone uses mercurial for development work on vim means they
are using the d in dvcs.  They are creating local branches and merging
their local head back into default to pick up latest applied patches and
so on.  That is the definition of DVCS.

Whether changesets are communicated as pulls, bundles, or generated
diffs, they are all ways of updating other distributed repos easily.
There is nothing to stop anyone to get their clone hosted somewhere and
send links around - you don't even have to pull into your local repo to
see the changes, `hg incoming --patch` will generate a diff you can
review first.

There is nothing stopping a group of developers working on area by
themselves with their own repos, and then when they have got what they
believe is a good improvement submitting one or more patches.  If would
be up to them to handle and collapsing or rebasing as required to get it
accepted by Bram.  This is an early step towards possibly having a
trusted lieutenants workflow ;-)

> mercurial lovers speak up and tell why you'd prefer keep using
> mercurial for exchanging patches. (I'm not talking about changing the
> official repository. I'm only talking about preparing patches)
>
> I'd like to document whatever the result will be in about 2 weeks and
> make it official if nobody objects.
>
> This will not be a "you must follow this" - it will just be a
> recommendation which we document officially.
>
> Marc Weber
>


Mike
--
I have got to stop bouncing those reality checks.
Re: Managing patches - proposal MarcWeber 6/3/13 10:42 AM
Excerpts from Mike Williams's message of Mon Jun 03 18:11:34 +0200 2013:
> o remotes and tracking anonymous branches
> The equivalent to remotes would be to add new path aliases to the repo's
> .hgrc file under [paths].  See `hg help paths` for more details on that.

Example:

me: having branches A,B,C
him: having branches A,B,C

using path aliases, what exactly happens if pull from "him"?

If I use git I get new branches:

  git remote add him git:///
  git fetch him

  him/A
  him/B
  him/C

its not required to create bookmarks. How would the mercurial workflow
look like for this example ?

Is it still that hard to "remove temporary branches" again requiring
login etc - talking about bitbucket - does somebody know?

> The simplest approach to track new heads introduced by remotes is to add
> a bookmark to the new tip head after the pull.

So its me having to to bookmark him/A him/B him/C ?
and if he is happening to have 30 branchees, I have to bookmark 30
branches?

> o patches by email
> The advantage of patches being provided by email is that list members
> can review them before loading them into their local repo first.
I don't want to change this. I want developpers to tell the list about
their changes - so that they get reviewed.

The difference is that a mail to the mailinglist would eventualy no
longer contain a patch file, but an url to a git pull requset

Eg you can get the patch by appending ".patch" to a pull request url:
https://github.com/MarcWeber/vim-addon-manager/pull/120.patch

Now drop the '.patch' and you'll get to the web interface. It'll tell
you that that pull request has been closed, my last comment was "pushed
upstream".

If you comment on such a pull request you'll get notified if additional
comments happen. This way involved people will always know what's going
on. We still want to send important comments to the mailinglist.

> Patches can be easily imported into a repo.  If the patch is not an
> output from `hg diff` (which identifies the parent changeset) then you
> can use the patch queue extension to quickly try it out and remove it
> again without littering your repo with incomplete work.
Using that patch queue extension, how can I get updates from that
"incomplete work"? Using git remotes I'd do

  git fetch him

> There is nothing stopping a group of developers working on area by
> themselves with their own repos, and then when they have got what they
> believe is a good improvement submitting one or more patches.  If would
> be up to them to handle and collapsing or rebasing as required to get it
> accepted by Bram.  This is an early step towards possibly having a
> trusted lieutenants workflow ;-)
Yes, but to find out whether somebody else is working on a similar
feature, github, bitbucket might make it easier to do an initial
research.

But you're right, I'd like to see a wiki page listing all "work being
done" so people can look it up easily. However in practise this doesn't
work, but pull requests like implementations do more often :/

> (I'm not talking about changing the
> official repository. I'm only talking about preparing patches)
Me too. Well - finally it'll be Bram reviewing and merging patches.
No doubt. Everything else would be a fork of Vim.

Marc Weber
Re: Managing patches - proposal Josh 6/3/13 11:04 AM


On Monday, June 3, 2013, Ben Fritz wrote:
On Monday, June 3, 2013 7:21:04 AM UTC-5, Josh wrote:
> On Jun 3, 2013, at 6:25 AM, LCD 47 <lcd047@gmail.com> wrote:
> > (1) Mercurial and Git are virtually identical to one another in terms of
> >    features.  There are, of course, differences, but they are largely
> >    irrelevant to this discussion.
>
> I wouldn't say they're completely irrelevant to this discussion.  If we're discussing a shift in how development works, discussing a new dcvs might be a good idea too. +1 to git
>

Mercurial has an extension (hg-git) that allows it to push-pull git repositories as well as native Hg repositories. Git probably has something similar. Anybody who wants to use Git can. But I think moving the official repository to a new DVCS because some developers like it better, this soon after adopting Mercurial, would be silly at best.

I think because we're discussing a change in workflow, discussing a new dcvs is a good discussion to have, as it might affect our choice of hosting.


--
--
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@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.


Re: Managing patches - proposal Mike Williams 6/4/13 2:23 AM
On 03/06/2013 18:42, Marc Weber wrote:
> Excerpts from Mike Williams's message of Mon Jun 03 18:11:34 +0200 2013:
>> o remotes and tracking anonymous branches
>> The equivalent to remotes would be to add new path aliases to the repo's
>> .hgrc file under [paths].  See `hg help paths` for more details on that.
>
> Example:
>
> me: having branches A,B,C
> him: having branches A,B,C
>
> using path aliases, what exactly happens if pull from "him"?
>
> If I use git I get new branches:
>
>    git remote add him git:///
>    git fetch him
>
>    him/A
>    him/B
>    him/C
>
> its not required to create bookmarks. How would the mercurial workflow
> look like for this example ?

A quick 10 mins creating some example repos with divergent bookmarked
branches shows the following:

<example repo creation, bookmarking, committing and path setting elided>
F:\hg\bookmarks\marc>hg pull him
pulling from F:\hg\bookmarks\him
searching for changes
adding changesets
adding manifests
adding file changes
added 3 changesets with 3 changes to 3 files (+3 heads)
divergent bookmark A stored as A@him
divergent bookmark B stored as B@him
divergent bookmark C stored as C@him
(run 'hg heads .' to see heads, 'hg merge' to merge)

F:\hg\bookmarks\marc>hg bookmarks
    A                         1:24f97714d350
    A@him                     4:2f35d54872a3
    B                         2:60706d6db7a2
    B@him                     5:bf894f2c55f3
  * C                         3:826395aa207d
    C@him                     6:002cd688aa9d


> Is it still that hard to "remove temporary branches" again requiring
> login etc - talking about bitbucket - does somebody know?

That is a git thing - git is happy to have history rewritten.  The
mercurial approach is to not support this out of the box, but it can be
done.  To help with managing history modification mercurial supports
phases which tracks changeset visibility.  (There is ongoing development
to further simplify history rewriting but it is not available by default
yet - for those interested see
http://mercurial.selenic.com/wiki/ChangesetEvolution)

git is very much into feature branches and rebasing or deleting to keep
the history "nice".  Mercurial is more into preserving development
history with merges of feature branches back into the main line.
Bookmarks can be deleted so the namespace is kept clean (this is why you
don't use named branches for bug fixes/feature development in mercurial
- branch names are forever).

>> The simplest approach to track new heads introduced by remotes is to add
>> a bookmark to the new tip head after the pull.
>
> So its me having to to bookmark him/A him/B him/C ?
> and if he is happening to have 30 branchees, I have to bookmark 30
> branches?

With recent versions of mercurial bookmarks are included in repo updates
using pull and push.  If he is not using bookmarks then yes you would
have to bookmark them yourself if you want to track them using bookmarks
rather than trying to work out which head to use.

>> o patches by email
>> The advantage of patches being provided by email is that list members
>> can review them before loading them into their local repo first.
> I don't want to change this. I want developpers to tell the list about
> their changes - so that they get reviewed.
>
> The difference is that a mail to the mailinglist would eventualy no
> longer contain a patch file, but an url to a git pull requset
>
> Eg you can get the patch by appending ".patch" to a pull request url:
> https://github.com/MarcWeber/vim-addon-manager/pull/120.patch
>
> Now drop the '.patch' and you'll get to the web interface. It'll tell
> you that that pull request has been closed, my last comment was "pushed
> upstream".
>
> If you comment on such a pull request you'll get notified if additional
> comments happen. This way involved people will always know what's going
> on. We still want to send important comments to the mailinglist.

Makes no difference whether using mercurial or git, it's just
bike-shedding on the process.  Pros and cons for both github and
bitbucket (and kiln, and rhodecode, ...)

However you are now asking developers to do multiple steps to review a
patch.  A patch in an email means it is front and centre.  It can still
include a URL to whatever since that can make subsequent integration and
tracking in the local clone straightforward if you decide you want to
actually try the patch.

>> Patches can be easily imported into a repo.  If the patch is not an
>> output from `hg diff` (which identifies the parent changeset) then you
>> can use the patch queue extension to quickly try it out and remove it
>> again without littering your repo with incomplete work.
> Using that patch queue extension, how can I get updates from that
> "incomplete work"? Using git remotes I'd do
>
>    git fetch him

At a stab (not tested):

hg incoming --patch | hg qimport

Patch queues have pros and cons at the moment.  If you are more
confident then just normally pulling and using strip later to remove
again would work.  There are many ways to solving this problem, you just
have to know the tool.

>> There is nothing stopping a group of developers working on area by
>> themselves with their own repos, and then when they have got what they
>> believe is a good improvement submitting one or more patches.  If would
>> be up to them to handle and collapsing or rebasing as required to get it
>> accepted by Bram.  This is an early step towards possibly having a
>> trusted lieutenants workflow ;-)
> Yes, but to find out whether somebody else is working on a similar
> feature, github, bitbucket might make it easier to do an initial
> research.
>
> But you're right, I'd like to see a wiki page listing all "work being
> done" so people can look it up easily. However in practise this doesn't
> work, but pull requests like implementations do more often :/

Yep the main problem is a social organisation one, not a tool one.
Mercurial and git are both very flexible on workflows, once you have
worked out how you want to organise yourself.

>> (I'm not talking about changing the
>> official repository. I'm only talking about preparing patches)
> Me too. Well - finally it'll be Bram reviewing and merging patches.
> No doubt. Everything else would be a fork of Vim.
>
> Marc Weber
>


Mike
--
I can do what you do, you just do it better.
Re: Managing patches - proposal Josh 6/5/13 6:43 AM

On Jun 4, 2013, at 4:23 AM, Mike Williams <mike.w...@globalgraphics.com> wrote:

> On 03/06/2013 18:42, Marc Weber wrote:
>> Excerpts from Mike Williams's message of Mon Jun 03 18:11:34 +0200 2013:
>>> o remotes and tracking anonymous branches
>>> The equivalent to remotes would be to add new path aliases to the repo's
>>> .hgrc file under [paths].  See `hg help paths` for more details on that.
>>
>> Example:
>>
>> me: having branches A,B,C
>> him: having branches A,B,C
>>
>> using path aliases, what exactly happens if pull from "him"?
>>
>> If I use git I get new branches:
>>
>>   git remote add him git:///
>>   git fetch him
>>
>>   him/A
>>   him/B
>>   him/C
>>
>> its not required to create bookmarks. How would the mercurial workflow
>> look like for this example ?
>
> A quick 10 mins creating some example repos with divergent bookmarked branches shows the following:
>
> <example repo creation, bookmarking, committing and path setting elided>
> F:\hg\bookmarks\marc>hg pull him
> pulling from F:\hg\bookmarks\him
> searching for changes
> adding changesets
> adding manifests
> adding file changes
> added 3 changesets with 3 changes to 3 files (+3 heads)
> divergent bookmark A stored as A@him
> divergent bookmark B stored as B@him
> divergent bookmark C stored as C@him
> (run 'hg heads .' to see heads, 'hg merge' to merge)
>
> F:\hg\bookmarks\marc>hg bookmarks
>   A                         1:24f97714d350
>   A@him                     4:2f35d54872a3
>   B                         2:60706d6db7a2
>   B@him                     5:bf894f2c55f3
> * C                         3:826395aa207d
>   C@him                     6:002cd688aa9d
>
>
>> Is it still that hard to "remove temporary branches" again requiring
>> login etc - talking about bitbucket - does somebody know?
>
> That is a git thing - git is happy to have history rewritten.  The mercurial approach is to not support this out of the box, but it can be done.  To help with managing history modification mercurial supports phases which tracks changeset visibility.  (There is ongoing development to further simplify history rewriting but it is not available by default yet - for those interested see http://mercurial.selenic.com/wiki/ChangesetEvolution)
>
> git is very much into feature branches and rebasing or deleting to keep the history "nice".  Mercurial is more into preserving development history with merges of feature branches back into the main line. Bookmarks can be deleted so the namespace is kept clean (this is why you don't use named branches for bug fixes/feature development in mercurial - branch names are forever).
>
>>> The simplest approach to track new heads introduced by remotes is to add
>>> a bookmark to the new tip head after the pull.
>>
>> So its me having to to bookmark him/A him/B him/C ?
>> and if he is happening to have 30 branchees, I have to bookmark 30
>> branches?
>
> With recent versions of mercurial bookmarks are included in repo updates using pull and push.  If he is not using bookmarks then yes you would have to bookmark them yourself if you want to track them using bookmarks rather than trying to work out which head to use.
>
>>> o patches by email
>>> The advantage of patches being provided by email is that list members
>>> can review them before loading them into their local repo first.
>> I don't want to change this. I want developpers to tell the list about
>> their changes - so that they get reviewed.
>>
>> The difference is that a mail to the mailinglist would eventualy no
>> longer contain a patch file, but an url to a git pull requset
>>
>> Eg you can get the patch by appending ".patch" to a pull request url:
>> https://github.com/MarcWeber/vim-addon-manager/pull/120.patch
>>
>> Now drop the '.patch' and you'll get to the web interface. It'll tell
>> you that that pull request has been closed, my last comment was "pushed
>> upstream".
>>
>> If you comment on such a pull request you'll get notified if additional
>> comments happen. This way involved people will always know what's going
>> on. We still want to send important comments to the mailinglist.
>
> Makes no difference whether using mercurial or git, it's just bike-shedding on the process.  Pros and cons for both github and bitbucket (and kiln, and rhodecode, ...)
>
> However you are now asking developers to do multiple steps to review a patch.  A patch in an email means it is front and centre.  It can still include a URL to whatever since that can make subsequent integration and tracking in the local clone straightforward if you decide you want to actually try the patch.
>

Right. What would be really great would if we could support both workflows completely, and even better if we could transparently mix the two.  I bet we could with some clever use of hooks and the GitHub/bit bucket Apis.  I'll give it a shot with GitHub and post back with my findings. Anyone willing to try the same with emailing patches/integrating the bit bicker issue tracker and mercurial?

>>> Patches can be easily imported into a repo.  If the patch is not an
>>> output from `hg diff` (which identifies the parent changeset) then you
>>> can use the patch queue extension to quickly try it out and remove it
>>> again without littering your repo with incomplete work.
>> Using that patch queue extension, how can I get updates from that
>> "incomplete work"? Using git remotes I'd do
>>
>>   git fetch him
>
> At a stab (not tested):
>
> hg incoming --patch | hg qimport
>
> Patch queues have pros and cons at the moment.  If you are more confident then just normally pulling and using strip later to remove again would work.  There are many ways to solving this problem, you just have to know the tool.
>
>>> There is nothing stopping a group of developers working on area by
>>> themselves with their own repos, and then when they have got what they
>>> believe is a good improvement submitting one or more patches.  If would
>>> be up to them to handle and collapsing or rebasing as required to get it
>>> accepted by Bram.  This is an early step towards possibly having a
>>> trusted lieutenants workflow ;-)
>> Yes, but to find out whether somebody else is working on a similar
>> feature, github, bitbucket might make it easier to do an initial
>> research.
>>
>> But you're right, I'd like to see a wiki page listing all "work being
>> done" so people can look it up easily. However in practise this doesn't
>> work, but pull requests like implementations do more often :/
>
> Yep the main problem is a social organisation one, not a tool one. Mercurial and git are both very flexible on workflows, once you have worked out how you want to organise yourself.
>
>>> (I'm not talking about changing the
>>> official repository. I'm only talking about preparing patches)
>> Me too. Well - finally it'll be Bram reviewing and merging patches.
>> No doubt. Everything else would be a fork of Vim.
>>
>> Marc Weber
>
>
> Mike
> --
> I can do what you do, you just do it better.
>
> --
> --
> 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+u...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
Re: Managing patches - proposal MarcWeber 6/5/13 2:29 PM
I've written a summary here:
http://vim-wiki.mawercer.de/wiki/vim-development/development.html

At this page you can tell others about ideas and that you're working on
topics:
http://vim-wiki.mawercer.de/wiki/vim-development/recent-work.html

I hope hat this somewhat reflects the important points about this
discussion.

About git mirrors: I don't know which to prefer. jp seems to be more "up
to date" - at least today - but b4winckler mirrors all branches.

Is anybody interested in maintaining / using the bitbucket mirror?

The github mirrors will do it for me at the moment. However if others
would use it I'd try starting such mirror.

Marc Weber
More topics »