> 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
--
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