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

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

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

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

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 <[EMAIL PROTECTED]> 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.
> <[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.

Sorry again if this is not the right thread, but what feature of .Net 4.0 do you currently leverage that wouldn't compile on 3.5? (which would be fine for us)
Troy, can we really compare the impact of moving Lucene development to vs2010 to that of moving the user base to .Net 4.0 ?
Again, keep in mind that the best part of Lucene.Net libraries currently running are probably still 2.4.1, and IMHO trying to get a good part of those versions back up to date is not just a side option: enforcing .Net 4.0 was clearly a deal breaker for us so far, and reporting critical hints on 2.9.x obsolete constructs would be needed for those still behind, as I recall most of those comments were lost in the .Net port, and several pattern changes are just above your usual developer skills without the appropriate guidance.
Of course it's up to the integrators to make the effort to adapt to the new API when needed, but there should be a practical path for that, or beware the Sharpmap syndrome, where only the same handful of developers kept moving ahead with no one behind to push when the initial energy burst slowly faded.  

Anyway, thanks guys for making this live, and hopefully we can help at some point.

Cheers,

Jesse

-----Message d'origine-----
De : Simone Chiaretta [mailto:[EMAIL PROTECTED]]
Envoyé : mercredi 1 février 2012 21:10
À : [EMAIL PROTECTED]
Cc : [EMAIL PROTECTED]
Objet : Re: [Lucene.Net] Graduation

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 <[EMAIL PROTECTED]> 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

Hi,

On 02.02.2012 03:27, Jean-Sylvain Boige wrote:
> Sorry again if this is not the right thread, but what feature of .Net
> 4.0 do you currently leverage that wouldn't compile on 3.5? (which
> would be fine for us) Troy, can we really compare the impact of
> moving Lucene development to vs2010 to that of moving the user base
> to .Net 4.0 ? Again, keep in mind that the best part of Lucene.Net
> libraries currently running are probably still 2.4.1, and IMHO trying
> to get a good part of those versions back up to date is not just a
> side option: enforcing .Net 4.0 was clearly a deal breaker for us so

.NET 4.0 is only enforced by accident. There is only one place
where a bit of .NET 4.0 code is used (CloseableThreadLocal),
and there is an alternative for .NET <= 3.5 commented out in this
file.

I was able to compile 2.9.4 with the .NET 3.5 tool chanin
while targeting plain .NET 2.0 without any issue.

If someone is interested, I'd publish the necessary (minimal)
changes.

Robert

Hi Robert,

Thanks for letting us know, and I'm definitely interested in knowing the details about it.
Ideally again, if it's the only point of dependency on .Net 4.0 and there's a 3.5 alternative commented out, I'm all for making your change standard until there is a stronger motive for alienating the user base.

Regards,

Jesse

-----Message d'origine-----
De : Robert Jordan [mailto:[EMAIL PROTECTED]]
Envoyé : jeudi 2 février 2012 12:22
À : [EMAIL PROTECTED]
Objet : Re: [Lucene.Net] Graduation

Hi,

On 02.02.2012 03:27, Jean-Sylvain Boige wrote:
> Sorry again if this is not the right thread, but what feature of .Net
> 4.0 do you currently leverage that wouldn't compile on 3.5? (which
> would be fine for us) Troy, can we really compare the impact of moving
> Lucene development to vs2010 to that of moving the user base to .Net
> 4.0 ? Again, keep in mind that the best part of Lucene.Net libraries
> currently running are probably still 2.4.1, and IMHO trying to get a
> good part of those versions back up to date is not just a side option:
> enforcing .Net 4.0 was clearly a deal breaker for us so

.NET 4.0 is only enforced by accident. There is only one place where a bit of .NET 4.0 code is used (CloseableThreadLocal), and there is an alternative for .NET <= 3.5 commented out in this file.

I was able to compile 2.9.4 with the .NET 3.5 tool chanin while targeting plain .NET 2.0 without any issue.

If someone is interested, I'd publish the necessary (minimal) changes.

Robert

There seems to be an overall theme of the concern of number of committers.
I do agree with this.  I'm going throw out some suggestions. We could use
implementing any number of these as our graduation or maybe work towards
obtaining a certain number of new committers for 2012.

