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. <[email protected]> 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:[email protected]] > Sent: Wednesday, February 01, 2012 12:44 PM > To: [email protected]; [email protected] > 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:[email protected]] > Envoyé : mercredi 1 février 2012 18:38 > À : [email protected] > 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 >
