lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Simone Chiaretta <>
Subject Re: [Lucene.Net] Graduation
Date Thu, 02 Feb 2012 16:13:23 GMT
Mine below

On Thu, Feb 2, 2012 at 1:30 PM, Stefan Bodewig <> 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. 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 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 configuration on teamcity, but that's an unofficial
I know probably here there is maven... but not very .net-like way of

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 into years '10s, which
would also make it more appealing and fun to work with for possible
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 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 "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.


> Thanks
>     Stefan

Simone Chiaretta
Microsoft MVP ASP.NET - ASPInsider
twitter: @simonech

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

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