* Throw up a step by step instructions on the main site on how to
contribute. including how to become to committer.
* Mentorship program from committers to anyone who says they are interested
in contributing code.   Someone shows interest, one of the committers
either gets assigned or volunteers to follow up with that person.   Cookies
are for closers only. ABC.
* Hackathon - not so much hacking on the code base, but show off
applications or functionality have  built with Lucene.Net, maybe get some
sponsors, offer prizes.  Or maybe hold a 48 hour contest.  Something like
http://blog.railsrumble.com/     Maybe the first year we see who builds the
coolest demo applications (one category web, the other desktop).
* Develop/execute long term marketing strategy.
* Show up at an apache conference and hang out, announce any .NET events/UG
(user groups) that are doing meetings on Lucene.NET
* Dogfood the incubation / lucene.net site with search from Lucene.NET
* Blogroll going on the site (maybe use something like yahoo pipes to
create feeds from different bloggers and use JS to display it).

> but nowadays marketing and
> documenting an OSS project is as important (if not more) as developing it.
More important.

But what about a CI environment? with a public output?
There is a Lucene.net configuration on teamcity, but that's an unofficial
setup:
http://teamcity.codebetter.com/project.html?projectId=project56
I know probably here there is maven... but not very .net-like way of
working.

There is a CI with a few different builds at builds.apache.org, but its
painful to get it done when you can't log in to help out installing build
dependencies. Maybe co-app will change that in the future. Plus I'm more of
an a.d.d dev/designer. I'm not exactly wired for the devopts mentality,
though I tend to build dev tools and help with infra at work and end up
working in that arena.

After spending a few vacation weekends working on the CI and only getting
so far (which was my only vacation for 2011), I got kinda burned out on it.
 Its more complicated than most setups because we've taken a lowest common
denominator approach so that it will work for both Mono or .NET installs
even if a developer does not have all the tools installed.  The
incompleteness of the CI setup is my fault, but as soon as I get time and a
second wind I'll get back to working on it.  Its more of a continuous build
server at the moment.

 For example git support has reached a beta test phase by now with a few
> projects (those who raised their proverbial hands) trying it.  Trying it
> both from an infrastructure perspective but also experimenting how the
> different approach a DVCS brings mixes with ASF policies and practices.
> This took some time to land, partly because only one or two people were
> willing to make this happen.

I've been watching the threads on implementing git as SCM instead of just
having mirrors. very interesting discussions and there tons of details to
work out.   The process of creating diffs and patches, then uploading it
just seems painful to me when it comes to growth. So when git gains wider
adoption in the ASF, its going to help to lower that barrier.

On Fri, Feb 3, 2012 at 10:53 AM, Jean-Sylvain Boige <[EMAIL PROTECTED]>wrote:

> Hi Robert,
>
> Thanks for letting us know, and I'm definitely interested in knowing the
> details about it.
> Ideally again, if it's the only point of dependency on .Net 4.0 and
> there's a 3.5 alternative commented out, I'm all for making your change
> standard until there is a stronger motive for alienating the user base.
>
> Regards,
>
> Jesse
>
> -----Message d'origine-----
> De : Robert Jordan [mailto:[EMAIL PROTECTED]]
> Envoyé : jeudi 2 février 2012 12:22

On 2012-02-01, Simone Chiaretta wrote:

> As other said, while the user base is pretty big, the dev community is
> relatively small and still relying on just a few people.

Can you recommend an approach that would draw in more developers?  Is
there anything the current team should be doing or stop doing?

> 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.

I'm not sure I fully follow you here.  The choice of tools usually
follows what our infrastructure team can support.  It is possible to
introduce new tools to the mix if there are enough people who volunteer
to support it.

For example git support has reached a beta test phase by now with a few
projects (those who raised their proverbial hands) trying it.  Trying it
both from an infrastructure perspective but also experimenting how the
different approach a DVCS brings mixes with ASF policies and practices.
This took some time to land, partly because only one or two people were
willing to make this happen.

That being said, the infrastructure team is more likely to trust
committers of TLPs than incubator podlings - the latter might fail,
after all.  So a graduated Lucene.Net could have a bigger impact on
infrastructure options than one sitting inside the incubator.

Not sure what tools you are missing or deem inadequate, though, but that
would be for a different thread.

> 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.

What would you suggest?

Does this need to get solved before graduation?

> 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.

I agree the strategy must get decided on and be documented at one point,
but does this need to get solved before graduation?

Thanks

     Stefan

Mine below

On Thu, Feb 2, 2012 at 1:30 PM, Stefan Bodewig <[EMAIL PROTECTED]> wrote:

