Hi all,

I created a new github repository where I'm dumping all extensions I
write or port from Java myself. The intention is having a community
based repository for all things Lucene.Net. I threw some stuff in
already, and will have some more soon. More details here:
http://www.code972.com/blog/2011/06/announcing-lucene-net-contrib/

Code is at https://github.com/synhershko/Lucene.Net.Contrib

Itamar.

In fact, there is a repo in contrib for this purpose. "core". (I know a
better name is needed)
https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net_2_9_4g/src/contrib

IMO, all community contributions should be at one place (Apache) to avoid
confusions,  since there are already a lot of Lucene.Net related
codes/repositories around(  ActiveLuceneNet, LuceneWrap, LinqToLucene, Azure
Library for Lucene.Net, HebMorph :) etc. ). For ex., looking at your
"Announcing: Lucene.Net.Contrib" page, I see that you are not aware of the
"simplistic implementations" of faceted search in contrib.
DIGY
On Thu, Jun 16, 2011 at 4:38 PM, Itamar Syn-Hershko <[EMAIL PROTECTED]>wrote:

> Hi all,
>
> I created a new github repository where I'm dumping all extensions I write
> or port from Java myself. The intention is having a community based
> repository for all things Lucene.Net. I threw some stuff in already, and
> will have some more soon. More details here:
> http://www.code972.com/blog/2011/06/announcing-lucene-net-contrib/
>
> Code is at https://github.com/synhershko/Lucene.Net.Contrib
>
> Itamar.
>

To cite my blog post:
"This is not trying to compete with Lucene.Net's contrib section, it is
just intended in being much more flexible, fast growing community of
extensions, most probably will be small in size."
The .NET community is not around Apache as much as the Java community
is. It is much easier to get to it via github and nuget, and it is
impossible to do that in slow release cycles. Also, git is so much
easier for projects of this sort, where community contributions is the
center of things (unlike Lucene.Net, in which the product is). Forks and
branches in SVN are a real pain...
My goal is to publish extensions I find useful and hopefully to get or
incorporate others' too. If for example I find a bug in
FastVectorHighlighter and can't wait on a Lucene.Net release, I'd copy
it from the original Contrib and fix it on my branch. I don't think all
changes justify that, hence my latest patch was submitted to JIRA.
I'm not trying to split resources, on the contrary. As far as I'm
concerned, you can incorporate my repo in contribs before every release.
Itamar.
On 16/06/2011 17:47, digy digy wrote:

> In fact, there is a repo in contrib for this purpose. "core". (I know a
> better name is needed)
> https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net_2_9_4g/src/contrib
>
> IMO, all community contributions should be at one place (Apache) to avoid
> confusions,  since there are already a lot of Lucene.Net related
> codes/repositories around(  ActiveLuceneNet, LuceneWrap, LinqToLucene, Azure
> Library for Lucene.Net, HebMorph :) etc. ). For ex., looking at your
> "Announcing: Lucene.Net.Contrib" page, I see that you are not aware of the
> "simplistic implementations" of faceted search in contrib.
>
>
> DIGY
>
>
> On Thu, Jun 16, 2011 at 4:38 PM, Itamar Syn-Hershko<[EMAIL PROTECTED]>wrote:
>
>> Hi all,
>>
>> I created a new github repository where I'm dumping all extensions I write
>> or port from Java myself. The intention is having a community based
>> repository for all things Lucene.Net. I threw some stuff in already, and
>> will have some more soon. More details here:
>> http://www.code972.com/blog/2011/06/announcing-lucene-net-contrib/
>>
>> Code is at https://github.com/synhershko/Lucene.Net.Contrib
>>
>> Itamar.
>>

Hi Itamar,

On 2011-06-16, Itamar Syn-Hershko wrote:

>  Also, git is so much easier for projects of this sort, where
> community contributions is the center of things (unlike Lucene.Net, in
> which the product is). Forks and branches in SVN are a real pain...

First of all, I hope you've never had the impression community
contributions wouldn't be welcome to the ASF.  Actually we proud
ourselfs in providing community driven software and prefer to see the
community at the center of the project rather than the product.  In my
personal experience the source code becomes the center in github
projects and there doesn't seem to be much of interaction.  Maybe I've
been following the wrong projects.  And I'll be one of the first to
admit sometimes "code speaks loader than words".

Anyway.  Is it really a question of tools or one of direct access or is
there anything deeper beyond that?

If it was about tools, I'm sure you know there is a git mirror of the
Lucene.Net svn repository and maybe one day we'll even be able to use
git for write access (in the meantime git-svn may be able to help out).

The question of direct access for you is one that would likely resolve
itself if you kept pestering the committers with patches 8-).  Usually
this leads to "let him commit it himself" sooner or later.

> My goal is to publish extensions I find useful and hopefully to get or
> incorporate others' too. If for example I find a bug in
> FastVectorHighlighter and can't wait on a Lucene.Net release, I'd copy
> it from the original Contrib and fix it on my branch.

Maybe it would be better to push for bugfix releases of Lucene.Net
then.  But I get your point.

> I'm not trying to split resources, on the contrary.  As far as I'm
> concerned, you can incorporate my repo in contribs before every
> release.

Many thanks.

This has some legal implications as we've seen on another branch of this
thread and in the end we'd have to undergo the IP-clearance process each
time we pull in new code from your repository (at least we'd have to
verofy the changes since the last time code was pulled are "clean").

