Politics

[gmarik]

TLDR: If you here to rant go on

• if you're here to help with maintenance see Help maintain Vundle  #383.

Because recent discussion in this issue turned into an off-topic it has been moved to #383.

[weynhamz]

Hey, @gmarik

I am currently maintaining fholgado's minibufexpl.vim, a bunch of legacy issus and PRs have been solved and merged into the develop branch of my fork in the last a few days, and a new version 6.5 will be released soon.

I have been using vundle for a while, it is great, I'd like to help you maintain and improve it too. I have sended two PRs (#200 and #230) for this project, I believe I can do more. I have also written a very comprehensive answer on stackoverflow.com about vim plugins management and what it should be like.

[gmarik]

Hey @techlivezheng,

Thanks for quick response and all the support!

Let's wait a bit and see how many ppl would like to join our efforts! )

[jdevera]

Hi @gmarik , I'm always trying to keep an eye on user issues, I try to help people figure out what the problem is,especially when it seems it's not a vundle problem. I'll continue to do that, hope that helps. I guess I could also classify features vs bugs, since I'm looking at all of them anyway. So yeah, sure, count me in.

I have a task in my todo list to create a test suite for vundle, but that is more involved and I can barely get any time for it. The bits I have done are not usable yet.

[gmarik]

@jdevera you've been helping since I can remember; glad to know you're sill interested!

[gmarik]

hey @techlivezheng,
regarding to #242, it looks like refactoring/feature and therefore has lower priority than Bugs.
Let's sort through bugs first, ok?

[gmarik]

So priorities:

1. sort through issues/PRs and mark as BUG/FEATURE/INVALID
2. deal with/fix all the BUGs first thing

After that maybe:

3. decide what needs to be done for Vundle v1
4. release Vundle v1.

and after that

5. refactor code (to improve maintainability)

Let me know what you think

[gmarik]

@jdevera's fork has some nice ideas https://github.com/jdevera/vundle/issues/5

[weynhamz]

@gmarik I'd love to, may I have the right to mark the issues? You can see the work I have done for @fholgado's minibufexpl issue list.

[gmarik]

@jdevera , @techlivezheng you are both collaborators now, congrats! )

[weynhamz]

That's good, thanks @gmarik.

[jdevera]

Great, thanks Cap'n

[greduan]

I would be interested in being a collaborator. :)

I already have tons of experience in the community support forums of another program (over 10,000 posts). Just like a resume of sorts. :P

- Eduan

[emberian]

I'm interested as well.

[jdevera]

Proposing #226 as "won't fix".

[greduan]

I agree as well, at one point I thought of using submodules, but then I just decided to simply ignore the /bundle directory.

You can leave it as won't fix, my two cents.

[jdevera]

Is any of you running windows? We could use some help from somebody verifying fixes and/or helping users with windows issues

[greduan]

I don't have Windows. However it is in my plans to install Windows in dual boot soon, and of course install Vim. 😉

- Eduan

[weynhamz]

2013/1/11 Eduan Lavaque [email protected]

I don't have Windows. However it is in my plans to install Windows in dual
boot soon, and of course install Vim. [image: 😉]

• Eduan

Me either, never plan to go back to M$ world after entering the Arch Linux
universe.

[jdevera]

What do you guys think of accepting #271 ? As a temporary measure, of course, until #244 is solved. I'm asking because this particular change has come up in four pull requests already. Once #244 is fixed, we can just remove the file from gitignore.

[greduan]

@jdevera Honestly, I have no idea.
I'm not sure what it's up and downs are. However, if it's a temporary measure while a more stable measure is taken, I think there's no problem.

[jdevera]

Please review this patch 3dcb0c3, which solves part of #112. I'll merge it in 5 days if there is no objection.

[bpinto]