> On 2012-02-01, Simone Chiaretta wrote:
>
> > As other said, while the user base is pretty big, the dev community is
> > relatively small and still relying on just a few people.
>
> Can you recommend an approach that would draw in more developers?  Is
> there anything the current team should be doing or stop doing?
>

It think there is little that can be done here:
finding committees dedicated to help open source project is difficult,
especially if it is not something "cool" but just a server side library
nobody see.
I've seen that moving to a more "social" source control helps, like moving
to git or mercurial. Lucene.net is still on Subversion, and that makes
difficult for people to contribute sporadically. Actually hosting the
source on something like github would definitely help: but I think both
solutions are against the rules of the ASF: no external tools allowed.

Also, but that's again something we cannot change, working on a line by
line port of a java library, with no space to creativity is not super
exciting :)
> > 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.
>
> I'm not sure I fully follow you here.  The choice of tools usually
> follows what our infrastructure team can support.  It is possible to
> introduce new tools to the mix if there are enough people who volunteer
> to support it.
>
> For example git support has reached a beta test phase by now with a few
> projects (those who raised their proverbial hands) trying it.  Trying it
> both from an infrastructure perspective but also experimenting how the
> different approach a DVCS brings mixes with ASF policies and practices.
> This took some time to land, partly because only one or two people were
> willing to make this happen.
>
> That being said, the infrastructure team is more likely to trust
> committers of TLPs than incubator podlings - the latter might fail,
> after all.  So a graduated Lucene.Net could have a bigger impact on
> infrastructure options than one sitting inside the incubator.
>
> Not sure what tools you are missing or deem inadequate, though, but that
> would be for a different thread.
>

I'm not a committer, just someone that cares about Lucene.net but with not
much time.
Good to know there is a kind of git beta support.

But what about a CI environment? with a public output?
There is a Lucene.net configuration on teamcity, but that's an unofficial
setup:
http://teamcity.codebetter.com/project.html?projectId=project56
I know probably here there is maven... but not very .net-like way of
working.

Also the CMS, from my understanding, is kind of difficult to work with.
> > 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.
>
> What would you suggest?
>

Having a blog on the site, and have posts on what's going on, plans for the
future, to start discussions: I agree, probably the same thing already
happen on this or the user ML, but they definitely have much bigger
visibility than just something came straight from the '90s (the ML).
But from my understanding working on the current CMS makes having a blog
very complicate.
> Does this need to get solved before graduation?
>

I have no idea: by looking at the requirements probably not, but something
that IMHO has to be solved: bringing Lucene.net into years '10s, which
would also make it more appealing and fun to work with for possible
contributors.
I know probably all this sounds silly from a hard-core developer/OSS
fanatic/linux hacker point of view, but nowadays marketing and
documenting an OSS project is as important (if not more) as developing it.
> > 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

For this I think yes: otherwise we risk that Lucene.net "graduates",
whatever that means, and than committers are split by the decision to take,
and the project dies again, for the same reasons it was dying last year.

But again, since I don't have time for dealing with all that
stuff, especially all the bureaucratic procedures required by the ASF, I'm
just giving my advice, of someone that is deeply into the .NET community.
But the final word is to people that really spend their time on code and
administrative stuff.

Simone

Simone Chiaretta
Microsoft MVP ASP.NET - ASPInsider
Blog: http://codeclimber.net.nz
RSS: http://feeds2.feedburner.com/codeclimber
twitter: @simonech

Any sufficiently advanced technology is indistinguishable from magic
"Life is short, play hard"

[I started to write a really long response and then figured I should
split it to keep this thread focussed.]

On 2012-02-02, Simone Chiaretta wrote:

> On Thu, Feb 2, 2012 at 1:30 PM, Stefan Bodewig <[EMAIL PROTECTED]> wrote:

>> On 2012-02-01, Simone Chiaretta wrote:

>>> As other said, while the user base is pretty big, the dev community is
>>> relatively small and still relying on just a few people.

>> Can you recommend an approach that would draw in more developers?  Is
>> there anything the current team should be doing or stop doing?

> It think there is little that can be done here:
> finding committees dedicated to help open source project is difficult,
> especially if it is not something "cool" but just a server side library
> nobody see.

Yes, true.

> Also, but that's again something we cannot change, working on a line by
> line port of a java library, with no space to creativity is not super
> exciting :)

This I fully agree with.

> I'm not a committer, just someone that cares about Lucene.net but with not
> much time.

And both your time and thoughts are very much appreciated.

>>> 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.

>> What would you suggest?

