RE: [Lucene.Net] Graduation

[Granroth, Neal V.]

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:jsbo...@aricie.fr] 
Sent: Wednesday, February 01, 2012 12:44 PM
To: lucene-net-dev@lucene.apache.org; lucene-net-...@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:geobmx...@hotmail.com] 
Envoyé : mercredi 1 février 2012 18:38
À : lucene-net-...@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

RE: [Lucene.Net] Graduation

[Jean-Sylvain Boige]

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:simone.chiare...@gmail.com] 
Envoyé : mercredi 1 février 2012 21:10
À : lucene-net-dev@lucene.apache.org
Cc : lucene-net-dev@lucene.apache.org
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  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 produc

Re: [Lucene.Net] Graduation

[Stefan Bodewig]

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)



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


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

Re: [Lucene.Net] Graduation

[Stefan Bodewig]

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

Re: [Lucene.Net] Graduation

[Stefan Bodewig]

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

RE: [Lucene.Net] Infrastructure Choices/Issues (was Re: [Lucene.Net] Graduation)

[Prescott Nasser]

Stefan, im looking into using the tarball approach to our docs. I attempted to 
update the website yesterday and I ended up running out of time waiting for the 
publish to happen.

In the meantime, you mentioned a roller set up for add - im not familiar with 
the term, but could you provide me a link or two to look into - getting a blog 
onto the front page would be fantastic.

Sent from my Windows Phone

From: Stefan Bodewig
Sent: 2/2/2012 9:14 AM
To: lucene-net-...@incubator.apache.org
Subject: [Lucene.Net] Infrastructure Choices/Issues (was Re: [Lucene.Net] 
Graduation)

On 2012-02-02, Simone Chiaretta wrote:

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

There already is a git-mirror (of trunk) on github at
<https://github.com/apache/lucene.net> and I think it is possible to
arrange for github pull requests to go to the project's mailing list.
If there is any interest I can try to dig out the details.

But as with all contributions there is the bar of licensing the code to
the ASF, so for anything that is more than a few lines JIRA with the
simple checkbox is more effective.

Furthermore if the team wanted to go with git as primary SCM then
Lucene.Net could join the club of testers (if anybody volunteers to help
out infra).

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

Not quite "no external tools" but certainly no external SCM.  As for
other tools, the ASF prefers people to use what is here and help out if
this is not adequate.

> But what about a CI environment? with a public output?

<http://ci.apache.org/> with options of buildbot, Continuum and Jenkins.

There even are some builds for Lucene.Net, see
e.g. <https://builds.apache.org/job/Lucene.Net-Trunk-All-Nightly/> but
my understanding is the team isn't happy with the setup, yet.

Likely this is a case of missing communication.

> Also the CMS, from my understanding, is kind of difficult to work with.

Not the CMS per se, but the restriction to "CMS or static files", I
think.  We'll need to find a better solution for the generated
documentation, that's true.

[OT: just stumbled upon
http://www.apache.org/dev/cmsref.html#generated-docs which may provide a
solution (the "upload a tarball rather than use svn" approach).]

> On Thu, Feb 2, 2012 at 1:30 PM, Stefan Bodewig  wrote:

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

OK.  Technically this could be done immediately.  There is a Roller
instance set up for ASF projects and it should be possible to embed blog
content into the sity dynamically.

Many thanks

 Stefan