@gmarik
I guess both maintainers are no longer maintaining the project? :(

Should we be looking for someone else?

[jdevera]

I think it would be worth having one or two more maintainers. Personally, my time availability to look at vundle issues is very limited lately because I have a surge of other side projects. I'll get more active here once I hit a bit of quiet time on those other fronts.

[jdevera]

I'm looking at pr #354 and would be great to get someone to give it a spin under windows.

[ezequielv]

I've created pr #355 with updates to pr #354 (not knowing that github would have updated #354 with those updates for me). I'd appreciate if anyone took this pr upstream (after testing it, I presume). Cheers.

[gmarik]

I'd like to get everyone here interested helping/leading Vundle.

IMO it's too much for one person to handle therefore we need a Vundle team…

@jdevera let me know what you think…

[starcraftman]

Hi. I'm not super experienced with vimscript but I'd like to help while learning. I guess I'd probably start with testing stuff and we can go from there.

[justinxreese]

@gmarik how do you feel about old PR's? I notice some as old as 3 years are still open. Do you want to draw a line somewhere or try to evaluate them all for what they are?

[jdevera]

I think there are two issues that are stopping Vundle right now, I might be wrong.

First is the lack of a collaborator with an active Windows environment where they can test PRs.

Second is the lack of the very much requested version locking. Because we encourage people to manage Vundle with Vundle, any breaking changes we make are going to break a lot of installations. We have to do this once, at least, but it should be the last time, and it should be after we have version locking, so people can lock in a particular version and if the want to live in the cutting edge, then accept the risks.

To solve the first one, I have been trying to convince every Vim user I know that Vundle is the bee's knees, even giving talks about it: http://www.slideshare.net/jacobodevera/vundle-lightning-talk for the off chance that maybe I can get someone else excited about it and maybe get more help.

For the second one, well, some things need to be changed in Vundle, and it is against @gmarik's policy of "no features" with which I disagree but profoundly respect. I used to have a fork with several additional features, but decided to shut it down to focus my energy on helping Vundle users. Vundle users are asking for features, but our hands are tied because we lack a somewhat formal team that tests those features. It'd be awesome if we can come up with such team.

I work only on Linux, so I could test all things in that platform. Unfortunately, our Windows users appear randomly to report a issue and then we never hear from them again, I wish we can get some Window user excited about the future of Vundle.

I am willing and able to write complex features, I know Vundle's code.

[starcraftman]

Hi @jdevera, I'm actually a dual booting Windows 7/Ubuntu user so I can actually test some of the Windows centric PRs/bugs/stuff. I've also been responding to some of the Windows issues too. I agree with your other point, revision locking seems essential because a lot of people want it and if we do any major changes we should allow our users to freeze at an older version just in case we break them. I think you've definitely got the right track.

I'm probably gonna start by going through the issues and trying to answer stuff that has no comments or isn't resolved front to back. I'd say we respond to support requests and then close if finished or after some date of inactivity like 2 weeks for user to respond. While looking through we should probably apply labels to what's a reproducible bug or feature request for tracking. I'm not super familiar with GitHub but I assume we'd need permission to apply labels.

Once that is done I assume (insert people deciding what's in/out Vundle) should prioritize the remaining bugs/features/PRs along milestone targets so we can track and get back to doing releases maybe? Need to know where you are going to have a working project. This may involve at the same time revisiting the roadmap you have at the bottom of the main page and seeing what we want to do. I'm all for keeping Vundle in line with your simplicity ideal but that doesn't mean there aren't some things we could add like aforementioned revision control.

As for future of Vundle post the cleanup, don't know the code well enough. I'm still a little new to VimL, just wanted to help one of my favourite plugins. Getting through the above would be a really good start. I think in the end we need to ensure stuff is getting handled, nobody likes using a project they think is dead.

Regards,
starcraft.man

[MarcWeber]

At this point I'd like to improve your awarness because BrandonMathis pointed me to this issue at
honza/vim-snippets#307 (comment).

Having had a look at what jdevera did (his lighting talk) still shows the biggest issue which happens to Vim community - and which wastes a lot of valuable resources: lack of information.

In 2009 I had trouble distributing my plugins as others authors did. So i started vim-addon-manager.
In 2010 Vundle was started (for what reason?). VAM was in working state that time. Later Shougo started NeoBundle. For what reason? He did miss VAM. jdevra did miss VAM obviously, otherwise he would have included it in his talk. When I started VAM i was prenest @ #vim almost every day praising and advertising it to an extend I already started feeling bad.

For those who don't know: What is VAM? Its vim-addon-manager. Its main principles are:
Maximize values for users. This means: Install plugins along with dependencies, try to keep everything minimal, try to tell people about outdated plugins, try to be like DNS: Assign names to plugins so that its easier communicate. The last thing caused me to start vim-addon-manager (now that NeoBundle joins we (I and ZyX) decided to turn vim-addon-manager into vim-pi which means vim package index). You'll find it at bitbucket.org/vimcommunity/vim-pi and everybody is wwelcome to contribute and make feature proposals.

VAM does also care about Windows users (because installing git @ windows takes time), eg you let my v-server fetch plugins: http://vam.mawercer.de/

This all has been working pretty well for a long time.

How to stop this "everybody spends much time on this while important issues "http://vim-wiki.mawercer.de/wiki/topic/in-which-way-does-vim-suck.html" cannot get resolved because resources are spend multiple times on the same issues?

The main issue is that vim.sf.net does not allow user contributions. There is no wiki.
The only resource have been (tips) (got removed or moved to wikia), and script list, but no easy way to help people to decide on which solution they want to use.

For this reason I started the vim-git wiki (vim-wiki.mawercer.de). You're welcome to contribute and correct things you think are wrong. You can get github colloboration access. Editing it is as easy as opening files in Vim and following links by gf. I tried to make it most simple because I felt that contributing is key. And we all know and love Vim for its text editing features, so we should allow using this (which wikia might do in some complexer ways eventually).

If you think about the future of Vundle please consider joining vim-pi. Please consider thinking about how we all can lessen the work/time to be spent on plugins maximizing value and how we can make it simpler for the community (everybody of this thread being part of it) to find the information hes looking for: A comprehensive list of ways to solve tasks in Vim, such as plugin management.

At the moment we cannot just ditch VAM/NeoBundle/Pathogen/Vundle and tell the world to to just use on plugin manager. But eventually we can try to find a common way to configure which plugins to load - that at least would work for 80% of all cases most simple plugins. Than at least we could decrease the amount of install instructions (again, see the first thread which pointed me to this one).

And then flood vim_use and vim_dev asking Bram for a common source of information at vim.sf.net so that we can document this all in a fair way. If Shougo turns NeoBundle into something which really is competitive (I think only dependencies are missing and some way to query srcipt_ids etc) - I'd be happy to give up VAM. Because there are more important things to do in life. But till this happens I invite you all in collaborating on improving the eco systems - so that this kind of mess (people not knowing about all options) impacts community less in the future.

I think that my Wiki is a starting point, if you feel differently just let me know.
I'd appreciate you having a quick glance at one of the "summarizing" pages I wrote about plugin managers to make you aware of the amount of ways there are:
http://vim-wiki.mawercer.de/wiki//topic/vim%20plugin%20managment.html

And if there are lightning talks in the future we as community should try to make it simpler for those giving lighting talks to find a more complete overview about work being done than what many vim plugins @ github propagate: Repating install instructions for at least 3 common plugin managers - this just doesn't make sense. it should be vim-pi auto generating that information. So please consider joining. I know that I'm little bit biased - because I did spend a lot of my time trying to solve this "installation issue" - and more and more I see that I failed because the eco system is failing. (otherwise VAM would have been at least mentioned in the lighting talk).

So this message is not only about telling you that VAM exists (and that I personally think that it easily outperforms vundle for many ways) - but also that its more important to me to propagate freedom of choice - and this does not exist because people still miss options.

And if you really wonder why the rating of vim-addon-manger
http://vim.sourceforge.net/scripts/script.php?script_id=2905
is at 3/1039 (despite two people me and ZyX really taking care and replying within 24h or less usually) then let me tell you that such down voting happened at vim.sf.net within 2 days - and it did not only happen to vim-addon-manager, it also happened to DrChips plugins (he even removed all plugins from vim.org that time then) and some others (I could dig up the mails on the mailinglist).

I have access to the vim.sf.net database, I could manipulate the ratings - but there is no point in doing it because they have no value, they don't indicate "outdatedness" or the like. That's another reason why I want to support a wiki which can be updated to reflect the "current state of solutions" in the vim community and which is not based on 8 year old votings (which eventually no longer apply for whatever reasons).

If you want this all to change please write to the vim-dev mailinglist and ask Bram to allow the community taking over the homepage to do what needs to be done. sourceforge in the past did not even allow sending emails (which is why you cannot reset passwords btw).

Having a nice valuable website is also important for charity reasons (after all its the ads who help people in Uganda, and Vim is charity ware).

Please don't see see this message as attack. I just want to optimize my (and your life). Life is too short to do things twice. And exactly that is happening.

I've created a new issue about the common interface idea @ vim-pi
https://bitbucket.org/vimcommunity/vim-pi/issue/91

Additional issues which exist in plugin space:
You need doc/* documentation, you need README, you need install instructions/summary @ vim.sf.net. I feel this should be written once only. But that's another story.

[starcraftman]

Hi Marc. I'm not a super Vim expert but I can explain why I use Vundle. It has an easy and straightforward interface. I'm not above complexity, I program for a living. However, when I want a tool working I don't need to spend extra time getting it working. Your VAM has tons of neat features like dependency management but all I want is my plugins installed/working.

For a new person to use Vundle all they need is what is in the quickstart. 1) Have git/curl. 2) make a git clone of Vundle. 3) Open vim and call :BundleInstall 4) Restart vim and get to work.

That's pretty damn straight forward. Total vundle documentation is around 200 lines and quite concise.

I've summarized below what I see after having spent some time on VAM.

• Your documentation is too long, too dense and the formatting seems odd (just me?) in some places. Especially the use of '>' and '<'. It is almost 2000 lines of text, I don't think you need that much. I don't want to read that, nor should I. See https://github.com/gmarik/Vundle.vim/blob/master/doc/vundle.txt.
• The documentation is confusing. I went to installation and it took me a while to figure out you wanted me to copy what was between arrows (>, <) called the "commented version" to my .vimrc. I also got confused because you had a Windows install section but the link in it is dead (http://mawercer.de/~marc/vam/index.php). I expected to have to do something for Windows prior to using that installation line in section 2.
• Your commands aren't namespaced like VAMInstall, VAMUpdate instead it is InstallAddons, RunInstallHooks, ActivateAddons. Namespacing isn't a huge complaint but most other plugins I use do it.
• Once I enabled Bundle emulation support and put in my Bundle lines and restarted. On start up I had to confirm installation of every single Bundle first pushing Y, then enter to continue install. I've got quite a few, that was painfully annoying. By comparison, BundleInstall doesn't ask for my input, doesn't stop startup and opens a small pane at left to show progress.
• At this point I stopped looking and reverted back to Vundle. I think other users just wanting stuff working might have less patience.

As to your other point on duplicated effort. Happens all the time, look at GNOME/Unity/KDE, or init services. Personally, I despise with a passion the convergence idea of GNOME3/Unity and use KDE. That doesn't mean I don't think some people might like it. I don't go on GNOME boards and tell them they are wasting their time. People have different design goals and work on software accordingly, often even duplicating large amounts of work.

Vundle aims to follow KISS from what I've seen. Accordingly, it has simple documentation, commands and format. I think the above shows VAM doesn't really follow that aiming to be a "complete solution" for plugin management. Maybe we could convert Vundle to use VAM on the backend and make it a nice front for your system but that seems like more work than just fixing a few issues and adding revision/tag support. I guess ultimately it depends on gmarik and other guys opinion's on the matter. I'm just a new comer that wants to help Vundle if I can.

[gmarik]

@MarcWeber claim "lack of information" is irrelevant since Google.

Vundle wouldn't exists if there was the "Awesomest Plugin Manager". But there wasn't and still isn't one.
Personally I appreciate your effort to create one as I'd be happy to give up all the chores related to maintenance and just use it.

So create one and let us know. And if it looks like Vundle then i'll consider my Vundle-effort not wasted.

PS: Please create separate issue(or gist) if you'd like to continue this discussion. This is the issue for people willing to help maintain Vundle. Thank you!.

[gmarik]

@starcraftman to the point! Thanks for taking time for this! )

@jdevera I'm not "no-features" guy. I'm guaranted-to-work-features guy. Every new feature means more maintenance*OSes. I'm sure you've experienced how time-consuming maintenance is for last few months with…

[gmarik]

@BrandonMathis Thanks for suggestion. Personally I don't want to get paid for what is community effort at this point.
But if you want to personally thank me with your $$ i won't stop you ;)

[gmarik]

@techlivezheng we have you as a collaborator but i'm not sure if you have had any time to help with Vundle.
Are you still interested ?

[MarcWeber]

@gmarik:
Please rethink. As I said I'm not against Vundle. I'd like to understand in
which ways collaboration makes sense.

At least this is what you might want to think about:

• does it make sense to have a command "install plugins" command for all well
  known plugin managers - so that the effort which affects every user and every
  plugin author gets less when writing install information ?
  Current situation is: Everybody tries to have at least 3 sections: for
  VAM,Vundle,Pathogen (and soon neobundle and the ruby and python install solutions)
  That's why even if you think that VAM is too complex this should be a hot topic
  for you, too.
• would it be of interest to vundle to use vim-pi pool thus that vundle can
  install plugins by name, too?
• Some plugins are not available by git (eg drchips plugin).
  VAM can checkout from archive (zip, tar, xz, ..), but eventually the fix is to
  use the new url drchip provided to mirror his plugins @vim-scripts or such?
  http://www.drchip.org/astronaut/vim/forgit.tuv
  (shoud I create a bug request at vim-scripts ?)
• should we add a vundle option to vam.mawercer.de ? (will ignore dependencies then..)

That's somewhat unrelated to VAM vs Vundle.

I've just noticed that Vundle has acommand InstallAndRequire, am I missing more
important features in this matrix (despite claiming to be most simple)?
http://vim-wiki.mawercer.de/wiki/topic/vim%20plugin%20managment.html

Thus its fine if you don't want to support VAM, but consider helping the
documentation effort at least. That should not take too much of your time but
will help us all.

You're a collaborator of https://github.com/MarcWeber/vim-git-wiki now.
the github repo is synced with vim-wiki.mawercer.de every 10 min.

@starcraftman

1. documentation is tool long
   The idea is to have .vimrc bootstrap your vim setup. Thus the minimal setup
   also contains the "git clone" commands.

2. < > in docs
   That's actually :h syntax Vim is using for help files. Due to conceal feature
   you never see those characters when reading Vim help.
   The fix would be asking github to highlight vim help syntax or to open those
   files in Vim.

3. commands don't have VAM namespace.
   Well - Ins then tab will work VAMInst are more chars to type till tab completion works
   I agree, and we have comments in code to consider changing this.

4. installation asking for confirmation, no progress.
   Progress doesn't make that much sense because you don't know in advance how
   much will be installed if there are dependencies.
   (some packages will pull dependencies ..)
   That's why we never implemented it. Confirmation can be disabled by passing
   auto_install:1

If you got many "redownloads" you eventually missed the function changing the
naming of the target paths - because VAM by default has different naming.
Eg github repos are "github-name-repo" or such.

5. Link is broken: Sry, fixed. Thanks!

6. RunInstallHooks:
   This usually is not required. I've been discussing such features for long time.
   I'm not even sure a plugin manager should provide this features.
   Usually you're done by adding a name to the list of plugins to be installed,
   such as "ActivateAddons name1 name2".

Thanks for your feedback

[MarcWeber]

Thanks for all of your feedback. VAM changed naming, auto_install default, I improved the setup example in the README. Please consider providing feedback about this, too:
https://bitbucket.org/vimcommunity/vim-pi/issue/92/checking-out-plugins-would-it-make-sense

Eg are there vundle users using any of dr chips plugins? If so how to make them available ? Make vundle checkout .zip files or upload them to a repository hosting such as vim-scripts ?

[starcraftman]

@MarcWeber I'm glad you found the feedback useful. I can't speak for gmarik but I assume we won't be doing a major refactor to use VAM/pi for a while. It does seem like a neat technology. Maybe we can look at it later once Vundle's issue pile is smaller. Also, I don't use chips plugins so can't comment on bit. Thanks for your input, it is interesting and I may revisit VAM on linux if only to see what you've done and how it works.

@jdevera If I understand gmarik correctly, he seems fine with the idea of adding revision control so long as we can test it thoroughly before merging it. Did you want to work on that? I think you made a good case for it being in as protection against plugins breaking.

@gmarik Thanks for making me collaborator, I'll try to do as I said above and get to closing down issues once I test them. I'll stick to what I said above and go through all the issues, if the original reporter doesn't reply in two weeks I'll close. Since I can edit labels now, I'll try to properly tag issues docs/bug as I go so we can better filter stuff. Also, I'll try and focus on the Windows things since not many of us around it seems.

On a related note @gmarik were you planning on making any formal roadmap/use of milestones? Or maybe we'll just be avoiding major changes until after the clean up?

Update: @jdevera I just perused the PRs. Seems #189 and #267 have PRs with this issue supported. Maybe these can help cut down the work?

[MarcWeber]

@starcraftman Thanks again for all your feedback. I've edited the README once again.

@gmarik Sorry for being impolite - its obviously not my strength. It just happens that the title of this issue proofs my point, too. "Help maintain this" ... I'd join too, - if there wasn't VAM already supporting most of things - eg "dependencies" which are still in the TODO list of vundle (for a long time) - so I feel people spending their time should know why they do it. Our time is limited - yours and that of all contributors - and we should think well about how to spend it. Its only my point of view. Splitting community does not help anybody - that's why I'd like to focus on collaboration if possible. I'm fine with others feeling/ thinking differently.

[Shougo]

@MarcWeber I think you should create another issue "for collaborating to Vundle" like neobundle. This is not the thread.

@gmarik

@Shougo any tips how to test #380 #374 ? Is this windows specific?

Yes. Thanks for testing and merging.
I have Windows environement but to test it is too difficult. I cannot test with Windows until every weekend.

@jedevela

I think there are two issues that are stopping Vundle right now, I might be wrong.
First is the lack of a collaborator with an active Windows environment where they can test PRs.
Second is the lack of the very much requested version locking.

Yes. I think Windows specific collaborating users are needed, too. Version
locking feature may be important feature. But I think it is not time time for
new features development. Current vundle has many issues. To fix bug or close
issues are important than add new features.

@jdevera I'm not "no-features" guy. I'm guaranted-to-work-features guy. Every
new feature means more maintenance*OSes. I'm sure you've experienced how
time-consuming maintenance is for last few months with…

To implement it, Vundle project needs more Vim script developers. It is not easy
feature. (Sorry, I cannot work to implement this feature)

[MarcWeber]

I'd be interested in that roadmap, too.
Let me know when you're ready.

Please take care: Depending on the "new features" redesigns have to take
place, thus you should know where you want to be before cleaning up.

Eg if you want to add "parallel install featuers" this usually requires
massive rewrites (message passing style and keeping state about
progress).

So the best order is: Define goals, then think about how to reach them.

I'd also be very interested in how some TODO items might be implemented
in Vundle, eg such as "dependencies".

vim-pi does not only try to be source for plugin managers. We want to be
good enough so that even gentoo/debian/nixos/... could derive vim
packages .. - it doesn't mean that I'll implement it.

Even if we might have different views on some items let's keep talking
please.

[MarcWeber]

Excerpts from Shougo's message of Mon Feb 10 08:56:05 +0000 2014:

@MarcWeber I think you should create another issue "for collaborating
to Vundle" like neobundle. This is not the thread.
@Shougo
I agree - but it not have reached the same people in the same time..

We all suffer from "lack of time" - and maybe Vundles ROADMAP/goals could be
ours, too. That's why we at least should collaborate on "what we want".

And people in this thread are asked to help - thus the "what we want" is
important.

[dbarnett]

The collaboration discussion isn't entirely off-topic, because if the question is "I don't have time to maintain Vundle, what do I do?", then "Stop maintaining it, we can get the same benefit another way" would be a perfectly valid answer.

There is kind of an overwhelming number of options for vim plugin managers. TBH, I'd been hearing about VAM a lot after I started work on maktaba, but was very confused by the name and thought it was the same thing as debian's vim-addon-manager for a long time. After learning more about it, I found vim-pi, the dependency management, and the addon-info.json format to be extremely powerful. These are standards that every plugin manager should have available to use, even if they're unused in some simple default experience.

vimmers are experts at shooting themselves in the foot saying "we don't need all that fancy stuff, just give me a pile of regexes that does what I want". @starcraftman You say you don't need dependency management and want a completely effortless setup, but have you considered that many of the plugins you use don't work as well or are a huge maintenance burden for the author because of a lack of dependency management, and many plugins you would love to use were never written because it would take too much work?

People have different preferences for their plugin management interface, and I don't see the wide variety of plugin managers going away. But I agree with @MarcWeber that it would be nice to standardize some of the infrastructure between plugin managers so the burden doesn't fall to plugin authors to design and document their plugins around each different plugin manager. That either means more work for pathogen/Vundle/neobundle, or some kind of common core library that they're all able to bootstrap in.

[starcraftman]

Hi @dbarnett thanks for contributing.

Just before I start, I believe you are right that in general discussing alternatives/pi is more or less central to helping Vundle so that's on topic. Making another topic would just splinter the discussion.

I definitely might have spoken a bit too hastily. I do understand where you and authors are coming from. With the current state of plugin managers there's a lot of duplication and non-standard methods/interface. They need to list multiple install methods on the front page. It would be a preferred solution if we had some simple standard dependency resolution mechanism that worked automatically. Ideally plugins could be coded without worrying about dependencies in the same way we do c/java projects and have simple ways of declaring dependencies. Then the manager uses some maven like system to pull the dependencies. Nobody wants to manually manage copies of their dependencies.

So it isn't that I don't want that at all. The problem is one of the inertia of the sitaution, the classic legacy/new, good enough/need features. At this moment right now Vundle remains widely more popularly deployed than VAM or NeoBundle or the others (my perception). Probably only Pathogen comes close. If I look up GitHub stats, Vundle has almost 4.5k stars (pathogen similar) where Neo has 591 and VAM just over 300. Now I know that's not hits, but we can assume roughly same % of people star based on hits and we see that both other alternatives are getting much less traffic/use (barring some weird behavioural changes). I know also when I Googled on plugins and poked around github most places recommended pathogen or Vundle.

Knowing this, that means a lot of folks have configs for these. Vundle crossed what I'd refer to as "good enough" threshold. It's like XP. You might not like XP. You might even despise it. But for many folks, it is "good enogh" to get the daily work done. You could even show these people Mac or Linux but why retrain when it works "good enough". So even thought gmarik hasn't updated Vundle for a while, by default the project did what it needed to. And people kept using it.

Now to your point, going forward there are 3 options. We can either duplicate work entirely or eventually go the bootstrap route or just drop Vundle and stop maintaining. The last choice is a problem, because it would really hinder your idea of having PI/dependency adopted. If Vundle gets left up and we stop updating, people will still find it through Google, still clone, still go to plugins to get them and expect Vundle support. Only difference, now no support. Humorously, this is almost exactly the XP scenario. Inertia is such a powerful law. Alternatively to just stopping, gmarik could delete the repo suddenly. That'd be a big shock to the system and I'm unconvinced VAM is quite ready to be drop in and I don't think everyone wants/knows about NeoBundle to find it. That would probably just enrage a bunch of Vim programmers.

With that said, I think it is clear we need to support Vundle in some capacity even if only to turn it into a wrapper around VAM/pi. You need to leverage exposure to generate interest in your new method or it will never take off and if we could smoothly transition, the better. Alright, well that was a long post. I think it covers the "why" we need to duplicate a bit for now. All that and frankly, you'd still have to overcome pathogen's inertia which still remains quite popular it seems. So for now, it'd be great if some people helped by looking at issues, testing PRs and overall helping.

I hope that clarifies my analysis of the situation. I'm not just a glutton for punishment wanting to duplicate everything over.

I'd like @gmarik's thoughts. This is just my POV and I admit to being relatively new to Vundle/VimL. I just want to improve the situation. As programmers, we should have an easier time enhancing Vim.

Edit: Man, that was a lot of typing.

[MarcWeber]

I'm unconvinced VAM is quite ready to be drop in
You're kidding. VAM existed and was ready before Vundle.
VAM never broke the way vundle did (because it depended on vim-scripts.org which didn't receive updates for about 3 months in the past - and was not fixed in time - and I've seen many users join #vim complaining about it). I fixed the issue at the root by patching vim.sf.net introducing an API. And I do notify and talk to related projects, eg see https://github.com/vim-scraper/vim-scraper/issues/created_by/MarcWeber?state=open

About XP: We don't have to support XP. always remember that the future will be longer than the past.

If Vundle gets left up and we stop updating, people will still find it through Google, still clone, still > go to plugins to get them and expect Vundle support
You know what? Exactly this happened to Sanders snipmate long time ago. The internet had many references to his repository - there were many hundred clones just editing one or two snippets. That's why my first task on vim-sninppets was a) improve b) split engine from snippets (which eg SirVer still didn't do AFAIK) c) create VAM-kr so that there is a way to tell people about alternatives. And these alternatives have helped many people who suddenly found out that Syntastic works better than dedicated "py checking plugins" they found by using google. Which has been one of the reasons why vim-pi (formerly vim-addon-manager-known-repositories) was introduced. Exactly for this one reason having an option to tell people that projects got replaced by others. People can still get the old code - but at least they know that they should consider switching then. There are always two choices: Live with a problem - or try to improve - I try the latter - and I invite everyone (also gmarik) to join this effort and talk about it. The only problem I see is that VAM has everything vundle has, but not the other way round. The interface is different though - which is why I want to talk about that. I'd also accept VAM & vundle being merged continuing having the sexier "vundle" name and being hosted at gmarik/Vundle.vim in the future. That's why I invite everybody who wants to think about the future of Vundle to give VAM a try. Understanding how vundles future will differ from what VAM already is will help us all. Thanks.

[starcraftman]

@MarcWeber I"ll be short now, don't want to type as much as before. Careful with the quotes, your post's format is off. Second, try not to respond emotionally to things. I can see this bothers you (because you are frustrated/care) but its not good to get so emotionally worked up over things.

I know VAM is ready in the sense that it works and has features, what I meant was more along the lines of transition. I don't think they'd all find VAM or perhaps even be interested in relearning. They might even just mirror Vundle, hehe. Let us just agree that the current situation is complicated by numerous social factors well outside the software.

I do agree, since VAM already has many of the features people would want to put in Vundle it might be worth exploring that avenue. If I understand your idea, you would want us to make a Vundle2 branch and have it basically wrap VAM with a different interface but being able to expose your nice features yes? Well maybe. See what @gmarik thinks I guess.

[gmarik]

Closing because of off-topic.
Keep going if you want to but maintenance related matter now goes to #383.

Sorry, i want to solve problems not create them.
Thanks!

[MarcWeber]

I don't want to rant, I just don't feel that its helping trying to reimplement something which does already exist. Please keep the vim-pi team updated about your ROADMAP, maybe there is (little) chance for collaboration. Meanwhile I've rewritten the vundle emulation within VAM to illustrate that it could emulate vundle if little more care would be taken which is why I cannot join vundle even if I'd love to - because I totally agree that vundle got it right designing a nice interface and having a short appealing README and documentation. Please think about and document whether you're interested in joining vim-pi (which also allows using names instead of urls) and whether you are interested in having a unified API for the most common cases. Because I want to solve problems I want resources to be spent where problems are - and vim-wiki.mawercer.de documents some - I invite everybody to join once again. @gmarik Talking solves problems, not ignoring .. But again - this is my perception.

[gmarik]

@MarcWeber there are 116 open issues right now in Vundle.
You're welcome to join the effort of resolving them…!

Thanks!

[MarcWeber]

I've found many duplicates which were not marked as such (at least 10). I was surprised that Vundle users came up with many stuff we have in VAM (multi VCS support), lazy loading, and more - but most never got merged. (lack of maintainance!) - which is why I want to merge and discuss - so that we can improve service without spending more time.

You can close all issues marked by C, by F add a "future story" document or such and add the main ideas, then you can close most of those too.

IMHO you might consider documenting branches in the README - eg what is the events branch about?
Yes - going through all issues took me about 5-6 hours

A gmariks action required
F gmarik action required - move to TODO/future story
C means close
P pull this
V would be no issue In VAM


#364: helped (lazy loading is possible with Vundle)
C #368:  GetVundle
V #367: Is not that important. Fix would be do what VAM does: encode source in directory name
      and allow user to change naming if he so desires. Thus immediate fix is
      using VAM's vundle emulation without changing default naming function
#384: dependency management - gmarik must think about how to implement this and
wether to collaborate with vim-pi.

#383: help maintain .. as I said - VAM works

V #376: Slow startup time:
  - use faster plugins 
  - use lazy loading, see #364 or VAM's readme

C #372: can be closed (file://) - it is documented in README

C #370: Not a vundle issues, can be closed
C #369: can be closed, fix is {rtp: vim}

C #386: close this

A #361: 
A #355: compatibility issue with newer Vim ?
C #346: push updates to users - fix is subscribe to vim_use IMHO - thus probably can be closed
C #343: can be closed, :BundleInstall will never edit the .vimrc for many reasons I guess
A #334: 

C #333: its not a vundle bug, have a "help" file or such and document this pitfall
C #6 dup of #333

#332: more info required
#330: shell encoding - I don't care (unimportant to me)
C #328: dup of #335


A #323: (add to TODO or say won't fix)


C #348: duplicate of 356
C #327: dup of #356, #348
A #304: won't fix close or merge

#317 too complicated - won't look at it

V #302
V #300, #244 (rtp order)

C #299 (if I'm correct that ' was missing)
A #298 (TODO item or won't fix)
C #259

AF #292 (lock) Move to todo turn it into 'future story to think about'
AF #253
F  #35
F  #189

F #226 submodule support
F #198 (subtree proposal)
F #145 (dup of #116 or related)

F #144 (boottstrapping code in README)

C #59 (duplicate of #144)

# shallow clones
C #29, #28 (dup of 335) #252 (pull request)
V #335: requesting --depth 1 take care about google git accounts, fix is use VAM

F #26 make command-t: Hard question. No easy answer for VAM either.

#288 Too much effort to test - at VAM we created our own shell abstraction/quoting
F #286

F #56 (after checking out bundle source/load/append bundle lines from that bundle)
      Thus this is about dependencies

A #281 unsure  about this (you know it better than I do)

A #275 /\/\cdocument as known issue and close

#274 dropping spaces: unsure how important it is

C #269 old, not a vundle issue

A #268 Do you want vundle to use mercurial?

F #262 Do you want to support this? (checking out from git by zip or such like VAM ?)

C #254 close, user should reopen

C #236 Can be closed - how to omit a plugin from being loaded is trivial and not Vundles task

V #234 think about whether you want to support this

CV #125 Doesn't make sense, can be closed

CF #48 checkout changes of git repositries dup of #367 in some way

2 year old:
C #131 improve startup speed (missing benchmarks thus close)
C #117 (dup of #131)

#187 status unkown? parts seem to be working

#242 unsure

C #239 location of git, let $PATH solution has been given which is most simple and works for almost all use cases

C #229 its not a vundle issue

A #109 (use dictionaries, avoid reparsing)


F #221 search eg collaborate with vim-pi

C #219 customize signs, (there is a solution)

C #213 (one year, no reply), maybe quoting issue

C #207 Ignore mercurial repositories (this should work, correct)
C #24 (does work)

C #205 vim-latex (solutions given)

C #168 (2 years old, solved)

C #164 (suggestion to close this 10 month ago, no more replies)

C #22 (old)

VF #154, #134 (suggestion to support SVN)  (many VCS)


same names at vim.sf.net cannot be used:
#183, #323, #173

#87 (pretty old, requested status update or closing)
#96 (pretty old, requested status update or closing)
#97 (pretty old, requested status update or closing)
#13 (pretty old, requested status update or closing)

A #88 document as cannot fix (or don't know how to fix)

A #81 still valid?

#47 (more info in search results) related to #173 and closed pull request #250 (for what reason?)

To be reviewed by me (getting tired now)
#176
#174
#112 (helptags doesn't work always)
#103 plugin/*/.vim usage, doesn't get sourced, I once thought this would not be
    #working myself, but I was wrong, would need to retest
#88 (requires testing no windowns)
#86 (requires more work to review)
#76 (needs more work for finding out what this is about - more than one topic
#67 (needs more work - references other branches)
#47 (dup or related to other open in browser stuff and add info context)



Easy to fix - indicate lack of maintainance:
===========================================


#shellshlashes
#378 Shougo forked for this reasoan
#146, #170, #378, #380
#283 (shellslash)
#374, #111


A #278 patch reintroducing ~ (11 month old, does it work again)?
       eventually match against ^~ instead

P #322:  fix rtp in README duplicating
#266  dup of #322
#62 dup of 266
#169
#356, #222: rtp setting for windows gmariks action requiered ?
#260 dup of #111 (and others)


#247 conflict with  bufexplr which seems to be resolved with different branch,
    unsure about what to do?


Easy to fix - for starters
#326: easy thing - anybody should be able to get started with this
#231
#232 (git:// protocol error, is this still current?)
#136 (needs reproducing or closing)
#83 (still valid? check?)