lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "" <>
Subject Re: [Lucene.Net] Nuget, Lucene.Net, and Your Thoughts
Date Thu, 22 Sep 2011 14:27:19 GMT
Troy is indeed right in that I was referring to Neal's email and not yours. 
 That was a mistake on my part and anything that sprung from that mistake 
was unintended and I apologize for that.
For the rest, see inline.


The last e-mail was out of line and out of context. If anything, emails 
that can push people into emotional or motivational apathy towards working
on a project.
I believe it is debatable whether or not it was out of context; yes, the 
Nuget packages *are* being created, but people started to give sweeping 
generalizations about Nuget, so the out-of-context nature had already been 
established.  While not an excuse for continuing to be out-of-context, I 
felt it exposed a larger issue which I was trying to address. 
 I disagree that it was out of line.  Can emails like that push people into 
emotional or motivational apathy towards working on a project?  Yes, it 
absolutely can.  However, I feel that's part of the problem, there's 
already too much emotional and motivational apathy around working on the 
Lucene.NET project and my statements were to show example that I felt 
harbored that environment; I believe that saying something that needs to be 
heard takes precedence over whether or not the audience wants to hear it.

1) Lucene.Net will be getting nuget packages.   People can hate on it,
grumble, or not use it, but its a viable distribution vehicle. Its going 
  This thread was to gather feedback on how people that would use it, see
themselves using it.
Understood.  This is a very good thing.  See my previous comments on how 
the thread changed. 

2) Others might want alternatives to nuget that have not been provided 
 We should be open to providing distribution alternatives if enough people
warrant it.  Its not apathetic or impassive to think to that there might 
more than one way to distribute releases.
It was never implied that Nuget should be the only means of distribution.  
This falls outside the scope of the points I was trying to make.  FWIW, any 
distribution method that maintains the integrity of the project releases 
and helps to distribute those releases to the most people possible and also 
reduces the barrier to entry is a good thing. 

3) Attack problems. Not people. If you believe a person is the problem, 
the issue up with them offline. Those kinds of things are better face to
face or through a phone call, or an exceptionally clear e-mail. Its way 
easy for people to read into things too much or take things out of context
in an e-mail.
When the problem *is the people* (or at least, their opinions on the 
project which have an impact on it), then unfortunately, they are one in 
the same.  I believe there is a systemic problem with many of the opinions 
that prevent the growth of the project.  While I believe that those are the 
symptoms, it can't be argued that there *isn't* a problem with the project 
on some level, hence Lucene.NET going into incubation status. 
 I'm trying to point out an example of what I feel part (if not most or 
all) of the problem is.

Attacking people also distracts people from focusing on the actual issue 
prevents any actually logic or reason or sound argument from being heard.
 Its a good way to alienate people that you should actually be trying to
Agreed, but see above in reference to people or aspects of people being the 

4) If I was actually apathetic and severely short sighted, I would not be
spending my own vacation time this weekend automating nuget packages with
the build scripts for Lucene.Net or experimenting Portable Library Tools 
Lucene.Net 4.x to see if we can get it working on mobile.  Nor would I  
spent my last 4 day weekend setting up jenkins and local builds of
Lucene.Net.  Or put in the hours today to make sure the build scripts
are granular enough to implement the smaller packages.
Already addressed. 

5) If you feel so passionately about all this, why not work towards being 
contributor or committer and lead by example ?

When I first started using Lucene.NET, I did try to make a handful 
contributions, as well as had a few prolonged conversations about the 
process and vision of the project (at the time, it was to maintain a 
line-by-line port of the project). 
 At that point, the examples were not well-received (which was not 
something I took personally, it was simply a matter of not having 
compatible visions) nor did they foster leadership, so I diverted my 
energies elsewhere.  I might divert my energy back when I feel those 
visions are more compatible. 
 I've seen some underpinnings, but not enough, frankly, to warrant my 
participation as a contributor or committer to the project. 
 Also, it should be noted that my level of participation in the project is 
not relevant to providing an opinion as to why the project is struggling.  
I appreciate trying to encourage people to participate, but it shouldn't be 
veiled in that manner. 
 Nor should it be said that I'm not happy to see the changes in the project 
in the last year or that I don't value the project; both could be further 
from the truth, I just don't see (yet) what it takes to bring it to the 
next level, and ultimately, to the level of the Java project (where we 
would have things like Solr, elasticsearch, etc). 
 - Nick

- Michael

Since I'm the one implementing Nuget into the build process and I have not
played with the nuget server or creating a package, it just seem wise to
gather feedback on how people saw themselves using the contrib packages.

