Ben Fritz wrote:
On Wed, May 23, 2012 at 8:42 PM, James McCoy james...@jamessan.com wrote:
On Wed, May 23, 2012 at 08:31:48PM -0500, Benjamin Fritz wrote:
On Wed, May 23, 2012 at 1:52 PM, Bram Moolenaar b...@moolenaar.net wrote:
Ben Fritz wrote:
On Monday, May 21, 2012 12:59:47
Hello Tony,
Excerpt from Tony Mechelynck:
-- snip --
The Vim license goes far back in the history of Vim, and I think Bram
put a lot of thought (over time) into making it exactly what he wanted.
OTOH the GPL is one of a short list of popular licenses and there may
have been requests to
On Thursday, May 24, 2012 11:37:33 AM UTC-5, Thilo Six wrote:
Hello Tony,
Excerpt from Tony Mechelynck:
-- snip --
The Vim license goes far back in the history of Vim, and I think Bram
put a lot of thought (over time) into making it exactly what he wanted.
OTOH the GPL is one of a
Ben Fritz wrote:
On Monday, May 21, 2012 12:59:47 PM UTC-5, Thilo Six wrote:
How about setting up an independent repo (not a clone) at
http://vim-runtime.googlecode.com/
Code license: GNU GPL v2
runtimefiles are all (or better they all should be) licensed under Vim
licences.
On Wed, May 23, 2012 at 1:52 PM, Bram Moolenaar b...@moolenaar.net wrote:
Ben Fritz wrote:
On Monday, May 21, 2012 12:59:47 PM UTC-5, Thilo Six wrote:
How about setting up an independent repo (not a clone) at
http://vim-runtime.googlecode.com/
Code license: GNU GPL v2
runtimefiles
On Wed, May 23, 2012 at 08:31:48PM -0500, Benjamin Fritz wrote:
On Wed, May 23, 2012 at 1:52 PM, Bram Moolenaar b...@moolenaar.net wrote:
Ben Fritz wrote:
On Monday, May 21, 2012 12:59:47 PM UTC-5, Thilo Six wrote:
How about setting up an independent repo (not a clone) at
On Wed, May 23, 2012 at 8:42 PM, James McCoy james...@jamessan.com wrote:
On Wed, May 23, 2012 at 08:31:48PM -0500, Benjamin Fritz wrote:
On Wed, May 23, 2012 at 1:52 PM, Bram Moolenaar b...@moolenaar.net wrote:
Ben Fritz wrote:
On Monday, May 21, 2012 12:59:47 PM UTC-5, Thilo Six wrote:
On 24/05/12 04:29, Benjamin Fritz wrote:
[...]
I did not realize that. What are the reasons, then, for the dual
license? I feel kind of silly for not noticing until we went to the
Google Code repository. I do remember seeing a big licensing
discussion back around that time, where I learned that
Here are some thoughts for a group-managed repo.
It must be simple for the group managers, and for file
maintainers, and for Bram. It must also be simple for anyone to
report a problem or make a suggestion.
It should be similar to the existing Vim repo, and Mercurial
should be available just as
What directories should the group manage?
A possibility is below, although it may be too ambitious. It
shows all first-level directories under runtime, with some to
be managed by a group, and the remainder run directly by Bram.
The files in 'runtime' would NOT be part of the group repo, but
all
On Monday, May 21, 2012 2:11:13 AM UTC-5, JohnBeckett wrote:
Ben Fritz has pointed out that a second independent repo could
be created (vim-runtime-dev?) where any maintainer or other
interested party could be given access for hg push. Then
reviewers could pull changes into the stable
On Monday, May 21, 2012 2:11:13 AM UTC-5, JohnBeckett wrote:
What directories should the group manage?
A possibility is below, although it may be too ambitious. It
shows all first-level directories under runtime, with some to
be managed by a group, and the remainder run directly by Bram.
On Saturday, May 19, 2012 4:16:13 PM UTC-5, Ernie Rael wrote:
1. I want to maintain all changes to my file. Please don't touch it beyond
what I send you. I commit to be responsive enough for this to work.
2. I want to do all big changes and feature additions, but small
changes
Hello Gary,
Excerpt from Gary Johnson:
-- snip --
Would you be willing to set up a repository for us?
I'd be willing if I knew how, but I've never done that.
My expertise in this filed isn't large either. But thanks for helping anyway.
Regards,
Gary
--
Regards,
Thilo
Thomas Köhler wrote:
Hi Thilo,
snip
BTW, some files might not be changed because there is not much need.
I last changed uil.vim and prolog.vim in 2009 to support some new
feature available in vim (and uil.vim yesterday due to
Dominique's patch for @Spell support), and before that, I think I
Benjamin R. Haskell wrote:
snip
The hard part of supporting a given language in Vim is the first step:
writing the syntax file in the first place. Once there's a
relatively-complete syntax file (and most of the syntax files included
in Vim are fairly mature), the changes to that syntax file
Hello Ben and John,
Excerpt from Ben Fritz:
-- snip --
The files in 'runtime' would NOT be part of the group repo, but
all files in each listed directory (and subdirectories) would be
part of the group repo.
runtime (group)
+--autoload
+--colors
+--compiler
+--ftplugin
Hello Charles,
Excerpt from Charles Campbell:
-- snip --
Perhaps there could be an automated annual email such as:
---
Hello!
Thank you for your maintaining of runtimefile.vim. The Vim community
greatly appreciates your work.
This is an automated annual
Hello John,
Excerpt from John Beckett:
I am all with you here. I just want to add a note. see below.
Here are some thoughts for a group-managed repo.
It must be simple for the group managers, and for file
maintainers, and for Bram. It must also be simple for anyone to
report a problem or
On Monday, May 21, 2012 12:59:47 PM UTC-5, Thilo Six wrote:
How about setting up an independent repo (not a clone) at
http://vim-runtime.googlecode.com/
Code license: GNU GPL v2
runtimefiles are all (or better they all should be) licensed under Vim
licences.
Yeah, but Google Code only
Hello Gary,
Excerpt from Gary Johnson:
On 2012-05-17, Thilo Six wrote:
I would require that we gain at least 7 individuals with commit access.
This is to somewhat grant that always someone is around who can do the job.
Anyone who is interested to volunteer for this please speak up now.
On 2012-05-20, Thilo Six wrote:
Hello Gary,
Excerpt from Gary Johnson:
On 2012-05-17, Thilo Six wrote:
I would require that we gain at least 7 individuals with commit access.
This is to somewhat grant that always someone is around who can do the
job.
Anyone who is interested
Hello Ben,
Excerpt from Ben Fritz:
-- snip --
As a maintainer of a few runtime files, I have something to
make sure of: Are there any changes for the current
maintainers in what they observe--policy, obligations, or
something similar to those, to maintain the runtime files
they are in
Hello Dr. chip,
Excerpt from Charles E Campbell Jr:
-- snip --
Hello!
I've been on vacation this week, attending my daughter's graduation from
Emory University.
Congratulations.
I have several concerns about this proposal:
* vim.vim : there's a large block of code that I generate
Hello Ben,
Excerpt from Ben Fritz:
-- snip --
I would require that we gain at least 7 individuals with commit access.
This is to somewhat grant that always someone is around who can do the
job.
Anyone who is interested to volunteer for this please speak up now.
I am interested.
I am
On 5/19/2012 2:01 AM, Thilo Six wrote:
Hello Ben,
Excerpt from Ben Fritz:
-- snip --
1. I want to maintain all changes to my file. Please don't touch it beyond
what I send you. I commit to be responsive enough for this to work.
2. I want to do all big changes and feature additions, but
Hello Ernie,
Excerpt from Ernie Rael:
-- snip --
By other mail it looks like the big procedural issue of repository
hierarchy/operation is getting close to agreement.
-- snip --
I might not have been explicit enough about this yet. So lets fix that. I wont
create those repos and i do not
Hello, Thilo and those who have been actively discussed the runtime file issue.
On May 18, 2012, at 6:37 AM, Thilo Six wrote:
snip
Then we have decided that we change current maintenance model of runtimefiles
to
be a collaboration one and we use 'vim-dev' for future coordination.
As a
Kazunobu Kuriyama wrote:
As a maintainer of a few runtime files, I have something to
make sure of: Are there any changes for the current
maintainers in what they observe--policy, obligations, or
something similar to those, to maintain the runtime files
they are in charge of?
Nothing is
John Beckett johnb.beck...@gmail.com wrote:
Kazunobu Kuriyama wrote:
As a maintainer of a few runtime files, I have something to
make sure of: Are there any changes for the current
maintainers in what they observe--policy, obligations, or
something similar to those, to maintain the runtime
Hello Dominique,
Excerpt from Dominique Pellé:
John Beckett johnb.beck...@gmail.com wrote:
Kazunobu Kuriyama wrote:
As a maintainer of a few runtime files, I have something to
make sure of: Are there any changes for the current
maintainers in what they observe--policy, obligations, or
Hello Kazunobu and John,
Excerpt from John Beckett:
Kazunobu Kuriyama wrote:
As a maintainer of a few runtime files, I have something to
make sure of: Are there any changes for the current
maintainers in what they observe--policy, obligations, or
something similar to those, to maintain the
Thilo Six t@gmx.de wrote:
I would like to be able to comment
on checkins in a more formal way than emails.
How exactly would that work?
An image is worth a 1000 words. So here is a screenshot
illustrating how code reviews happen in Crucible:
Dominique Pellé dominique.pe...@gmail.com:
Thilo Six t@gmx.de wrote:
I would like to be able to comment
on checkins in a more formal way than emails.
How exactly would that work?
An image is worth a 1000 words. So here is a screenshot
illustrating how code reviews happen in Crucible:
On Friday, May 18, 2012 2:45:16 AM UTC-5, JohnBeckett wrote:
Kazunobu Kuriyama wrote:
As a maintainer of a few runtime files, I have something to
make sure of: Are there any changes for the current
maintainers in what they observe--policy, obligations, or
something similar to those, to
On Friday, May 18, 2012 12:54:56 AM UTC-5, Gary Johnson wrote:
On 2012-05-17, Thilo Six wrote:
I would require that we gain at least 7 individuals with commit access.
This is to somewhat grant that always someone is around who can do the
job.
Anyone who is interested to volunteer for
Ben Fritz wrote:
On Thursday, May 17, 2012 1:07:52 PM UTC-5, Thilo Six wrote:
To me absolutely yes. Obviously we will need to discuss and decide some more
details/workflows but i think the consensus is broad enough to start getting it
productive.
Are you fine with using vim-dev as our
Ingo Karkat wrote:
On 16-May-2012 08:35:30 -0700 (PDT), Ben Fritz wrote:
Or, how about just a clone of the main Vim repository? Often runtime
file changes are related to changes in the Vim code.
Often? Vim has superb backward compatibility, and the thing that started this
thread is
On Wednesday, May 16, 2012 2:15:34 PM UTC-5, Ingo Karkat wrote:
On 16-May-2012 08:35:30 -0700 (PDT), Ben Fritz wrote:
Or, how about just a clone of the main Vim repository? Often runtime
file changes are related to changes in the Vim code.
Often? Vim has superb backward compatibility,
Hello Bram,
Excerpt from Bram Moolenaar:
-- snip --
Including patches for runtime files doesn't take much of my time, under
the condition that I can include them as-is. Most time goes into
reviewing the change and making sure it doesn't break anything. Or
omits another change that was
Thilo Six wrote:
Excerpt from Bram Moolenaar:
-- snip --
Including patches for runtime files doesn't take much of my time, under
the condition that I can include them as-is. Most time goes into
reviewing the change and making sure it doesn't break anything. Or
omits another change
Hello Bram and Ben,
Excerpt from Bram Moolenaar:
-- snip --
Including patches for runtime files doesn't take much of my time, under
the condition that I can include them as-is. Most time goes into
reviewing the change and making sure it doesn't break anything. Or
omits another change that
On Thursday, May 17, 2012 1:07:52 PM UTC-5, Thilo Six wrote:
To me absolutely yes. Obviously we will need to discuss and decide some more
details/workflows but i think the consensus is broad enough to start getting
it
productive.
Are you fine with using vim-dev as our mailinglist for all
On 2012-05-17, Thilo Six wrote:
I would require that we gain at least 7 individuals with commit access.
This is to somewhat grant that always someone is around who can do the job.
Anyone who is interested to volunteer for this please speak up now.
I am interested.
Regards,
Gary
--
You
Hello Thilo,
Thilo Six wrote:
Hello Thomas and Benjamin,
Excerpt from Thomas Köhler:
-- snip --
I think you're misinterpreting what team maintenance would mean. It
wouldn't be a team per language, but rather a single team to handle
changes (maintenance) to all syntax files. (Which
On Tue, 15 May 2012, Ernie Rael wrote:
On 5/15/2012 9:02 AM, Thilo Six wrote:
No one is anyone blocking to take care of their peeve pets.
I'd be hesitant to suggest that people take care of their pet
peeves. Yes for real bugs or infrastructure features (like spell).
But since there is
On Wednesday, May 16, 2012 1:14:00 AM UTC-5, Thomas Köhler wrote:
OK, now things are clearer for me. That's basically a good idea,
but:
- URL would also need to change:
http://gott-gehabt.de/800_wer_wir_sind/thomas/Homepage/Computer/vim/syntax/uil.vim
would need to become something
On Wednesday, May 16, 2012 1:32:31 AM UTC-5, Benjamin R. Haskell wrote:
On Tue, 15 May 2012, Ernie Rael wrote:
On 5/15/2012 9:02 AM, Thilo Six wrote:
No one is anyone blocking to take care of their peeve pets.
I'd be hesitant to suggest that people take care of their pet
peeves. Yes
Hello Ernie,
Excerpt from Ernie Rael:
-- snip --
But since
there is hopefully a main guy for each file, shouldn't random changes be
kept to a minimum?
Well i can only speak for myself. Usually i very hardly try to be friendly. That
means the workflow of asking the maintainer for a change
Hi Thomas and Ben,
Excerpt from Ben Fritz:
On Wednesday, May 16, 2012 1:14:00 AM UTC-5, Thomas Köhler wrote:
OK, now things are clearer for me. That's basically a good idea,
but:
- URL would also need to change:
On 16-May-2012 08:35:30 -0700 (PDT), Ben Fritz wrote:
Or, how about just a clone of the main Vim repository? Often runtime
file changes are related to changes in the Vim code.
Often? Vim has superb backward compatibility, and the thing that started this
thread is adding @Spell support,
Ingo Karkat sw...@ingo-karkat.de wrote:
I would like to see runtime files treated the same way as all other Vim
sources.
Right now, no patches are published, and Bram just occasionally commits them
to
the repo.
Aren't you using Mercurial? Runtime files are now updated quite
often in
On 16-May-2012 21:42, Dominique Pellé wrote:
Ingo Karkat sw...@ingo-karkat.de wrote:
I would like to see runtime files treated the same way as all other
Vim sources. Right now, no patches are published, and Bram just
occasionally commits them to the repo.
Aren't you using Mercurial?
Hi Thilo,
Thilo Six wrote:
Excerpt from Thomas Köhler:
-- snip --
And it would help people like me that used to maintain some
runtime files in the past and now are stuck maintaining something
they don't use any longer.
I think that is exactly the meaning of team maintenance.
I commit
On Tue, 15 May 2012, Thomas Köhler wrote:
Hi Thilo,
Thilo Six wrote:
Excerpt from Thomas Köhler:
-- snip --
And it would help people like me that used to maintain some runtime
files in the past and now are stuck maintaining something they don't
use any longer.
I think that is exactly the
Hello Benjamin,
Benjamin R. Haskell wrote:
On Tue, 15 May 2012, Thomas Köhler wrote:
Thilo Six wrote:
Excerpt from Thomas Köhler:
[...]
But of course, there once was a reason for the current model, which
is let people maintain the stuff who know what they are doing
That exactly will not be
I like the idea of team maintenance of runtime files. I don't see why we
shouldn't just do it for all the runtime files. Just set up a Bitbucket or
Github clone (or another Google Code project, but I don't see a good way to
relate it back to the main Vim repository, and clones made on the
Hello Thomas and Benjamin,
Excerpt from Thomas Köhler:
-- snip --
I think you're misinterpreting what team maintenance would mean. It
wouldn't be a team per language, but rather a single team to handle
changes (maintenance) to all syntax files. (Which doesn't preclude
active maintainers
On 2012-05-15, Thilo Six wrote:
When i think of this team i count each current maintainer as a member already.
The idea is to use a mailinglist where anyone who likes can subscribe (think
of
vim-dev). All communication about runtimefiles happens openly. Not 99% via
private email where no
On Di, 15 Mai 2012, Gary Johnson wrote:
I like it.
Do you think there would be enough maintenance traffic to justify a
separate runtime-maintainers list or would vim-dev suffice?
+1
If the traffic isn't too big, I would prefer vim-dev list (since I am
already subscribed) so please add me
Hello Gary and Christian,
Excerpt from Christian Brabandt:
On Di, 15 Mai 2012, Gary Johnson wrote:
I like it.
Do you think there would be enough maintenance traffic to justify a
separate runtime-maintainers list or would vim-dev suffice?
+1
If the traffic isn't too big, I would
On 5/15/2012 9:02 AM, Thilo Six wrote:
No one is anyone blocking to take care of their peeve pets.
I'd be hesitant to suggest that people take care of their pet peeves.
Yes for real bugs or infrastructure features (like spell). But since
there is hopefully a main guy for each file, shouldn't
Hello Benjamin,
Excerpt from Benjamin R. Haskell:
-- snip --
I concur completely that a team of runtime file maintainers sounds
better. Back in January, I started composing an email wondering whether
having maintainers still made sense as a development model.
(Personally, I also find it
-- snip --
IIRC a maintainer has committed himself to be reachable via email 3 years
after
his last change. (I must have read that in vim help somewhere, but need to
seek
that out again first where exactly that was).
This is a good read:
:h develop.txt
though it does no contain that
Benjamin R. Haskell v...@benizi.com wrote:
[...]
On Sat, 12 May 2012, Thilo Six wrote:
[...]
That is exactlx what i think about the current practice, too. Really i
think instead of that single-point-of-failure modell of maintenance we
should move the a team maintenance of runtimefiles.
Hello Dominique,
Excerpt from Dominique Pellé:
-- snip --
Some statistics: I've contacted the maintainers of 15 syntax files
this weekend to add spelling checker support. The stats so far are:
- 4 responses received from maintainers of awk, forth, ocaml, scheme
(thanks!);
- 6 emails
Hello Thomas,
I answer on list.
Excerpt from Thomas Köhler:
-- snip --
And it would help people like me that used to maintain some
runtime files in the past and now are stuck maintaining something
they don't use any longer.
I think that is exactly the meaning of team maintenance.
I commit
On Sat, 12 May 2012, Thilo Six wrote:
Excerpt from John Beckett:
Dominique Pellé wrote:
Yes. Maintainers were in CC of the emails. But perhaps I should
write to the maintainers only to avoid sending too many emails to
vim_dev (still more of those simple patches to come...)
There is no
Hello John,
Excerpt from John Beckett:
Dominique Pellé wrote:
Yes. Maintainers were in CC of the emails. But perhaps I
should write to the maintainers only to avoid sending too many
emails to vim_dev (still more of those simple patches to
come...)
There is no good way to do this except
Hi
Attached patch adds @Spell to the runtime/syntax/ocaml.vim file
so that Vim only highlights spelling mistakes in comments and
strings when editing an ocaml source file with those settings:
:syntax on
:set spell
Regards
-- Dominique
--
You received this message from the vim_dev maillist.
Dominique Pellé wrote:
Hi
Attached patch adds @Spell to the runtime/syntax/ocaml.vim file
so that Vim only highlights spelling mistakes in comments and
strings when editing an ocaml source file with those settings:
:syntax on
:set spell
Dominique: did you contact the syntax file
Charles Campbell charles.e.campb...@nasa.gov wrote:
Dominique Pellé wrote:
Hi
Attached patch adds @Spell to the runtime/syntax/ocaml.vim file
so that Vim only highlights spelling mistakes in comments and
strings when editing an ocaml source file with those settings:
:syntax on
:set
Dominique Pellé wrote:
Yes. Maintainers were in CC of the emails. But perhaps I
should write to the maintainers only to avoid sending too many
emails to vim_dev (still more of those simple patches to
come...)
There is no good way to do this except to email the maintainers
only ... wait, try
John Beckett johnb.beck...@gmail.com wrote:
Dominique Pellé wrote:
Yes. Maintainers were in CC of the emails. But perhaps I
should write to the maintainers only to avoid sending too many
emails to vim_dev (still more of those simple patches to
come...)
There is no good way to do this
74 matches
Mail list logo