> I know probably all this sounds silly from a hard-core developer/OSS
> fanatic/linux hacker point of view, but nowadays marketing and
> documenting an OSS project is as important (if not more) as developing it.

It doesn't sound silly at all, I agree with you.  Writing good
"marketing" material requires a certain skill, though, a skill quite
different from writing decent C# code.

>>> 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.

>> I agree the strategy must get decided on and be documented at one point,
>> but does this need to get solved before graduation?

> For this I think yes: otherwise we risk that Lucene.net "graduates",
> whatever that means, and than committers are split by the decision to
> take, and the project dies again, for the same reasons it was dying
> last year.

Understood.  I tend to agree with that.  This also resonates with what
Prescott says.

> But the final word is to people that really spend their time on code and
> administrative stuff.

Whether it feels ready to leave the Incubator is on the Lucene.Net
community with those who actually do the work having to take the final
decision.

Many thanks

     Stefan

On 2012-02-01, Troy Howard wrote:

> - Repeatable, documented process: We need a better more defined,
> public and repeatable process for creating and building releases.

+1

Preferrably one the doesn't require binaries checked in into svn ;-)

No reason this needs to be done before graduation.

> - Committing to our decisions, despite alienating our user base:

You need to do this, true.  Documenting them might help.

[OT: I thought it would be possible to remove the 4.0 dependency for
2.9.4 with a small patch.]

> The question I have to Stephan is, what are the significant criteria
> for moving a project from the Incubator to a TLP?

Not sure whether there are hard rules, mine are

(1) Have all legal questions been addressed?

(2) Does the team understand the way the ASF wants to develop software:
    "the Apache way"?

(3) Is the team big and diverse enough to sustain?

My answers to this are

(1) Mostly, I'd need to perform a detailed review of the binaries
    checked in to svn to be absolutely sure.

(2) You have created three releases by Apache rules and went through the
    pains associated with that.  You perform your business on this list.
    What you haven't done is vote in a new committer.

    Also you seem to be working side-by-side rather than together from
    time to time, but with the 2.9.4 stuff done I expect that to change.

    I have full confidence in the current team and I'm sure you'd
    recognize and vote in potential committers.

(3) The team is not extraordinarily big but big enough IMHO.

> 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.

+1, fully agreed.

Stefan

Why not?

I am not confident that the project has reached a level of systematic, repeatable, releases.
Is that not one of the graduation criteria?  Version 2.9.4 (and 2.9.4g) represent just a single release and the process of porting the code and making the release products still seems a bit ad-hoc.
 
It also seems that there needs to be better agreement on how future ports of core Lucene are to be accomplished (or a concurrent, parallel, code base maintained).  

One side thought ... when discussing the line-by-line vs. conceptual port, it might be helpful to separate out concerns of " something that more closely resembles the .net world ".  While creating a .NET friendly API wrapper might be extremely useful, converting the Lucene code itself to be more ".NET like" may not be particularly beneficial.

- Neal

-----Original Message-----
From: Prescott Nasser [mailto:[EMAIL PROTECTED]]
Sent: Wednesday, February 01, 2012 11:38 AM
To: [EMAIL PROTECTED]
Subject: [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

On 2012-02-01, Prescott Nasser wrote:

> 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.

Prescott, many many thanks for starting this.

> 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.

I understand this and even agree that the size of the developer
community is my biggest concern as well.

Lets add some stats to that (I know stats lie)

<http://svnsearch.org/svnsearch/repos/ASF/search?path=%2Fincubator%2Flucene.net>

shows the current team has been more active last year than any group
that worked on Lucene.Net before.

<http://svnsearch.org/svnsearch/repos/ASF/search?from=20110101&path=%2Fincubator%2Flucene.net>
shows six different people have committed something during the time
inside the incubator which is more active developers than quite a few
Apache TLPs can show.

Of course it would be nice if the team was bigger, but maybe the "in
incubation" badge is actually keeping some people away from
contributing.

The team is big enough to make releases with three people reviewing the
artifacts and voting on them - as you have already demonstrated three
times.  This is the only requirement the ASF has on PMC size - along
with independence: six PMC members working for a single company would
not be good enough.

> 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.

Actually I'm not sure you are split at all.  Last time the subject was
discussed you all seemed to be on the same page.  Maybe you should break
the things you consider controversial into simple questions and poll or
even vote on them (in a different thread).  This may not only help in
determining if there actually is a split but also documenting the
decision.

Stefan