Cheers

        Stefan

I'm an active member of too many OSS projects as it is, and I can't
really become a committer in another one. The ASF's bureaucracy doesn't
help either.

It is also a matter of tools. Been working with SVN for years I can't
even look at it anymore now that I'm used to git, and no hacks can pay
for that. Seeing how code can evolve much faster and easier in github
than in ASF's infrastructure, I'm going to stay there for now.

Itamar.

On 17/06/2011 15:45, Stefan Bodewig wrote:
> Hi Itamar,
>
> On 2011-06-16, Itamar Syn-Hershko wrote:
>
>>   Also, git is so much easier for projects of this sort, where
>> community contributions is the center of things (unlike Lucene.Net, in
>> which the product is). Forks and branches in SVN are a real pain...
> First of all, I hope you've never had the impression community
> contributions wouldn't be welcome to the ASF.  Actually we proud
> ourselfs in providing community driven software and prefer to see the
> community at the center of the project rather than the product.  In my
> personal experience the source code becomes the center in github
> projects and there doesn't seem to be much of interaction.  Maybe I've
> been following the wrong projects.  And I'll be one of the first to
> admit sometimes "code speaks loader than words".
>
> Anyway.  Is it really a question of tools or one of direct access or is
> there anything deeper beyond that?
>
> If it was about tools, I'm sure you know there is a git mirror of the
> Lucene.Net svn repository and maybe one day we'll even be able to use
> git for write access (in the meantime git-svn may be able to help out).
>
> The question of direct access for you is one that would likely resolve
> itself if you kept pestering the committers with patches 8-).  Usually
> this leads to "let him commit it himself" sooner or later.
>
>> My goal is to publish extensions I find useful and hopefully to get or
>> incorporate others' too. If for example I find a bug in
>> FastVectorHighlighter and can't wait on a Lucene.Net release, I'd copy
>> it from the original Contrib and fix it on my branch.
> Maybe it would be better to push for bugfix releases of Lucene.Net
> then.  But I get your point.
>
>> I'm not trying to split resources, on the contrary.  As far as I'm
>> concerned, you can incorporate my repo in contribs before every
>> release.
> Many thanks.
>
> This has some legal implications as we've seen on another branch of this
> thread and in the end we'd have to undergo the IP-clearance process each
> time we pull in new code from your repository (at least we'd have to
> verofy the changes since the last time code was pulled are "clean").
>
> Cheers
>
>          Stefan
>
>

Digy has been extremely quick to update the 2
9.4g branch with additions posted to jira as well as bug fixes.

The main branch is slower to move at the moment because we are letting it bake before we release it as a binary.

I would urge you to keep you contributions here by creating a jira issue and attaching your patch. If you're really going to be doing a lot consider trying to join us as a committer

At the end of the day while I think it would be great that we are all in one place, I welcome your enthusiasm for the project.

If you decide to stay at git are you keeping extensions under the asf license? And could we include them in our contrib from time to time?

-Prescott

Sent from my Windows Phone

-----Original Message-----
From: Itamar Syn-Hershko
Sent: Thursday, June 16, 2011 8:01 AM
To: [EMAIL PROTECTED]
Subject: Re: [Lucene.Net] Announcing Lucene.Net.Contrib

> To cite my blog post:
>
>
> "This is not trying to compete with Lucene.Net's contrib section, it is
> just intended in being much more flexible, fast growing community of
> extensions, most probably will be small in size."
>
>
> The .NET community is not around Apache as much as the Java community
> is. It is much easier to get to it via github and nuget, and it is
> impossible to do that in slow release cycles. Also, git is so much
> easier for projects of this sort, where community contributions is the
> center of things (unlike Lucene.Net, in which the product is). Forks and
> branches in SVN are a real pain...
>
>
> My goal is to publish extensions I find useful and hopefully to get or
> incorporate others' too. If for example I find a bug in
> FastVectorHighlighter and can't wait on a Lucene.Net release, I'd copy
> it from the original Contrib and fix it on my branch. I don't think all
> changes justify that, hence my latest patch was submitted to JIRA.
>
>
> I'm not trying to split resources, on the contrary. As far as I'm
> concerned, you can incorporate my repo in contribs before every release.
>
>
> Itamar.
>
>
> On 16/06/2011 17:47, digy digy wrote:
>
>> In fact, there is a repo in contrib for this purpose. "core". (I know a
>> better name is needed)
>> https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net_2_9_4g/src/contrib
>>
>> IMO, all community contributions should be at one place (Apache) to avoid
>> confusions,  since there are already a lot of Lucene.Net related
>> codes/repositories around(  ActiveLuceneNet, LuceneWrap, LinqToLucene, Azure
>> Library for Lucene.Net, HebMorph :) etc. ). For ex., looking at your
>> "Announcing: Lucene.Net.Contrib" page, I see that you are not aware of the
>> "simplistic implementations" of faceted search in contrib.
>>
>>
>> DIGY
>>
>>
>> On Thu, Jun 16, 2011 at 4:38 PM, Itamar Syn-Hershko<[EMAIL PROTECTED]>wrote:
>>
>>> Hi all,
>>>
>>> I created a new github repository where I'm dumping all extensions I write
>>> or port from Java myself. The intention is having a community based
>>> repository for all things Lucene.Net. I threw some stuff in already, and
>>> will have some more soon. More details here:
>>> http://www.code972.com/blog/2011/06/announcing-lucene-net-contrib/
>>>
>>> Code is at https://github.com/synhershko/Lucene.Net.Contrib
>>>
>>> Itamar.
>>>

