sent 19:32:53 01 July 2011, Friday
by Marc Weber:
> And the result is: Do it like google: Ask authors to register their
> upstream (git,svn,hg,..) urls and be done. The page should fetch updates
> and generate the content based on the repos.
No autofetching of git/svn/hg/... Plugins there are very unstable.
Separate fields for link to project page, issue tracker, SCM repository url (in
the format similar to used by paludis (and mercurial for repos not controlled by
hg):
{SCM}[+(ssh/https/http/...)]://domain/repo
Some examples:
hg+http://vimpluginloader.hg.sourceforge.net:8000/hgroot/vimpluginloader/pluginloader-
overlay
git://git.calculate.ru/dev/school.git
svn://overlays.gentoo.org/proj/sunrise/reviewed/
svn+https://cafarelli.fr/svn/voyageur-overlay
> The page should fetch updates
> and generate the content based on the repos. Eg those who are hosted on
> github already have a README.* file which could be used to render
> content.
README-vim.org.*, not README. Or you want to answer questions like why README is
displayed differently on vim.org rather then on bitbucket?
And something to customize README without reposting of archive (fetching from
SCM repository does not seem to be an option: not everybody has them and not
everybody is going to have them controlled by one of known SCM's).
> the doc/*.txt files could be used to render the description
> (and details).
It should be good to post a formatted version of documentation somewhere like I
do. But I don't understand your words about the description (documentation is
documentation, it is neither description nor detailed description in my
opinion).
> Its horrific that you have to download a plugin in order
> to start reading its documentation, isn't it?
That is why I post documentation to sourceforge.
// With VAM downloading a plugin in order to read its documentation is simpler.
> Of course each author should be able to assign tags to his/her plugin
Good.
> and create cross references to other plugins such as
Bad. Too many possible relations. If one wants to do something like this he
should put this in README.
> my plugin "xptemplate" -is-related-to snipmate
> my plugin "xptemplate" -is-related-to ultisnips
Very bad. It should be handled by smart tags choice of both authors, not by
xptemplate author.
> my plugin "xptemplate" supersedes XY because FOO
Even worse: you think it superseeds, but others don't. Too subjective to be
here.
> We could move all existing plugins on www.vim.org (which don't have any
> maintainers) to a github account - the way vim-scripts has done it.
What for?
It is good to force one known format of archives, but git is an overkill.
Original message:
> I've been thinking about how to optimize that user find plugins
> - and how to make it easier for devs to expose their plugins to the
> public (of course this should be better than google).
>
> And the result is: Do it like google: Ask authors to register their
> upstream (git,svn,hg,..) urls and be done. The page should fetch updates
> and generate the content based on the repos. Eg those who are hosted on
> github already have a README.* file which could be used to render
> content. the doc/*.txt files could be used to render the description
> (and details). Its horrific that you have to download a plugin in order
> to start reading its documentation, isn't it?
>
> Of course each author should be able to assign tags to his/her plugin
> and create cross references to other plugins such as
>
> my plugin "xptemplate" -is-related-to snipmate
> my plugin "xptemplate" -is-related-to ultisnips
>
> my plugin "xptemplate" supersedes XY because FOO
>
> In the end that's almost all users care about.
>
> We could move all existing plugins on www.vim.org (which don't have any
> maintainers) to a github account - the way vim-scripts has done it.
>
> Does this make sense to you?
> Do you see any major problems which such an "open" design?
>
> I'm not going to replace www.vim.org in the near future.
> However may be willing to setup an alternative site which could be good
> enough to replace www.vim.org one day if Bram agrees, funding and
> support of the page suffices and the charity aspect of Vim is honored etc.
>
> And to make this a success I'd like to allow everyone to participate.
>
> Marc Weber
No comments:
Post a Comment