On Monday, June 3, 2013 4:16:12 AM UTC-5, Bram Moolenaar wrote: > ZyX wrote: > > > > > On Jun 3, 2013 1:09 AM, "Bram Moolenaar" <[email protected]> wrote: > > > > > > > > > > > > Glts wrote: > > > > > > > > > On Sunday, June 2, 2013 9:30:20 PM UTC+2, Bram Moolenaar wrote: > > > > > > Christian Brabandt wrote: > > > > > > > > > > > > > Note, that latest patch I sent, does not require an extra option, is > > > > > > > rather small, makes the code much more readable (imho) and we > > > > > > > can even get rid of test89. > > > > > > > > > > > > You mean the patch you sent on May 30? > > > > > > I don't see anybody responding that they like that solution. > > > > > > > > > > This is exactly one of the reasons people are calling for a proper issue > > > > > tracker on BitBucket or similar. I remember reading one dismissive and > > > > > three favourable reactions to this idea either on vim_dev or on vim_use. > > > > > On an issue tracker these would have been impossible to overlook. > > > > > > > > > > I proposed this originally but I'm still undecided. I think it would be > > > > > good to hear a few more voices. > > > > > > > > There already is an issue tracker. > > > > > > I can hardly call what Google code has an issue tracker. It lacks basic > > > functionality. It does not even support formatting and attachments, not to > > > mention more advanced things like components. Or such a thing like finely > > > looking UI. It is not surprising most people do not want to use it. > > > > It does support attachments. > > > > > And there are no PR's here. Other issue tracker problems are tolerable, > > > absence of PR's and attachments makes it impossible to hold patches there > > > making it useless when it comes to resolving the mentioned problem. > > > > What's a PR? Problem Report? >
I think he is referring to a "pull request", so that somebody can fix an issue in a clone of the repository, and request that you pull in and merge the changes. I didn't get the impression that was something you'd want to do anyway. But maybe you'd start accepting Hg "bundle"s? Then there would be no doubt where the changes were based on and less bitrot compared to a patch (though a merge or rebase will be needed). > > I don't think that the functionality of the Issue Tracker is relevant. > > What matters is that the discussions happen on the vim-dev maillist, > > that's where the developers are. I don't see that changing no matter > > how beautiful or functional any issue tracker would be. > > GitHub's issue tracker is very pretty and has a lot of features. I haven't used BitBucket, I imagine it is similar. Google Code is not as nice, but it's certainly not the worst I've seen. And if you don't plan to use a feature, I don't think it's relevant whether it's there or not. > > For me, the main issue with Issue trackers is that I can't edit them > > with Vim. Switching to a browser and having to click around slows down > > my work. That's why I use the todo list. > One problem with the todo list, is that it is not up-to-date until you publish runtime files periodically. So sometimes it is hard to tell whether you noticed a patch or fixed a bug in a later version. And, once a bug goes away from the TODO list, nobody can find it later to see that it was an issue but has been fixed (and when). -- -- 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.
