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) -- -- 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.
