On Sunday, June 2, 2013 3:58:11 AM UTC+2, Josh wrote: > On Jun 1, 2013, at 5:07 PM, Marc Weber <[email protected]> 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. 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 > > > > > > -- > > > -- > > > 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. > > > > > > > > > > +1 maybe we can get vim on GH and travis-ci! > > > > (Ps please let me know if I'm posting incorrectly to the ml)
+1 for GH -- -- 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.
