lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Chiaretta <simone.chiare...@gmail.com>
Subject Re: [Lucene.Net] Graduation
Date Wed, 01 Feb 2012 20:10:12 GMT
If I had to vote, I'd vote against graduation at this point.

As other said, while the user base is pretty big, the dev community is relatively small and
still relying on just a few people.
Also all the accessories around a OSS projects are very difficult to maintain, probably due
to the strict environment of the foundation, like CMS, CI, source control and so on.
Also, there must be an official way of communicating to the user base, which is not the ML
or some sporadic news on the site or on other blogs.

But the main point is a lack of long term strategy that is shared by everyone: most OSS can
go along without such things, but Lucene.net is in a position where such strategy is needed.
Shall Lucene.net be just a port of the java lib, and evolving with it (and following the evolution
of the java language) or shall it just be inspired by it and go along with the pace of .NET,
which is much faster than the java one?
Shall Lucene.net keep on actively supporting companies still on .NET 2.0, or follow the evolution
and drop support of old versions and adopt the innovations coming with the newest releases?

Personally I think Lucene.net should go directly to the latest version available of Lucene
for java (which should have all the nice features like generics, lambda and such) and do as
everybody is doing regarding support: just do critical bug fixes on older version and just
support the latest or 2 latest versions of .NET (which now will be 4 and 3.5). But this is
probably not the right thread to discuss this topics.

Wrapping up, I'd say no to gradation until the strategy on these two points has been decided,
and a better communication strategy is in place.

Simone

---
Simone Chiaretta
@simonech
Sent from a tablet

On 01/feb/2012, at 20:37, Troy Howard <thoward37@gmail.com> wrote:

> I agree with Neal on both points:
> 
> - Repeatable, documented process: We need a better more defined,
> public and repeatable process for creating and building releases. As
> Prescott can attest to, figuring all that out at this point is
> non-trivial and poorly documented. We have a wider footprint now than
> ever before but we still have a long way to go in terms of solving our
> problems as a team/community/project.
> 
> - Committing to our decisions, despite alienating our user base: As
> Jesse pointed out, there are users out there who will be alienated by
> our choices, wether it be to use .Net 4.0 vs 2.0, use VS2010 vs
> VS2008/2005, change the API to make more sense in .NET, or what have
> you. We are going to have to make choices regarding the project
> direction, commit to those choices and move forward, even if it does
> mean alienating a certain portion of our user base. We don't like that
> consequence but we can't survive as a project without being decisive
> about controversial issues and moving forward.
> 
> The question I have to Stephan is, what are the significant criteria
> for moving a project from the Incubator to a TLP?
> 
> In my mind, we have the "minimum marketable feature set" to be a TLP,
> which is to say, we have an open dialog and an interested community
> while remaining somewhat productive. I don't think we need to wait to
> graduate until we have solved every challenge that we face as a
> project but rather we simply need to prove that we have what it takes
> to survive and grow in a healthy and productive manner as a community.
> I think we've achieved that part and just need to continue improving
> our process.
> 
> Thanks,
> Troy
> 
> 
> On Wed, Feb 1, 2012 at 11:11 AM, Granroth, Neal V.
> <neal.granroth@thermofisher.com> wrote:
>> Jesse,
>> 
>> Thanks for making that point.  I am also in that situation where I must support.NET
2.0 for years into the future.  While I can experiment with .NET 4.0, there are a number or
reasons that preclude its deployment or anything that depends upon it.
>> 
>> However, consider what the Lucene.NET developers are up against.  I think I am not
mistaken that the current version of Java, which the Lucene core project uses, now makes use
of features that have no equivalent in .NET 2.0; use of the newer versions of .NET are essential
in order to update Lucene.NET to the current version of Lucene.
>> 
>> At some point you, I, and others in our situation have to develop migration plans
to get our products (and customers) to upgrade to the newer versions of .NET
>> 
>> - Neal
>> 
>> -----Original Message-----
>> From: Jean-Sylvain Boige [mailto:jsboige@aricie.fr]
>> Sent: Wednesday, February 01, 2012 12:44 PM
>> To: lucene-net-dev@lucene.apache.org; lucene-net-dev@incubator.apache.org
>> Subject: RE: [Lucene.Net] Graduation
>> 
>> Hi all,
>> 
>> I'm not sure if it's the best moment for that, but here are my 2 cents.
>> I have the feeling that a lot was done recently, and that the project is
>> taking a good direction.
>> 
>> To reflect on your impression, the one example of how it could go wrong I'm
>> thinking of, where a few people invest in bursts and in their turn is
>> Sharpmap (http://sharpmap.codeplex.com/) It's been years than a couple of
>> committers are literally throwing thousands of lines of codes at that
>> project, with dozens of branches and each method refactored a couple of
>> time, but not a clean release since then, loads of inertia, and non
>> committers quite at lost.
>> 
>> I reckon the effort is better coordinated here, with clear incremental
>> steps.
>> 
>> However, when it was announced that the project could collapse, I reflected
>> that we were a quite a few consuming the lib, possibly interested in getting
>> involved, but striving to follow the upgrade path. By that time, v2.4 was
>> the common version around, and with 2.9.2 the upgrade path towards 3.0 by
>> replacing all the obsolete constructs was already a pain.
>> 
>> I know several integrators could not be bothered, yet we did make those
>> changes, and by the time we were finally ready to move on with the latest
>> upgrades, you guys added a constraint, which resulted in a complete show
>> stopper for us: .Net Framework 4.0. I understand that it feels natural for
>> anything fresh, but with that decision you probably lost those, who like us
>> have their products packaged with Lucene.Net in many existing environments
>> where moving to .Net 4.0 is neither an option nor a decision of ours.
>> 
>> Since then, we have kept investing into our 2.9.2 integration, but it will
>> be months at the very least until we can consider imposing .Net 4.0 as a
>> requirement for any further upgrades to our products.
>> I'm pretty sure there are quite a few of us in that situation, which feels a
>> bit similar to when we were many stuck with 2.4.1 constructs while help was
>> requested to upgrade past 2.9.2.
>> 
>> I guess you get the idea: it's a good thing if the project moves fast
>> because of a few committers deeply involved, but it's as important to make
>> sure most traditional integrators are following behind.
>> 
>> Cheers,
>> 
>> Jesse
>> 
>> 
>> 
>> -----Message d'origine-----
>> De : Prescott Nasser [mailto:geobmx540@hotmail.com]
>> Envoyé : mercredi 1 février 2012 18:38
>> À : lucene-net-dev@incubator.apache.org
>> Objet : [Lucene.Net] Graduation
>> 
>> Stefan has it on his agenda to get us to graduate, so I wanted to kick off a
>> conversation on how we feel about that - do we feel we are ready? Why/why
>> not. What are all the steps we need to take, etc.
>> 
>> My two cents, Im worried about the sustainability of our community. I feel
>> like we are a very small group working on this and that if one or two key
>> players left we'd be in a ton of trouble. We haven't really developed great
>> sustainable momentum, more like great bursts of effort then nothing for a
>> while.
>> 
>> We have also yet to fully determine the path we wish to take with the code
>> base, seems we are split with a line by line and something that more closely
>> resembles the .net world. I fear without determining our goals we might
>> fumble, which id rather do in the incubator.
>> 
>> -P
>> 

Mime
View raw message