I think this is the best way to get exposure and be able to evolve, and
I feel much more comfortable with git than SVN and the JIRA bureaucracy.
As I said in my previous e-mail you're more than welcome to grab my repo
into the main contrib project. At the moment everything is ASL, and the
intention is to keep it that way (at least, only permissive licenses;
the hyphenation library I'll bring in is MIT).
Itamar.
On 16/06/2011 19:16, Prescott Nasser wrote:

> Digy has been extremely quick to update the 2
> 9.4g branch with additions posted to jira as well as bug fixes.
>
> The main branch is slower to move at the moment because we are letting it bake before we release it as a binary.
>
> I would urge you to keep you contributions here by creating a jira issue and attaching your patch. If you're really going to be doing a lot consider trying to join us as a committer
>
> At the end of the day while I think it would be great that we are all in one place, I welcome your enthusiasm for the project.
>
> If you decide to stay at git are you keeping extensions under the asf license? And could we include them in our contrib from time to time?
>
> -Prescott
>
> Sent from my Windows Phone
>
> -----Original Message-----
> From: Itamar Syn-Hershko
> Sent: Thursday, June 16, 2011 8:01 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [Lucene.Net] Announcing Lucene.Net.Contrib
>
>
>
>> To cite my blog post:
>>
>>
>> "This is not trying to compete with Lucene.Net's contrib section, it is
>> just intended in being much more flexible, fast growing community of
>> extensions, most probably will be small in size."
>>
>>
>> The .NET community is not around Apache as much as the Java community
>> is. It is much easier to get to it via github and nuget, and it is
>> impossible to do that in slow release cycles. Also, git is so much
>> easier for projects of this sort, where community contributions is the
>> center of things (unlike Lucene.Net, in which the product is). Forks and
>> branches in SVN are a real pain...
>>
>>
>> My goal is to publish extensions I find useful and hopefully to get or
>> incorporate others' too. If for example I find a bug in
>> FastVectorHighlighter and can't wait on a Lucene.Net release, I'd copy
>> it from the original Contrib and fix it on my branch. I don't think all
>> changes justify that, hence my latest patch was submitted to JIRA.
>>
>>
>> I'm not trying to split resources, on the contrary. As far as I'm
>> concerned, you can incorporate my repo in contribs before every release.
>>
>>
>> Itamar.
>>
>>
>> On 16/06/2011 17:47, digy digy wrote:
>>
>>> In fact, there is a repo in contrib for this purpose. "core". (I know a
>>> better name is needed)
>>> https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net_2_9_4g/src/contrib
>>>
>>> IMO, all community contributions should be at one place (Apache) to avoid
>>> confusions,  since there are already a lot of Lucene.Net related
>>> codes/repositories around(  ActiveLuceneNet, LuceneWrap, LinqToLucene, Azure
>>> Library for Lucene.Net, HebMorph :) etc. ). For ex., looking at your
>>> "Announcing: Lucene.Net.Contrib" page, I see that you are not aware of the
>>> "simplistic implementations" of faceted search in contrib.
>>>
>>>
>>> DIGY
>>>
>>>
>>> On Thu, Jun 16, 2011 at 4:38 PM, Itamar Syn-Hershko<[EMAIL PROTECTED]>wrote:
>>>
>>>> Hi all,
>>>>
>>>> I created a new github repository where I'm dumping all extensions I write
>>>> or port from Java myself. The intention is having a community based
>>>> repository for all things Lucene.Net. I threw some stuff in already, and
>>>> will have some more soon. More details here:
>>>> http://www.code972.com/blog/2011/06/announcing-lucene-net-contrib/
>>>>
>>>> Code is at https://github.com/synhershko/Lucene.Net.Contrib
>>>>
>>>> Itamar.
>>>>
>

Itamar,

This sounds like a great idea. I agree with DIGY that the best way to work
is for contributors to prepare patches and attach them to JIRA tickets. We
can then review and commit those patches in our normal way. That said, I
think your idea of maintaining a separate repo is still a good idea. You're
right that it's easier to work with and will attract more attention on
GitHub. The main thing we care about is facilitating work getting done on
the library, so we want to make that as easy as possible.

For us to accept your work into the Lucene.Net repo, we would need you to
either submit a one-time CLA (Contributor License Agreement), which will
cover any contributions you wish to provide on this project or others, or a
SGA (Software Grant Agreement) for just this Contrib project.

After we have a CLA/SGA in place, then we could easily pull from your GitHub
repo, and apply patches to Contrib/Core on whatever schedule we are making
releases. You can work at your pace, and we can work at ours. Everyone wins!

For CLA/SGA details see:

http://www.apache.org/licenses/#clas

In a nutshell, though, the easiest way to accomplish this is to pick one of
those agreements, print it off, fill in the blanks and sign, scan back in,
then email to [EMAIL PROTECTED] and [EMAIL PROTECTED] .

After that has been taken care of, just let us know when a particular
feature's changeset is ready, and we can pull it down, make a patch, and go
through our normal process.

