====
> No autofetching of git/svn/hg/... Plugins there are very unstable.
That's not an issue. We could introduce a version field in addon-info.txt.
Whenever that version changes there is a new stable version. Thus you don't
push a new zip file. You just increment the number (which you do anyway) and
push and be done.
But seriously: If you write unstable code knowing that in advance a
branch should be created in any case.
We could also start "release" branches and make all tools check those
out instead.
> README-vim.org.*, not README.
Well. The idea is "do it once". And if it appears slightly different its still
a lot better compared to what we have now.
> 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).
We both agree that reviewed code is better code. And rewievs and patches are
more likely to happen if the infrastructure (any VCS) is there.
Those who don't know git/mercurial/... yet - I'd be willing to help them or
maintain a git repo for them. In the end its providing that much value that
learning it pays off. And if it doesn't - we can still keep the existing scheme
(upload a .zip file) and make the site commit changes into a git/hg/...
repository.
> Bad. Too many possible relations. If one wants to do something like this he
> should put this in README.
> Even worse: you think it superseeds, but others don't
Isn't that great? This will result in:
X supersedes Y because ..
Y supersedes X because ..
and the user will read both and know what to do. I consider this being perfect.
I can't think about performing better.
It serves the end user. Having different opinions about a topic is fine.
Contradictions are allowed. The difference is that the user is much more likely
to notice it. And that's what I care about.
> It is good to force one known format of archives, but git is an overkill.
Yes. So what to use instead? bazaar, mercurial, fossil, .. ?
The point is: git is already used most. I'm fine with using whatever other VCS
- but It will take me trice the time to maintain (at least).
I know that for sure. mercurial still gets *always* into my way - because it
does not have remote locations and simple things like that. So if you want to join
you can implement and maintain whatever you feel is best. If I'm going to
maintain it - I'll choose git.
(I'm even happier if others are willing to assist :)
lith (Tom)
==========
>> put everything "unmaintained" into git
> Isn't this self-contradictory?
No, its not. There are different unmaintained software projects. Eg snipmate
was. I patched it and added features I missed which made me much more productive.
And if the infrastructure is in place this is much more likely to happen. For many projects
there is a maintainer. But I'd say there are many projects which do no longer have one.
If you think about all users. Writing a script once importing all the plugins
can be done easily and fast. Having everyone who wants to fork a project do
this manually will cost much more total time.
> I personally think tags would be a great step forward.
I didn't talk abou it that clearly. VAM already introduce a addon-info.txt file
(JSON format). Adding a key
{ 'tag' : ['C++'] }
would be trivial. And of course this would be done.
The difference is: You don't login. You just add the tag, commit, push and be
done.
> README as plaintext
Why not? If the rendering sucks too much the plaintext view is much better than
having none. And of course we can link to github's rendering etc.
> BTW I wouldn't make vim.org too dependent on github
If bitbucket etc provide README like formats and a standand the way github does
then I'm fine to support them. The difference is that we already know that
there is a pyhton script which can parse markdown files used by github. I don't
know about the other solutions yet.
And of course supporting SVN, mercurial, .. is a must. But git is a lot faster
than svn.. So I'd be fine with forcing git on SVN users. github does provide a
SVN interface. If you really want you can use that slow and inefficient
communication SVN does.
Of course I want to support the whole world. My time is limited. Thus I can't.
And I'm pretty sure that forcing people to learn git will help them very much
compared to not using any VCS at all. Eg creating a diff is dead easy.
If you don't use it have to unpack the source a second time and run diff
manually. This all is wasting time and resources. So of course I'm not going to
force anything on anybody. See it as "I propose a more efficient way" and I
hope that people join. Most people starting using VAM sticked to it.
I don't force VAM on anybody. But people like it because it just works and gets
the job done faster than everything else which exists today.
Of course you can say "We don't care how much Vim is being used". But I do.
Cause its me patching scion, ensime, .. so that they work with Vim. The more
devs - the less work for me. Many people already switch to Emacs for whatever
reasons. And if we can reduce workload on Vim users by favoring a VCS - we
should do so - because then they have time to work on language support.
I agree - its only me caring about it - cause I'm a software developer.
And if all this only saves you 30min in your life - then you can spend some
dollars on uganda or on one.laptop.org or the like.
Let me say it in other words: There is LFS (linux from scratch) - which is a
manual telling you to download tarballs manually - and you can do everything the
way you like. However there are also strong reasons why I don't know anybody
seriously using it.
Systems like Microsoft Windows, iphone, ... they all show that having standards
makes everyone benifit so much that nobody wants to go back.
Without Bram having spend time to introduce all the completion goodness - I'd
have stopped using Vim long time ago.
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