sent 04:12:56 02 July 2011, Saturday
by Marc Weber:
> > Updating 'version' field, creating tags and posting this to vim.org is
> > easily 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.
Scripts can't be published? You are free to reuse mine.
> > 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 ?
All this makes delay between release made by author and release noticed by
vim.org very large. And parsing changelog looks for me like a black magic
(though it does not matter whether pkgdo.pl will post plugin to vim.org or
update the changelog, both is scriptable).
> 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.
Clone existing repositories there? Looks like you are going to do too much work.
Won't this require some sort of agreement?
> 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.
pkgdo.pl script takes working directory (or explicitely specified revision) for
tested plugin and last revision tagged release-{version} for its dependencies.
Can't you write an example situation in which I am going to break things having
something unstable in default branch? Don't forget that normal user is not
supposed to use SCM version.
> 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..
My last objection was related not to trusting these relations but to the fact
that they are not needed as a separate field if they can be used only by human.
Having these in README is enough if one wants.
> projectPage, issueTracker etc will be determined by source url. Eg for
> github its easy. You can also overwrite those defaults.
Don't forget to check that author have not disabled this feature for particular
repository. If they are overridable it will be good.
Original message:
> > Updating 'version' field, creating tags and posting this to vim.org is
> > easily 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
No comments:
Post a Comment