Loading ...
Sorry, an error occurred while loading the content.

Re: vim plugins & www.vim.org - future

Expand Messages
  • ZyX
    Reply to message «vim plugins & www.vim.org - future», sent 19:32:53 01 July 2011, Friday ... No autofetching of git/svn/hg/... Plugins there are very
    Message 1 of 10 , Jul 1, 2011
    • 0 Attachment
      Reply to message «vim plugins & www.vim.org - future»,
      sent 19:32:53 01 July 2011, Friday
      by Marc Weber:

      > And the result is: Do it like google: Ask authors to register their
      > upstream (git,svn,hg,..) urls and be done. The page should fetch updates
      > and generate the content based on the repos.
      No autofetching of git/svn/hg/... Plugins there are very unstable.
      Separate fields for link to project page, issue tracker, SCM repository url (in
      the format similar to used by paludis (and mercurial for repos not controlled by
      hg):
      {SCM}[+(ssh/https/http/...)]://domain/repo
      Some examples:
      hg+http://vimpluginloader.hg.sourceforge.net:8000/hgroot/vimpluginloader/pluginloader-
      overlay
      git://git.calculate.ru/dev/school.git
      svn://overlays.gentoo.org/proj/sunrise/reviewed/
      svn+https://cafarelli.fr/svn/voyageur-overlay

      > The page should fetch updates
      > and generate the content based on the repos. Eg those who are hosted on
      > github already have a README.* file which could be used to render
      > content.
      README-vim.org.*, not README. Or you want to answer questions like why README is
      displayed differently on vim.org rather then on bitbucket?

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

      > the doc/*.txt files could be used to render the description
      > (and details).
      It should be good to post a formatted version of documentation somewhere like I
      do. But I don't understand your words about the description (documentation is
      documentation, it is neither description nor detailed description in my
      opinion).

      > Its horrific that you have to download a plugin in order
      > to start reading its documentation, isn't it?
      That is why I post documentation to sourceforge.
      // With VAM downloading a plugin in order to read its documentation is simpler.

      > Of course each author should be able to assign tags to his/her plugin
      Good.

      > and create cross references to other plugins such as
      Bad. Too many possible relations. If one wants to do something like this he
      should put this in README.

      > my plugin "xptemplate" -is-related-to snipmate
      > my plugin "xptemplate" -is-related-to ultisnips
      Very bad. It should be handled by smart tags choice of both authors, not by
      xptemplate author.

      > my plugin "xptemplate" supersedes XY because FOO
      Even worse: you think it superseeds, but others don't. Too subjective to be
      here.

      > We could move all existing plugins on www.vim.org (which don't have any
      > maintainers) to a github account - the way vim-scripts has done it.
      What for?
      It is good to force one known format of archives, but git is an overkill.

      Original message:
      > I've been thinking about how to optimize that user find plugins
      > - and how to make it easier for devs to expose their plugins to the
      > public (of course this should be better than google).
      >
      > And the result is: Do it like google: Ask authors to register their
      > upstream (git,svn,hg,..) urls and be done. The page should fetch updates
      > and generate the content based on the repos. Eg those who are hosted on
      > github already have a README.* file which could be used to render
      > content. the doc/*.txt files could be used to render the description
      > (and details). Its horrific that you have to download a plugin in order
      > to start reading its documentation, isn't it?
      >
      > Of course each author should be able to assign tags to his/her plugin
      > and create cross references to other plugins such as
      >
      > my plugin "xptemplate" -is-related-to snipmate
      > my plugin "xptemplate" -is-related-to ultisnips
      >
      > my plugin "xptemplate" supersedes XY because FOO
      >
      > In the end that's almost all users care about.
      >
      > We could move all existing plugins on www.vim.org (which don't have any
      > maintainers) to a github account - the way vim-scripts has done it.
      >
      > Does this make sense to you?
      > Do you see any major problems which such an "open" design?
      >
      > I'm not going to replace www.vim.org in the near future.
      > However may be willing to setup an alternative site which could be good
      > enough to replace www.vim.org one day if Bram agrees, funding and
      > support of the page suffices and the charity aspect of Vim is honored etc.
      >
      > And to make this a success I'd like to allow everyone to participate.
      >
      > Marc Weber
    • lith
      ... Isn t this self-contradictory? A plugin with no maintainer will probably never be updated. Why maintain it in a DVCS then? If somebody wants to create a
      Message 2 of 10 , Jul 1, 2011
      • 0 Attachment

        We could move all existing plugins on www.vim.org (which don't have any
        maintainers) to a github account - the way vim-scripts has done it.

        Isn't this self-contradictory? A plugin with no maintainer will probably never be updated. Why maintain it in a DVCS then? If somebody wants to create a fork, he/she is free to maintain the fork on github/bitbucket/etc.

        BTW I wouldn't make vim.org too dependent on github. Different people prefer different VCS or hosts. Maybe the plugin form could contain an URL field that is used to retrieve the README, wherever it is hosted. I'd display the README as plain text only.

        I personally think tags would be a great step forward.

        Regards,
        Tom

        --
        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
      • Marc Weber
        ZyX: ... 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
        Message 3 of 10 , Jul 1, 2011
        • 0 Attachment
          ZyX:
          ====
          > 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
        • ZyX
          Reply to message «Re: Aw: vim plugins & www.vim.org - future», sent 22:13:21 01 July 2011, Friday ... For me it is fine. ... It is a development version
          Message 4 of 10 , Jul 1, 2011
          • 0 Attachment
            Reply to message «Re: Aw: vim plugins & www.vim.org - future»,
            sent 22:13:21 01 July 2011, Friday
            by Marc Weber:

            > 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.
            For me it is fine.

            > But seriously: If you write unstable code knowing that in advance a
            > branch should be created in any case.
            It is a development version under SCM control. If changes are too large I may
            create a branch, but you can't force me to have something stable in a mercurial
            repo. That is what releases are for.

            > We could also start "release" branches and make all tools check those
            > out instead.
            Too much work for different SCMs and even more work to force author's to do
            this.

            > Well. The idea is "do it once". And if it appears slightly different its
            > still a lot better compared to what we have now.
            What we have now is normal: once you have a scribtable API (and you do already:
            with WWW::Mechanize vim.org is easily scriptable). What is needed is more
            semantical fields so that authors will know where to write an issue tracker URL
            and users will know where to find it.

            > > 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.
            This is about changing README's, not about how SCM is helpful.

            > > 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.
            No, it is not. I don't trust this and relations are defined by tags.

            > 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.
            On some sites there is something like «similar plugins» column. Use tags to
            populate it.

            > > 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 :)
            I guess I should have been less concrete: SCM is an overkill.

            > > 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.
            Would be good. What are other fields you plan to be taken from addon-info.json?

            Original message:
            > ZyX:
            > ====
            >
            > > 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
          • Marc Weber
            ... No, seriously: If you re going to break things you should use a topic branch. If your VCS makes this hard you re using the wrong VCS :) But I agree that
            Message 5 of 10 , Jul 1, 2011
            • 0 Attachment
              Excerpts from ZyX's message of Fri Jul 01 20:54:04 +0200 2011:
              > > That's not an issue. We could introduce a version field in addon-info.txt.
              > For me it is fine.
              No, seriously: If you're going to break things you should use a "topic"
              branch. If your VCS makes this hard you're using the wrong VCS :)

              But I agree that it should not me forcing working styles on others.
              So "version" will be one of the supported fields for that reason even
              though I'm very unlikely to maintain it myself.
              Thus I'd also suggest a setting which tells whether the latest stable
              version should be preferred.
              I just don't to give this version field a high priority at the
              beginning because it requires visiting each commit.

              If your code is still unstable users will tell you and you'll reach a
              new stable state much faster.

              fields I'd use in addon-info.txt:

              tags: ["C++",".."] # to group plugins by language, feature, ...
              name: # name used to resolve dependencies. If there are multiple matches ask user which one to use
              # if there are obvious reasons to prefer one
              # vim-addon-manager-known-repositories will reflect this in some
              # way
              dependencies: {
              # VAM style list of dependencies by name
              }
              maintainer : "email"

              version: "0.3" # if this changes assume new stable version
              preferred: true # for your style of development. Indicates whether the latest stable version should be used

              relations: ... relations to other plugins.

              > No, it is not. I don't trust this and relations are defined by tags.
              Of course you neither trust any VimL code unless you've written it
              yourself. But hey, don't you think that this will give you an idea about
              what could be important? Nobody prevents you from verifying the
              statements yourself.

              And of course I'd rather propagate "join and improve existing projects"
              rather than "fork and tell everybody your code is better" even though it
              may not.

              So this is meant to place hints at "unmaintained" projects so that you
              can get users attention. Of course the user still has to decide what to
              install and use.

              Eg visit this: http://www.vim.org/scripts/script.php?script_id=2540
              The first impression says: "Hey, great plugin". Then you fix something.
              Then you sent a patch. Then you don't get a reply. Then on irc you're
              told: upstream is at github.com/garbas/... Then you can rewrite your
              patch cause all the code has changed?
              What is left ? A bad feeling about wasted time on all sides.

              Its ok to have different ideas about how things should be.
              I'd like to introduce a soft force that those differences get documented
              and pointed out. That's the idea.

              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
            • Daniel Choi
              I applaud this effort. I started writing VimScript applications recently, and I ended up wrapping my Vim applications and plugins in Ruby gems because I think
              Message 6 of 10 , Jul 1, 2011
              • 0 Attachment
                I applaud this effort.

                I started writing VimScript applications recently, and I ended up
                wrapping my Vim applications and plugins in Ruby gems because I think
                it's significantly easier for people to install and get up and running
                that way.

                I know you're addressing other issues besides ease of installation and
                upgrades for end-users, but I would like to suggest the Ruby gem
                system as a model you might borrow some features from.

                Dan Choi

                http://danielchoi.com/software

                --
                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
              • ZyX
                Reply to message «Re: Aw: vim plugins & www.vim.org - future», sent 00:25:07 02 July 2011, Saturday ... I see no profit here. I will spend too much time
                Message 7 of 10 , Jul 1, 2011
                • 0 Attachment
                  Reply to message «Re: Aw: vim plugins & www.vim.org - future»,
                  sent 00:25:07 02 July 2011, Saturday
                  by Marc Weber:

                  > No, seriously: If you're going to break things you should use a "topic"
                  > branch. If your VCS makes this hard you're using the wrong VCS :)
                  I see no profit here. I will spend too much time guessing how should I name this
                  branch instead of doing something. My preoutgoing hooks ensure that nothing will
                  be pushed unless it passes all tests (though it does not ensure that I won't
                  change tests themselves), so breakage is not too large.

                  In any case
                  1. I am not going to have anything stable at the 'default' branch.
                  2. Tip is what I use on my machine, so bad breakages will be fixed soon.
                  3. Never consider SCM version to be stable.
                  4. 1.-3. are related only to me, not to other developers.

                  > So "version" will be one of the supported fields for that reason even
                  > though I'm very unlikely to maintain it myself.
                  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?

                  > I just don't to give this version field a high priority at the
                  > beginning because it requires visiting each commit.
                  One of the reasons why I would leave the job of doing a releases on authors:
                  after creating a series of commits I do
                  ../repository/pkgdo.pl release fooplugin +++ $'Added foo#Bar()\nFixed...'
                  `+++' is incrementing plugin version (in this case: third number). $'...' is
                  comment to release.

                  Where are you going to get comments on releases if you do release automatically?
                  What if repository is very large (because somebody is trying to perform a DoS
                  attack)?

                  > If your code is still unstable users will tell you and you'll reach a
                  > new stable state much faster.
                  Code is stable enough in releases. Users must not expect development version to
                  be stable. Vim.org must not do this either.

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

                  > > No, it is not. I don't trust this and relations are defined by tags.
                  >
                  > Of course you neither trust any VimL code unless you've written it
                  > yourself. But hey, don't you think that this will give you an idea about
                  > what could be important? Nobody prevents you from verifying the
                  > statements yourself.
                  >
                  > And of course I'd rather propagate "join and improve existing projects"
                  > rather than "fork and tell everybody your code is better" even though it
                  > may not.
                  >
                  > So this is meant to place hints at "unmaintained" projects so that you
                  > can get users attention. Of course the user still has to decide what to
                  > install and use.
                  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.

                  > Eg visit this: http://www.vim.org/scripts/script.php?script_id=2540
                  > The first impression says: "Hey, great plugin". Then you fix something.
                  > Then you sent a patch. Then you don't get a reply. Then on irc you're
                  > told: upstream is at github.com/garbas/... Then you can rewrite your
                  > patch cause all the code has changed?
                  > What is left ? A bad feeling about wasted time on all sides.
                  I don't argue the fact that there should be fields `project page' and/or `SCM
                  repository'.


                  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.

                  Original message:
                  > Excerpts from ZyX's message of Fri Jul 01 20:54:04 +0200 2011:
                  > > > That's not an issue. We could introduce a version field in
                  > > > addon-info.txt.
                  > >
                  > > For me it is fine.
                  >
                  > No, seriously: If you're going to break things you should use a "topic"
                  > branch. If your VCS makes this hard you're using the wrong VCS :)
                  >
                  > But I agree that it should not me forcing working styles on others.
                  > So "version" will be one of the supported fields for that reason even
                  > though I'm very unlikely to maintain it myself.
                  > Thus I'd also suggest a setting which tells whether the latest stable
                  > version should be preferred.
                  > I just don't to give this version field a high priority at the
                  > beginning because it requires visiting each commit.
                  >
                  > If your code is still unstable users will tell you and you'll reach a
                  > new stable state much faster.
                  >
                  > fields I'd use in addon-info.txt:
                  >
                  > tags: ["C++",".."] # to group plugins by language, feature, ...
                  > name: # name used to resolve dependencies. If there are multiple matches
                  > ask user which one to use # if there are obvious reasons to prefer one
                  > # vim-addon-manager-known-repositories will reflect this in some
                  > # way
                  > dependencies: {
                  > # VAM style list of dependencies by name
                  > }
                  > maintainer : "email"
                  >
                  > version: "0.3" # if this changes assume new stable version
                  > preferred: true # for your style of development. Indicates whether the
                  > latest stable version should be used
                  >
                  > relations: ... relations to other plugins.
                  >
                  > > No, it is not. I don't trust this and relations are defined by tags.
                  >
                  > Of course you neither trust any VimL code unless you've written it
                  > yourself. But hey, don't you think that this will give you an idea about
                  > what could be important? Nobody prevents you from verifying the
                  > statements yourself.
                  >
                  > And of course I'd rather propagate "join and improve existing projects"
                  > rather than "fork and tell everybody your code is better" even though it
                  > may not.
                  >
                  > So this is meant to place hints at "unmaintained" projects so that you
                  > can get users attention. Of course the user still has to decide what to
                  > install and use.
                  >
                  > Eg visit this: http://www.vim.org/scripts/script.php?script_id=2540
                  > The first impression says: "Hey, great plugin". Then you fix something.
                  > Then you sent a patch. Then you don't get a reply. Then on irc you're
                  > told: upstream is at github.com/garbas/... Then you can rewrite your
                  > patch cause all the code has changed?
                  > What is left ? A bad feeling about wasted time on all sides.
                  >
                  > Its ok to have different ideas about how things should be.
                  > I'd like to introduce a soft force that those differences get documented
                  > and pointed out. That's the idea.
                  >
                  > Marc Weber
                • Marc Weber
                  ... Because every dev has to find this solution and write his/her own script. Overkill. ... Either changelog summary. Eg using git ( :-) ) its common to create
                  Message 8 of 10 , Jul 1, 2011
                  • 0 Attachment
                    > 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

                    --
                    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
                  • ZyX
                    Reply to message «Re: Aw: vim plugins & www.vim.org - future», sent 04:12:56 02 July 2011, Saturday ... Scripts can t be published? You are free to reuse
                    Message 9 of 10 , Jul 2, 2011
                    • 0 Attachment
                      Reply to message «Re: Aw: vim plugins & www.vim.org - future»,
                      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
                    Your message has been successfully submitted and would be delivered to recipients shortly.