> Excerpts from H Xu's message of Sun Dec 26 13:51:22 +0100 2010:
>> Hello Marc Weber,
>>
>> Github is able to help solve conflicts if any happens. But vim online
>> can't (unless
>> you make it). For example, after one uploads a new version, the collaborator
>> may not see the new version and uploads the new version again.(It always
>> requires a refresh after a modification of a page on vim.org to see the modified
>> page, is this a bug or something else?)
>
> So what? Then you can document the workflow that way:
> commit to master first, push to github, then use github to create a
> snapshot and upload this to www.vim.org
>
> Then no conflicts can happen.
> If you don't trust committers (and that they are able to workaround the
> issues you mention) - then you can't trust the plugin either.
>
> You can't make this fool proof. If fools maintain a package there is
> nothing what could help you. If you "own" a plugin its you adding
> collaborators. So its "opt-in" always.
>
> So I don't think we can (want) to protect against each kind of
> (upstream?) failure.
>
> We want to enhance the likelihood that plugins keep being maintained in
> the future. reducing overall noise.
>
> A maintainer switch (or adding maintainers) is always better than having
> many packages you don't know which one to use.
>
> Does this make sense to you?
>
> if packages are maintained errors can be reported and any kind of issues
> (such as upstream merge issues) can be resolved quickly.
>
> If there are two maintainers its more likely that fixes happen faster.
>
> Yours
> Marc Weber
>
Hello,
OK, I've changed my mind now. It is better to be able to add
collaborator for plugins.
Regards,
Hong Xu
2011/1/1
--
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