I agree, and I agree with Dan Swain's opinion on the matter; have contrib 
as a separate package (with a dependency on core, obviously) and separate 
certain contrib packages out when they are significant enough to stand on 
their own. 
 Additionally, I'd add that you have a Lucene.NET "all" package, which 
would wrap all of the packages/references up (it's pretty common practice, 
at least among a number of the packages that MS puts out, to have one 
package that has everything, see the Rx framework for an example).

On Wed, Sep 21, 2011 at 9:00 PM, Nicholas Paldino [.NET/C# MVP] <> wrote:

> With all due respect, it's myopic opinions like yours and Michael's (his
> leans more towards apathy) which will harm the ability to get the 
> into the hands of people.
> I think (hope?) it can be agreed upon that the more that people are 
> of
> Lucene.NET, the better it is for the project in general, and most
> importantly, the more potential that you have that someone will 
> back* to it (and given what Lucene.NET has gone through in the past 
> it
> desperately needs that participation).
> The fact of the matter is that Nuget puts packages in the hands of .NET
> developers, that leads to exposure and regardless of personal opinions 
> whether or not they *like* Nuget, it can't be denied that it's an
> *extremely* popular way to get libraries into people's projects.
> If you want to quibble over the actual numbers (and the definition of
> "extremely popular") then that's fine, but here are the numbers you 
> If you want to just tell that audience to take a leap, that's fine, but 
> think it would be foolish to do so otherwise.
> Additionally, given that Lucene.NET is already on Nuget, isn't there 
> concern that there isn't an official distro?  Aren't you concerned about
> the
> integrity of the brand that so many of you fought to keep alive over the
> past year?  There's no guarantee that what's on Nuget will be the 
> releases/builds that come out of this project, and I'm a little 
> there isn't more concern over that aspect either.
> Just my $0.02
> - Nick
> -----Original Message-----
> From: Digy []
> Sent: Wednesday, September 21, 2011 7:06 PM
> To:
> Subject: RE: [Lucene.Net] Nuget, Lucene.Net, and Your Thoughts
> I am not against it, but personally think it as a toy.
> I am from the generation where people used vi to write codes.
> -----Original Message-----
> From: Aaron Powell []
> Sent: Thursday, September 22, 2011 1:56 AM
> To:
> Subject: RE: [Lucene.Net] Nuget, Lucene.Net, and Your Thoughts
> Any particular reason you guys are not interested in NuGet?
> Aaron Powell
> MVP - Internet Explorer (Development) | FunnelWeb Team Member
> | | Skype: aaron.l.powell |
> Github | BitBucket
> -----Original Message-----
> From: Digy []
> Sent: Thursday, 22 September 2011 7:42 AM
> To:
> Subject: RE: [Lucene.Net] Nuget, Lucene.Net, and Your Thoughts
> Sorry, but I feel the same as Neal.
> -----Original Message-----
> From: Granroth, Neal V. []
> Sent: Wednesday, September 21, 2011 6:08 PM
> To:
> Subject: RE: [Lucene.Net] Nuget, Lucene.Net, and Your Thoughts
> No interest in Nuget whatsoever.
> - Neal
> -----Original Message-----
> From: Michael Herndon []
> Sent: Tuesday, September 20, 2011 10:57 PM
> To:;
> Subject: [Lucene.Net] Nuget, Lucene.Net, and Your Thoughts
> We're taking a quick poll over the next few days to see how people would
> like use Lucene.Net through Nuget on the developers mailing list**
> Currently version 2.9.2 is hosted on, but that package was not
> create by the project maintainers, thus nuget is not currently set up in
> source.  Going forward, we would like to continue what someone else 
> by creating nuget packages for Lucene.Net.
> Right now there are two packages: Lucene & Lucene.Contrib.  My question 
> the community is do you wish to finer grain packages, i.e. a package for
> each contrib project or continue to keep it simple.
> The granular approach will let you use only what you need. We can also
> create additional higher level packages which have dependencies on the
> other
> ones.   Possibly a Lucene.Net-Essentials and Lucene.Net-Full.
> Or we can keep it simple and continue with only two packages.
> My concerns are that the granular approach might overwhelm people with
> choice. The simple choice might be considered bloat for importing and 
> installing assemblies that you might never use.
> Another topic to converse about is would you like to see an out-of-band
> project nuget feed for  nightly builds, branches with new or 
> features, or stable code snapshots for a projected release?
> ** when you post, please respond to
>  This
> was posted to both lists to make sure everyone subscribed to both lists 
> a chance to voice their use cases or concerns.
> -----
> Checked by AVG -
> Version: 2012.0.1809 / Virus Database: 2085/4510 - Release Date: 
> -----
> Checked by AVG -
> Version: 2012.0.1809 / Virus Database: 2085/4510 - Release Date: 


  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message