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
No comments:
Post a Comment