> scriptable: I do this all in one command. Why don't you want to maintain it?
Because every dev has to find this solution and write his/her own
script. Overkill.
> Where are you going to get comments on releases if you do release automatically?
Either changelog summary. Eg using git ( :-) ) its common to create
summaries based on changelog. We could introduce a old changelog.txt
file as well and show that as plaintext. Then you can provide human
readable summaries about the big changes dropping all the noise of
typical commit logs.
Eg doc/changelog.txt or such would be a perfect place ?
> What if repository is very large (because somebody is trying to perform a DoS
> attack)?
I'm not very sure about whether we're going to host the repos.
It is an option to "outsource" this all. Eg forward download requests to
githubs zip feature (or bitbuckets ..)...
You can download raw files from both: bitbucket, github. Thus its enough
to check for a couple of files.
Also it should be possible to impose restrictions on memory / running
time etc.
I don't see a big problem here.
> Code is stable enough in releases. Users must not expect development version to
> be stable. Vim.org must not do this either.
We can start a long discussion. Even if you have release you're causing
trouble cause your releases may not be done at the same time as other
releases depending on your work. So you still may break things.
We could start creating release schedules (like gnome, kde, .. all
have).
> > preferred: true # for your style of development. Indicates whether the
> > latest stable version should be used
> Understood nothing here. Who is using the latests stable version?
tools like VAM. The site could track the changelog. And whenever the
version bumps it could store the revision number. This could find its
way into an API which could be used by
vim-addon-manager-known-repositories or the like. Then VAM can checkout
the latest stable version instead of HEAD.
> Deprecations and support dropped by maintainer is a property of an old plugin,
> not of a new. What are these fields for? User can read about it in project
> description and VAM cannot do anything automatically when somebody said `my
> plugin superseeds foo' because this information is untrusted.
Those relations must not propagate into VAM-known-repositories.
That source should always be maintained or at least reviewed manually.
If you assume that everything is not trustable - when stop using your
computer :( its as simple as that. You can't review the kernel, Vim's C
code, the compiler which is compiling Vim (which can introduce security
wholes)...
Those relations will never be a final statements. They are hints which
may be biased by the authors. We should document that. But I still think
that they are worth it. You can manually verify all the statements.
And we can introduce "report this false statement" buttons..
> By the way, where are fields `projectPage' and `issueTracker'? If you are going
> to pull data from addon-info.json, they should be there also.
You're right. I missed those as well as "scriptid". The scriptid is
important. If it takes off (and I hope it will but I don't know) we must
find a way to be at least link compatible to www.vim.org.
projectPage, issueTracker etc will be determined by source url. Eg for
github its easy. You can also overwrite those defaults.
We'll also introduce
upstream: the VCS url where development takes place
follows: [ list of urls]
the follows key will indicate that this is a personal branch following
a foreign upstream. A use case would be a fork of snipmate-snippets.
Then you have your own upstream, but you're likely to follow the
official upstream (keeping and extending your own changes).
Marc Weber
--
You received this message from the "vim_use" 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
No comments:
Post a Comment