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.
