Ben Fritz wrote:
> On Wed, May 23, 2012 at 8:42 PM, James McCoy 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 wrote:
> >> >
> >> > Ben Fritz wrote:
> >> >
> >> >> On Monday, May 21, 2012 12:59:47 PM UTC-5, Thilo S
On Thursday, May 24, 2012 11:37:33 AM UTC-5, Thilo Six wrote:
> Hello Tony,
>
>
> Excerpt from Tony Mechelynck:
>
> -- --
> > 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 o
Hello Tony,
Excerpt from Tony Mechelynck:
-- --
> 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 al
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 G
On Wed, May 23, 2012 at 8:42 PM, James McCoy 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 wrote:
>> >
>> > Ben Fritz wrote:
>> >
>> >> On Monday, May 21, 2012 12:59:47 PM UTC-5, Thilo Six wrote:
>> >> > > How about set
On Wed, May 23, 2012 at 08:31:48PM -0500, Benjamin Fritz wrote:
> On Wed, May 23, 2012 at 1:52 PM, Bram Moolenaar 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://
On Wed, May 23, 2012 at 1:52 PM, Bram Moolenaar 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
>> >
>> > runtimef
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
>
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 Co
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 proble
Hello Charles,
Excerpt from Charles Campbell:
-- --
> Perhaps there could be an automated annual email such as:
>
> ---
> Hello!
>
> Thank you for your maintaining of . The Vim community
> greatly appreciates your work.
> This is an automated annual request: are
Hello Ben and John,
Excerpt from Ben Fritz:
-- --
>> 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
>> +--ftpl
Benjamin R. Haskell wrote:
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 are u
Thomas Köhler wrote:
Hi Thilo,
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
changed
Hello Gary,
Excerpt from Gary Johnson:
-- --
>> 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
4096R/0xC
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"
>
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 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
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 f
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 f
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".
> >> Any
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 u
Hello Ernie,
Excerpt from Ernie Rael:
-- --
> By other mail it looks like the big procedural issue of repository
> hierarchy/operation is getting close to agreement.
-- --
I might not have been explicit enough about this yet. So lets fix that. I wont
create those repos and i do not plan to b
On 5/19/2012 2:01 AM, Thilo Six wrote:
Hello Ben,
Excerpt from Ben Fritz:
-- --
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 "s
Hello Ben,
Excerpt from Ben Fritz:
-- --
>>> 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 interest
Hello Dr. chip,
Excerpt from Charles E Campbell Jr:
-- --
> 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 a
Hello Ben,
Excerpt from Ben Fritz:
-- --
>>> 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 a
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 mailin
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 volu
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 thos
Dominique Pellé :
> Thilo Six 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:
>
> http://www.atlassian.
Thilo Six 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:
http://www.atlassian.com/en/software/crucible/overvi
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 main
Hello Dominique,
Excerpt from Dominique Pellé:
> John Beckett 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
John Beckett 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 files
>> they ar
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 d
Hello, Thilo and those who have been actively discussed the runtime file issue.
On May 18, 2012, at 6:37 AM, Thilo Six wrote:
>
>
> 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 ma
Thilo Six wrote:
> 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 can help with routine matters, but I've never spent any
significant time with syntax files.
John
--
You received this messag
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
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
Hello Bram and Ben,
Excerpt from Bram Moolenaar:
-- --
>>> 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 chang
Thilo Six wrote:
> Excerpt from Bram Moolenaar:
> -- --
> > 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 chan
Hello Bram,
Excerpt from Bram Moolenaar:
-- --
> 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 submi
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 compatibil
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
> thre
On 16-May-2012 21:42, Dominique Pellé wrote:
> Ingo Karkat 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?
Yes, I am, tho
Ingo Karkat 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 Mercurial. Here are t
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, someth
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:
>>
>> http://gott-gehabt.de/800_wer_wir_sind/thomas/Homepage/Comput
Hello Ernie,
Excerpt from Ernie Rael:
-- --
> 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 fi
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
>
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 someth
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 ho
Hello Thilo,
Thilo Six wrote:
> Hello Thomas and Benjamin,
> Excerpt from Thomas Köhler:
> -- --
> >> 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.
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
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
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 m
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 n
Hello Thomas and Benjamin,
Excerpt from Thomas Köhler:
-- --
>> 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 mainta
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 Google
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 e
On Tue, 15 May 2012, Thomas Köhler wrote:
Hi Thilo,
Thilo Six wrote:
Excerpt from Thomas Köhler:
-- --
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 meanin
Hi Thilo,
Thilo Six wrote:
> Excerpt from Thomas Köhler:
>
> -- --
> > 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 c
Hello Thomas,
I answer on list.
Excerpt from Thomas Köhler:
-- --
> 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 my
Hi all,
Dominique Pellé wrote:
> Benjamin R. Haskell 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 tea
Hello Dominique,
Excerpt from Dominique Pellé:
-- --
> 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 wi
Benjamin R. Haskell 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. Unless that c
-- --
> 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
Hello Benjamin,
Excerpt from Benjamin R. Haskell:
-- --
> 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
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 goo
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 t
John Beckett 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 except to email t
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, t
Charles Campbell 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 spell
>>
>
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 maintai
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.
76 matches
Mail list logo