Thanks,
Troy
On Thu, Jun 16, 2011 at 9:48 AM, Itamar Syn-Hershko <[EMAIL PROTECTED]>wrote:

> I think this is the best way to get exposure and be able to evolve, and I
> feel much more comfortable with git than SVN and the JIRA bureaucracy.
>
>
> As I said in my previous e-mail you're more than welcome to grab my repo
> into the main contrib project. At the moment everything is ASL, and the
> intention is to keep it that way (at least, only permissive licenses; the
> hyphenation library I'll bring in is MIT).
>
>
> Itamar.
>
>
>
> On 16/06/2011 19:16, Prescott Nasser wrote:
>
>  Digy has been extremely quick to update the 2
>> 9.4g branch with additions posted to jira as well as bug fixes.
>>
>> The main branch is slower to move at the moment because we are letting it
>> bake before we release it as a binary.
>>
>> I would urge you to keep you contributions here by creating a jira issue
>> and attaching your patch. If you're really going to be doing a lot consider
>> trying to join us as a committer
>>
>> At the end of the day while I think it would be great that we are all in
>> one place, I welcome your enthusiasm for the project.
>>
>> If you decide to stay at git are you keeping extensions under the asf
>> license? And could we include them in our contrib from time to time?
>>
>> -Prescott
>>
>> Sent from my Windows Phone
>>
>> -----Original Message-----
>> From: Itamar Syn-Hershko
>> Sent: Thursday, June 16, 2011 8:01 AM
>> To: [EMAIL PROTECTED]he.**org<[EMAIL PROTECTED]>
>> Subject: Re: [Lucene.Net] Announcing Lucene.Net.Contrib
>>
>>
>>
>>  To cite my blog post:
>>>
>>>
>>> "This is not trying to compete with Lucene.Net's contrib section, it is
>>> just intended in being much more flexible, fast growing community of
>>> extensions, most probably will be small in size."
>>>
>>>
>>> The .NET community is not around Apache as much as the Java community
>>> is. It is much easier to get to it via github and nuget, and it is
>>> impossible to do that in slow release cycles. Also, git is so much
>>> easier for projects of this sort, where community contributions is the
>>> center of things (unlike Lucene.Net, in which the product is). Forks and
>>> branches in SVN are a real pain...
>>>
>>>
>>> My goal is to publish extensions I find useful and hopefully to get or
>>> incorporate others' too. If for example I find a bug in
>>> FastVectorHighlighter and can't wait on a Lucene.Net release, I'd copy
>>> it from the original Contrib and fix it on my branch. I don't think all

Troy, no problem.
The repo may contain code from others, which I took from other projects
or merged from forks. I'm no lawyer but just to make sure this will
still work for you if all code is ASL?
Itamar.
On 16/06/2011 22:51, Troy Howard wrote:

> Itamar,
>
> This sounds like a great idea. I agree with DIGY that the best way to work
> is for contributors to prepare patches and attach them to JIRA tickets. We
> can then review and commit those patches in our normal way. That said, I
> think your idea of maintaining a separate repo is still a good idea. You're
> right that it's easier to work with and will attract more attention on
> GitHub. The main thing we care about is facilitating work getting done on
> the library, so we want to make that as easy as possible.
>
> For us to accept your work into the Lucene.Net repo, we would need you to
> either submit a one-time CLA (Contributor License Agreement), which will
> cover any contributions you wish to provide on this project or others, or a
> SGA (Software Grant Agreement) for just this Contrib project.
>
> After we have a CLA/SGA in place, then we could easily pull from your GitHub
> repo, and apply patches to Contrib/Core on whatever schedule we are making
> releases. You can work at your pace, and we can work at ours. Everyone wins!
>
> For CLA/SGA details see:
>
> http://www.apache.org/licenses/#clas
>
> In a nutshell, though, the easiest way to accomplish this is to pick one of
> those agreements, print it off, fill in the blanks and sign, scan back in,
> then email to [EMAIL PROTECTED] and [EMAIL PROTECTED] .
>
> After that has been taken care of, just let us know when a particular
> feature's changeset is ready, and we can pull it down, make a patch, and go
> through our normal process.
>
> Thanks,
> Troy
>
>
> On Thu, Jun 16, 2011 at 9:48 AM, Itamar Syn-Hershko<[EMAIL PROTECTED]>wrote:
>
>> I think this is the best way to get exposure and be able to evolve, and I
>> feel much more comfortable with git than SVN and the JIRA bureaucracy.
>>
>>
>> As I said in my previous e-mail you're more than welcome to grab my repo
>> into the main contrib project. At the moment everything is ASL, and the
>> intention is to keep it that way (at least, only permissive licenses; the
>> hyphenation library I'll bring in is MIT).
>>
>>
>> Itamar.
>>
>>
>>
>> On 16/06/2011 19:16, Prescott Nasser wrote:
>>
>>   Digy has been extremely quick to update the 2
>>> 9.4g branch with additions posted to jira as well as bug fixes.
>>>
>>> The main branch is slower to move at the moment because we are letting it
>>> bake before we release it as a binary.
>>>
>>> I would urge you to keep you contributions here by creating a jira issue
>>> and attaching your patch. If you're really going to be doing a lot consider
>>> trying to join us as a committer
>>>
>>> At the end of the day while I think it would be great that we are all in
>>> one place, I welcome your enthusiasm for the project.
>>>
>>> If you decide to stay at git are you keeping extensions under the asf
>>> license? And could we include them in our contrib from time to time?
>>>
>>> -Prescott
>>>
>>> Sent from my Windows Phone
>>>
>>> -----Original Message-----
>>> From: Itamar Syn-Hershko
>>> Sent: Thursday, June 16, 2011 8:01 AM
>>> To: [EMAIL PROTECTED]he.**org<[EMAIL PROTECTED]>
>>> Subject: Re: [Lucene.Net] Announcing Lucene.Net.Contrib
>>>
>>>
>>>
>>>   To cite my blog post:
>>>>
>>>> "This is not trying to compete with Lucene.Net's contrib section, it is
>>>> just intended in being much more flexible, fast growing community of
>>>> extensions, most probably will be small in size."
>>>>
>>>>
>>>> The .NET community is not around Apache as much as the Java community
>>>> is. It is much easier to get to it via github and nuget, and it is
>>>> impossible to do that in slow release cycles. Also, git is so much
>>>> easier for projects of this sort, where community contributions is the
>>>> center of things (unlike Lucene.Net, in which the product is). Forks and

Well, having all the code as ASL helps a lot, but the difference here is
about ownership of the code. Anything that goes into the ASF repo must be
owned by the ASF. Using the ASL doesn't state ownership by the ASF, merely
terms of use.

In order for individual contributions to be owned by the ASF the author must
legally donate the code. That's the purpose of the CLA/SGA. Each individual
(or corporation) who owns code which is submitted, must also execute a
CLA/SGA. This could be a problem in terms of external libraries written (and
owned) by someone other than ASF or yourself.

Anyhow, this is my understanding of it.

Thanks,
Troy

On Thu, Jun 16, 2011 at 12:59 PM, Itamar Syn-Hershko <[EMAIL PROTECTED]>wrote:

> Troy, no problem.
>
>
> The repo may contain code from others, which I took from other projects or
> merged from forks. I'm no lawyer but just to make sure this will still work
> for you if all code is ASL?
>
>
> Itamar.
>
>
>
> On 16/06/2011 22:51, Troy Howard wrote:
>
>  Itamar,
>>
>> This sounds like a great idea. I agree with DIGY that the best way to work
>> is for contributors to prepare patches and attach them to JIRA tickets. We
>> can then review and commit those patches in our normal way. That said, I
>> think your idea of maintaining a separate repo is still a good idea.
>> You're
>> right that it's easier to work with and will attract more attention on
>> GitHub. The main thing we care about is facilitating work getting done on
>> the library, so we want to make that as easy as possible.
>>
>> For us to accept your work into the Lucene.Net repo, we would need you to
>> either submit a one-time CLA (Contributor License Agreement), which will
>> cover any contributions you wish to provide on this project or others, or
>> a
>> SGA (Software Grant Agreement) for just this Contrib project.
>>
>> After we have a CLA/SGA in place, then we could easily pull from your
>> GitHub
>> repo, and apply patches to Contrib/Core on whatever schedule we are making
>> releases. You can work at your pace, and we can work at ours. Everyone
>> wins!
>>
>> For CLA/SGA details see:
>>
>> http://www.apache.org/**licenses/#clas<http://www.apache.org/licenses/#clas>
>>
>> In a nutshell, though, the easiest way to accomplish this is to pick one
>> of
>> those agreements, print it off, fill in the blanks and sign, scan back in,
>> then email to [EMAIL PROTECTED] and [EMAIL PROTECTED] .
>>
>> After that has been taken care of, just let us know when a particular
>> feature's changeset is ready, and we can pull it down, make a patch, and
>> go
>> through our normal process.
>>
>> Thanks,
>> Troy
>>
>>
>> On Thu, Jun 16, 2011 at 9:48 AM, Itamar Syn-Hershko<[EMAIL PROTECTED]**
>> >wrote:
>>
>>  I think this is the best way to get exposure and be able to evolve, and I
>>> feel much more comfortable with git than SVN and the JIRA bureaucracy.
>>>
>>>
>>> As I said in my previous e-mail you're more than welcome to grab my repo
>>> into the main contrib project. At the moment everything is ASL, and the
>>> intention is to keep it that way (at least, only permissive licenses; the
>>> hyphenation library I'll bring in is MIT).
>>>
>>>
>>> Itamar.
>>>
>>>
>>>
>>> On 16/06/2011 19:16, Prescott Nasser wrote:
>>>
>>>  Digy has been extremely quick to update the 2
>>>
>>>> 9.4g branch with additions posted to jira as well as bug fixes.
>>>>
>>>> The main branch is slower to move at the moment because we are letting
>>>> it
>>>> bake before we release it as a binary.
>>>>
>>>> I would urge you to keep you contributions here by creating a jira issue
>>>> and attaching your patch. If you're really going to be doing a lot
>>>> consider
>>>> trying to join us as a committer
>>>>
>>>> At the end of the day while I think it would be great that we are all in
>>>> one place, I welcome your enthusiasm for the project.
>>>>
>>>> If you decide to stay at git are you keeping extensions under the asf
>>>> license? And could we include them in our contrib from time to time?

Makes sense. Well, I suggest you guys will look into that. I will sign
the agreement soon and will let you know what code is not mine and not
covered by my agreement (but perhaps already by another one).
Itamar.
On 16/06/2011 23:17, Troy Howard wrote:

> Well, having all the code as ASL helps a lot, but the difference here is
> about ownership of the code. Anything that goes into the ASF repo must be
> owned by the ASF. Using the ASL doesn't state ownership by the ASF, merely
> terms of use.
>
> In order for individual contributions to be owned by the ASF the author must
> legally donate the code. That's the purpose of the CLA/SGA. Each individual
> (or corporation) who owns code which is submitted, must also execute a
> CLA/SGA. This could be a problem in terms of external libraries written (and
> owned) by someone other than ASF or yourself.
>
> Anyhow, this is my understanding of it.
>
> Thanks,
> Troy
>
> On Thu, Jun 16, 2011 at 12:59 PM, Itamar Syn-Hershko<[EMAIL PROTECTED]>wrote:
>
>> Troy, no problem.
>>
>>
>> The repo may contain code from others, which I took from other projects or
>> merged from forks. I'm no lawyer but just to make sure this will still work
>> for you if all code is ASL?
>>
>>
>> Itamar.
>>
>>
>>
>> On 16/06/2011 22:51, Troy Howard wrote:
>>
>>   Itamar,
>>> This sounds like a great idea. I agree with DIGY that the best way to work
>>> is for contributors to prepare patches and attach them to JIRA tickets. We
>>> can then review and commit those patches in our normal way. That said, I
>>> think your idea of maintaining a separate repo is still a good idea.
>>> You're
>>> right that it's easier to work with and will attract more attention on
>>> GitHub. The main thing we care about is facilitating work getting done on
>>> the library, so we want to make that as easy as possible.
>>>
>>> For us to accept your work into the Lucene.Net repo, we would need you to
>>> either submit a one-time CLA (Contributor License Agreement), which will
>>> cover any contributions you wish to provide on this project or others, or
>>> a
>>> SGA (Software Grant Agreement) for just this Contrib project.
>>>
>>> After we have a CLA/SGA in place, then we could easily pull from your
>>> GitHub
>>> repo, and apply patches to Contrib/Core on whatever schedule we are making
>>> releases. You can work at your pace, and we can work at ours. Everyone
>>> wins!
>>>
>>> For CLA/SGA details see:
>>>
>>> http://www.apache.org/**licenses/#clas<http://www.apache.org/licenses/#clas>
>>>
>>> In a nutshell, though, the easiest way to accomplish this is to pick one
>>> of
>>> those agreements, print it off, fill in the blanks and sign, scan back in,
>>> then email to [EMAIL PROTECTED] and [EMAIL PROTECTED] .
>>>
>>> After that has been taken care of, just let us know when a particular
>>> feature's changeset is ready, and we can pull it down, make a patch, and
>>> go
>>> through our normal process.
>>>
>>> Thanks,
>>> Troy
>>>
>>>
>>> On Thu, Jun 16, 2011 at 9:48 AM, Itamar Syn-Hershko<[EMAIL PROTECTED]**
>>>> wrote:
>>>   I think this is the best way to get exposure and be able to evolve, and I
>>>> feel much more comfortable with git than SVN and the JIRA bureaucracy.
>>>>
>>>>
>>>> As I said in my previous e-mail you're more than welcome to grab my repo
>>>> into the main contrib project. At the moment everything is ASL, and the
>>>> intention is to keep it that way (at least, only permissive licenses; the
>>>> hyphenation library I'll bring in is MIT).
>>>>
>>>>
>>>> Itamar.
>>>>
>>>>
>>>>
>>>> On 16/06/2011 19:16, Prescott Nasser wrote:
>>>>
>>>>   Digy has been extremely quick to update the 2
>>>>
>>>>> 9.4g branch with additions posted to jira as well as bug fixes.
>>>>>
>>>>> The main branch is slower to move at the moment because we are letting
>>>>> it
>>>>> bake before we release it as a binary.
>>>>>
>>>>> I would urge you to keep you contributions here by creating a jira issue
>>>>> and attaching your patch. If you're really going to be doing a lot

On 2011-06-16, Troy Howard wrote:

> Well, having all the code as ASL helps a lot, but the difference here is
> about ownership of the code. Anything that goes into the ASF repo must be
> owned by the ASF.

No, this is not true.  It has to be licensed to the ASF, that's all.
The ASF doesn't do copyright assignments.

> In order for individual contributions to be owned by the ASF the author must
> legally donate the code. That's the purpose of the CLA/SGA.

The CLA goes beyond the license when it comes to protection of
"intellectual property".  By signing a CLA you state that all IP you add
to the ASF repo is either yours or can legally be shared by yourself.

The ASF does require IP-clearance before allowing code into the ASF
repo, so yes, before we could pull in anything from Itamar's git repo
he'd have to sign a CLA and chase down other contributors using the
process described in http://incubator.apache.org/ip-clearance/index.html

Again, this is not about ownership but about IP protection.

While we are at the topic of "owership".  Itamar, if you look at the
bottom of Lucene.Net's home page you'll see among other things
"Apache Lucene.Net, Lucene.Net ... are trademarks of the Apache Software
Foundation".  Please see http://www.apache.org/foundation/marks/ for the
ASF's policy on trademarks.

Strictly speaking you'd need to ask for permission if you wanted to keep
the Lucene.Net.Contrib name, it may be better to change that early on.
One thing that I'd like to ask you to change is the description on the
main github page.  Please note it is "Apache Lucene" and "Apache
Lucene.Net" and please add a trademark attribution somewhere on your
page.

I'm not a lawyer and I really don't take any joy from asking you to do
that either, it's just that wee need to make sure our marks are used
consistent with our policy.

Cheers

        Stefan

OK, now this is nitpicking, really.

I never imagined in the open-source world I will have to argue about a
permission to use a particular name for a project I create. And I do not
intend on doing so. If the ASF wants to grant permission, it'd be nice.
If not, I'd either won't care or would put that project down. I really
don't have time to play such games. I release code as open-source
because I believe in OSS, instead of keeping it to myself and save quite
a lot of time. The ASF should encourage such complementary actions /
projects, not condemn them.

I don't mind adding "Apache" to the wording there, but I'm going to do
nothing further with this.

Itamar.
On 17/06/2011 15:25, Stefan Bodewig wrote:

> On 2011-06-16, Troy Howard wrote:
>
>> Well, having all the code as ASL helps a lot, but the difference here is
>> about ownership of the code. Anything that goes into the ASF repo must be
>> owned by the ASF.
> No, this is not true.  It has to be licensed to the ASF, that's all.
> The ASF doesn't do copyright assignments.
>
>> In order for individual contributions to be owned by the ASF the author must
>> legally donate the code. That's the purpose of the CLA/SGA.
> The CLA goes beyond the license when it comes to protection of
> "intellectual property".  By signing a CLA you state that all IP you add
> to the ASF repo is either yours or can legally be shared by yourself.
>
> The ASF does require IP-clearance before allowing code into the ASF
> repo, so yes, before we could pull in anything from Itamar's git repo
> he'd have to sign a CLA and chase down other contributors using the
> process described in http://incubator.apache.org/ip-clearance/index.html
>
> Again, this is not about ownership but about IP protection.
>
> While we are at the topic of "owership".  Itamar, if you look at the
> bottom of Lucene.Net's home page you'll see among other things
> "Apache Lucene.Net, Lucene.Net ... are trademarks of the Apache Software
> Foundation".  Please see http://www.apache.org/foundation/marks/ for the
> ASF's policy on trademarks.
>
> Strictly speaking you'd need to ask for permission if you wanted to keep
> the Lucene.Net.Contrib name, it may be better to change that early on.
> One thing that I'd like to ask you to change is the description on the
> main github page.  Please note it is "Apache Lucene" and "Apache
> Lucene.Net" and please add a trademark attribution somewhere on your
> page.
>
> I'm not a lawyer and I really don't take any joy from asking you to do
> that either, it's just that wee need to make sure our marks are used
> consistent with our policy.
>
> Cheers
>
>          Stefan
>
>

Hi Itamar,

IMO, the main problem here is not about licensing.
Suppose that you developed two excellent contribs, Regex & FacetedSearch
(from previous eMails I know that you didn't know they already existed in Lucene.Net), and put them in your repository.

Then, how would Lucene.Net users determine which one to use? which is better? which will be supported longer?

I don't want to say Apache repo. is better, just to emphasize the possible confusion.

Anyway, it is good to see people working on Lucene.Net.

DIGY

-----Original Message-----
From: Itamar Syn-Hershko [mailto:[EMAIL PROTECTED]]
Sent: Thursday, June 16, 2011 7:48 PM
To: [EMAIL PROTECTED]
Subject: Re: [Lucene.Net] Announcing Lucene.Net.Contrib

I think this is the best way to get exposure and be able to evolve, and
I feel much more comfortable with git than SVN and the JIRA bureaucracy.
As I said in my previous e-mail you're more than welcome to grab my repo
into the main contrib project. At the moment everything is ASL, and the
intention is to keep it that way (at least, only permissive licenses;
the hyphenation library I'll bring in is MIT).
Itamar.
On 16/06/2011 19:16, Prescott Nasser wrote:

> Digy has been extremely quick to update the 2
> 9.4g branch with additions posted to jira as well as bug fixes.
>
> The main branch is slower to move at the moment because we are letting it bake before we release it as a binary.
>
> I would urge you to keep you contributions here by creating a jira issue and attaching your patch. If you're really going to be doing a lot consider trying to join us as a committer
>
> At the end of the day while I think it would be great that we are all in one place, I welcome your enthusiasm for the project.
>
> If you decide to stay at git are you keeping extensions under the asf license? And could we include them in our contrib from time to time?
>
> -Prescott
>
> Sent from my Windows Phone
>
> -----Original Message-----
> From: Itamar Syn-Hershko
> Sent: Thursday, June 16, 2011 8:01 AM
> To: [EMAIL PROTECTED]
> Subject: Re: [Lucene.Net] Announcing Lucene.Net.Contrib
>
>
>
>> To cite my blog post:
>>
>>
>> "This is not trying to compete with Lucene.Net's contrib section, it is
>> just intended in being much more flexible, fast growing community of
>> extensions, most probably will be small in size."
>>
>>
>> The .NET community is not around Apache as much as the Java community
>> is. It is much easier to get to it via github and nuget, and it is
>> impossible to do that in slow release cycles. Also, git is so much
>> easier for projects of this sort, where community contributions is the
>> center of things (unlike Lucene.Net, in which the product is). Forks and
>> branches in SVN are a real pain...
>>
>>
>> My goal is to publish extensions I find useful and hopefully to get or
>> incorporate others' too. If for example I find a bug in
>> FastVectorHighlighter and can't wait on a Lucene.Net release, I'd copy
>> it from the original Contrib and fix it on my branch. I don't think all
>> changes justify that, hence my latest patch was submitted to JIRA.
>>
>>
>> I'm not trying to split resources, on the contrary. As far as I'm
>> concerned, you can incorporate my repo in contribs before every release.
>>
>>
>> Itamar.
>>
>>
>> On 16/06/2011 17:47, digy digy wrote:
>>
>>> In fact, there is a repo in contrib for this purpose. "core". (I know a
>>> better name is needed)
>>> https://svn.apache.org/repos/asf/incubator/lucene.net/branches/Lucene.Net_2_9_4g/src/contrib
>>>
>>> IMO, all community contributions should be at one place (Apache) to avoid
>>> confusions,  since there are already a lot of Lucene.Net related
>>> codes/repositories around(  ActiveLuceneNet, LuceneWrap, LinqToLucene, Azure
>>> Library for Lucene.Net, HebMorph :) etc. ). For ex., looking at your
>>> "Announcing: Lucene.Net.Contrib" page, I see that you are not aware of the
>>> "simplistic implementations" of faceted search in contrib.

Digy, no worries, I will not create duplicate efforts. Regex and
FacetedSearch I never got to a point where I actually needed (yet), so I
wasn't looking too hard for them in the original contribs. But that is
also a great example for the issue I'm trying to solve here - iirc it
wasn't only me who failed to see them.
> Then, how would Lucene.Net users determine which one to use? which is better? which will be supported longer?
So, as I said, I will probably not fork anything that is currently
there, and whatever you grab from me you don't have currently, and
you'll be able to maintain just the same as if I had submitted a patch.

For example I think the HTMLStripCharFilter is a great addition, and I
have built a great sample app for HebMorph using it (will be up in a few
days), but I find it really annoying having to use SVN, JIRA and a huge
code base just to get it available for my project.

> Anyway, it is good to see people working on Lucene.Net.

Yeah, well, I'm actually more of a CLucene person, and I'm preparing
some surprises from that end too :)

Itamar.

Hi Itamar,

wow, I've really managed to screw up and send a completely different
message from what I intended to say.  For this I want to apologize.  I
never thought I'd manage to add to the "Apache is a beaurocracy" meme
but I obviously did.  I'm really sorry about that.

First of all I want to thank you for your contributions to Lucene.Net
and the service you do to the community at large by your contrib
project.

Unlike you I'm only an observer and haven't contributed anything of
substance to the project.  My official status as "mentor" will wear off
once Lucene.Net leaves the Incubator at which point I hope you will
still be around and be an important part of the community.

Feel free to ignore me as only one voice of many.

Still I feel I should try to explain what I intended to say the first
time around.

The ASF doesn't require ownership of contributed code
====================================================
Some other foundations, corporations doing open source projects or even
smaller indepent projects work by copyright assignments, the ASF does
not.  It solely relies on the license and contributor agreements.

Contributor License Agreements and IP-clearance
==============================================
For code that goes into the repository of the Apache Software Foundation
the ASF requires an audit trail for intellectual property rights.  The
ASF is not unique here - I once was contacted by the Eclipse
Foundations's legal team in my role as XMLUnit developer where they
wanted to clear the IP origin of XMLUnit in order to ship it with some
parts of Eclipse.

Knowing that the ASF has done its due dilligence with regard to IP is
important to many companies when they decide whether they want to use a
certain OSS project or not.  I guess this is more important in the US
but at ${work} I've had at least one customer who didn't allow us to use
a certain OSS library because they had doubts in its origin.

So while this may seem to be a burden it helps spreading the acceptance
of Apache projects in a wider context.

There is a different option for distributing your code
=====================================================
This is something I didn't say but should have said.

We only need an ICLA, a software grant or anything similar if Lucene.Net
wanted to assimilate your code and distribute it as an ASF release.
There is nothing that would prevent us from bundling your DLL with a
binary release of Lucene.Net and clearly mark it as yours (in the
LICENSE and NOTICE files) as your code is distributed under a license
that is clearly compatible with the Apache License.

Naming and Trademarks
====================
The main impetus here is to avoid confusion of users.  If there is a DLL
called Lucene.Net.Contrib.dll, users will expect it to be part of the
Apache Lucene.Net project.  In particular if there is a Contrib area in
Lucene.Net and a DLL of the same name is part of the official
distribution.

Personally I think it would be good if you found a different name for
your project to avoid this confusion.

Maybe I should have stopped with that in my inital email.

The ASF has chosen to use trademarks to avoid such confusion and in my
limited understanding of US trademark law (I'm neither a lawyer nor a US
citizen) you have to take certain actions to defend your trademarks so
they don't become void.

Even in the OSS world naming is not free.  You may recall that Mozilla
Firefox was called Firebird initially and changed its name so it didn't
collide with the SQL database of the same name.  There are other similar
cases as well.

Tools
====
I'm not involved enough in the infrastructure side of things but I know
work is underway ease git usage for ASF projects.

A central repo simply matches the way the ASF works and what our users
expect from it.  A single place with the official blessed source tree.

I absolutely appreciate your preference for a DVCS and actually share it
- even though git wouldn't be my personal choice here.

Stefan