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

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

Expand Messages
  • 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 1 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 2 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 3 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 4 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 5 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.