I'm pretty sure a project under Outercurve doesn't need to be hosted on CodePlex Aaron Powell Umbraco Ninja
http://www.aaron-powell.com | http://twitter.com/slace | Skype: aaron.l.powell | MSN: aaz...@hotmail.com 2010/11/5 Granroth, Neal V. <neal.granr...@thermofisher.com> > Phil, > Some good thoughts; though Outercurve projects are simply hosted back on > CodePlex, so the problems noted with development there probably still apply. > Also, I am not so sure you're making correct assumptions about companies > being in ".NET space". But as this thread is diverging off-topic, you can > contact me directly if you'd like to talk further. > > - Neal > > -----Original Message----- > From: Phil Haack [mailto:phi...@microsoft.com] > Sent: Thursday, November 04, 2010 10:42 AM > To: lucene-net-user@lucene.apache.org > Subject: RE: Lucene.NET Community Status > > I'm not necessarily pushing for a move away from the ASF (nor am I > suggesting not to make the move), but I don't understand how the move away > would necessarily kill the project. Especially if the Lucene.NET team > continued to follow the same existing process of the line-by-line port from > Lucene. After all, Lucene is OSS, so there's no reason the project couldn't > continue to do the line-by-line port. Also, the Lucene team wouldn't shun > the newly formed project would they out of spite? From what I've heard, > their forums are active and helpful. It seems to me that where the project > lives is separate from how the project operates. > > I'm not suggestion that the ASF processes are not helpful. In fact, I tend > to lean towards suggesting staying with the ASF, but it's worth exploring > the idea of a move to a more .NET friendly environs while maintaining a > relationship with the original Lucene project. For example, the Outercurve > Foundation is also establishing processes that benefits its projects, > provides indemnification, and has a former ASF board member on its board. > > I'm compiling a list of companies that benefit from Lucene.NET. Obviously, > these companies are in the .NET space. My impression is that the ASF isn't > really geared to rallying these companies to help out the project, since the > focuse tends to be in the Java space and not the .NET space. Apache doesn't > share the same mindshare in the .NET world that it does in the Java world > for whatever reason. > > I had hoped that the forge that the project was hosted in would be separate > from its foundation, but apparently that's not the case with ASF. So the > question I'm posing is, if the project moved to a forge and foundation > that's more geared towards .NET developers such that we could really try > hard to rally all these beneficiaries around the project, while still > maintaining close ties to the original Lucene project, would that be the > best of both worlds for the project? > > Of course, this all depends on what the core team of contributors feel > about it. Without strong leadership, the project withers. And it would > really require them to step up and say yes or no and lead in a particular > direction so we can throw our support behind that direction. > > Phil > > -----Original Message----- > From: Granroth, Neal V. [mailto:neal.granr...@thermofisher.com] > Sent: Thursday, November 04, 2010 8:20 AM > To: lucene-net-user@lucene.apache.org > Subject: RE: Lucene.NET Community Status > > Others have expressed these points better than I am able. > > The algorithms that make up Lucene were expressed in the Java project and > active development occurs there. All ports of Lucene benefit from work done > there and we all free to contribute to its on-going development. > Separating the project would sever these beneficial connections. > > The ASF formal processes are also beneficial. In the environment in which > I work I can readily justify use of open source developed within its > guidelines. It is extremely difficult to justify use of open source from > ad-hoc projects on CodePlex or elsewhere. > > So, yes it is pretty cut and dry. > > - Neal > > -----Original Message----- > From: Josh Handel [mailto:josh.han...@catapultsystems.com] > Sent: Thursday, November 04, 2010 10:01 AM > To: lucene-net-user@lucene.apache.org > Subject: RE: Lucene.NET Community Status > > I think there are more than 4 people interested in a .NET centric API.. > Also, we have also talked about how moving to a more .NET friendly forge may > infact attact new blood.. And given that Lucene is open source, and as of > yet, I haven't seen the Lucene (Java) guys show any special deference to the > .NET project.. I'm not sure where (beyond brand, some potential legal > support, and a rigiours process) where being "close" to Lucene (Java) is > providing value.. > > Plus the Line by Line port is kinda what got us here in the first place.. > if the project had done a conceptual port (line NUnit, NHibernate, NAnt) > rather than line by line, then we would have built up the search expertise > we are now lacking.. And we might not have burned out our top talent with an > overly boring and laborious process.. > > Just saying, it's not as cut and dry as you are selling it right now ;-). > > Josh > > -----Original Message----- > From: Granroth, Neal V. [mailto:neal.granr...@thermofisher.com] > Sent: Thursday, November 04, 2010 9:55 AM > To: lucene-net-user@lucene.apache.org > Subject: RE: Lucene.NET Community Status > > You are forgetting the people who test, report bugs, and assist new users. > There are a lot more people involved then just the four you've listed. > > You are also forgetting the discussion that pointed out a move to CodePlex > or other location outside ASF would mostly likely kill the project. The > project greatly benefits from close connections to Lucene (Java). > > - Neal > > > > -----Original Message----- > From: Troy Howard [mailto:thowar...@gmail.com] > Sent: Thursday, November 04, 2010 1:17 AM > To: lucene-net-user@lucene.apache.org > Subject: Re: Lucene.NET Community Status > > Phil, > > I've been unsuccessful at finding the specific reference in the ASF policy > that covers this, but in a nutshell, yes, the code must be hosted by ASF, as > well as the websites, docs, etc... This will prevent anything other than a > mirror or branch existing on CodePlex.com. > > If the project leaves ASF this is not a concern of course, but will need to > change it's name. > > There are currently four commiters (taken from > http://lucene.apache.org/lucene.net/ ): > > George Aroush geo...@aroush.net > Işık YİĞİT (DIGY) digyd...@gmail.com > Doug Sale ds...@myspace-inc.com > Michael Garski mgar...@myspace-inc.com > > > Based on SVN logs commit activity, DIGY is the most recent committer. > mgarksi's last commit was in 03/2010, and aroush in 12/2009. > > Currently only George and DIGY are showing interest in the project in the > mailing lists. I would say that they are the people who would fit the bill > of "core active project leaders". > > Thanks, > Troy > > > On Wed, Nov 3, 2010 at 9:52 PM, Phil Haack <phi...@microsoft.com> wrote: > > > I have a couple of naive questions, so forgive me. I see that Apache > > projects use SVN http://www.apache.org/dev/version-control.html > > > > But is it required to host Apache projects in this svn? The reason I > > ask is that a small change to hosting in a forge like CodePlex.com > > would provide the project huge exposure to more .NET developers. You > > could do this, but keep all other processes the same. > > > > Also, it makes keeping documentation really easy since they support > > MetaWeblog API, and thus Windows Live Writer. It might seem like I'm > > trying to hawk technology answers to organizational projects, but > > you'd be surprised by how much reducing the friction of documentation > > makes people more willing to write documentation. At least, for the > > projects I work on, I'm more than willing to contribute documentation > > when I can just point a blog client to it and publish. > > > > The other question I ask is who are the core active project leaders > > for Lucene.NET? I'd really like to understand what they want. I and > > others have many ideas, but it'd be helpful to understand what > > direction they want to take things and what things are non-negotiable > > so we have a framework to work with. > > > > Thanks, > > Phil > > > > > > > > > > ________________________________________ > > From: Troy Howard [thowar...@gmail.com] > > Sent: Wednesday, November 03, 2010 8:47 PM > > To: lucene-net-user@lucene.apache.org > > Subject: Re: Lucene.NET Community Status > > > > All, > > > > I'm entering this conversation late as well. I'll apologize in > > advance, as I know this will be lengthy. > > > > Briefly, I'll list my "credentials" and reasons for concern here: > > > > - I've been using Lucene.Net for many years since the early versions > > and have built significant products for my company using it. Those > > products are a core source of our revenue, which is measured in the > > millions of $$s. The success of my company's products are directly > > dependent on the success of the Lucene.Net project. > > > > - I run software development at my company and make the final > > decisions about what we do and how we use our resources. The > > developers here work on open source code on our clock. I would like to > > have them start doing this for Lucene.Net. We have very smart and > > productive people who could be a huge asset to this project. I hope > > that the opportunity to leverage my company's team will not be > > bypassed by the people running this project. > > > > - I have hacked extensively on the Lucene.Net internals to improve > > performance in our product and have been manually maintaining our > > local branch, merging in changes from the main project. I feel I have > > enough knowledge of both the CS theory behind search engines and in > > particular this codebase to not be intimidated by any aspect of the > > needs of this project. > > > > - I started a similar kind of open source project in that it is a > > .Net implementation of an existing C++ open source project and > > struggled with the "syntactic port" vs "conceptual port" issue, and so > > have perspective to provide on that discussion > > > > > > Relationship To ASF and Lucene > > ----------------------------------------------- > > > > I'd like to address one thing upfront: This should definitely remain > > an Apache Software Foundation project. As Grant and George have stated > > clearly and accurately, this is a huge benefit for this project in > > terms of it's credibility. This is not just because the name is well > > respected. It's because of WHY the Apache name is so well respected: > > the processes and values of the Foundation set excellent standards > > which encourages excellent code. This is not just my opinion, but can > > be objectively proven by the enormous success of the Apache projects. > > Complying with ASF's standards may be difficult, but it's extremely > valuable. > > > > I feel that Grant's recommendation of attempting to become a TLP at > > Apache is the wrong direction. This should remain part of the Lucene > > project. It is not unique in any substantial way from Lucene and thus > > doesn't warrant being separate. > > > > Also, there was some mention of Lucene's file format and maintaining > > that compatibility. This is essential. If this ever changes, > > Lucene.Net will be useless. Being cross platform and having a very > > stable on disk format is one of it's most compelling aspects. > > > > > > Microsoft's Interest and Involvement > > --------------------------------------------------- > > > > Another thing to mention: Phil Haack and Scott Hanselman, while both > > are Microsoft employees, are more than just a representative of the > > company they work for. They are both outstanding advocates of open > > source software and have been instrumental in the change of attitude > > that Microsoft has shown in recent years towards this community. The > > fact that they have shown interest in this issue doesn't mean > > Microsoft is interested, it means that this is a significant issue for > > the .Net open source community. The fact they they work for Microsoft > > means that they may be able to leverage resources and wield clout from > > that vantage point that can benefit our community greatly. > > > > Regarding the question "What can Microsoft do to help"?.... I'll take > > a somewhat radical stance here. > > > > We need Visual J# not to have been abandoned... We need IronJava, like > > IronPython or IronRuby. We need a native, MS developed and supported, > > fully optimized and performant compiler for plain old Java code that > > runs on the .Net runtime and exposes Java libraries to other .Net > > languages like F#, C#, VB, etc.. > > > > There is a huge wealth of open source Java code out there, much of it > > in the Apache project archives, which would all be "ported" at once. > > Currently our community only gets access to Lucene.Net and iTextSharp > > and a few other libraries where dedicated people like George put in > > hard hours of direct syntax porting to implement these things in C#. > > > > We need more than that. > > > > I need Hadoop to run in .Net and HDFS, Hbase, Solr, Nutch, Tika, and > > everything else in that ecosystem. > > > > My company is actually at a critical point now, where we are > > considering abandoning .Net/WCF as our service layer platform, and > > switching to Java, so that we can leverage those excellent Java > > projects. Our business needs demand that we have what Hadoop does. It > > will be easier for me to migrate my application code to Java than to > > attempt to find equivalent functionality in the existing .Net world or > > write my own framework, or port Hadoop. > > > > So, if there was ONE thing that Microsoft could do to *significantly* > > help the .Net developer community, it would be providing a *real* > > implementation of IronJava which would obviate the need to port code > > completely, and simply allow those libraries and applications to run > > in .Net natively. > > > > That said, assuming that Visual J# remains "retired" (see: > > http://msdn.microsoft.com/en-us/vjsharp/default ) this project is one > > of the few things we .Net developers have to work with. > > > > > > Java or .Net Code Idioms > > ------------------------------------- > > > > I agree that moving to a codebase that is more .Net idiomatic will > > both improve the user experience of end users of Lucene.Net but will > > also improve the level of involvement that we can get from the > > community. To put it simply, right now, hacking on the Lucene.Net core > > code means you must understand Java idioms well, and how to translate > > those to .Net. This is a skill set which is somewhat uncommon. > > > > The "direct port" methodology also leads to code that is not fully > > optimized for .Net. I have changed our local branch in a number of > > significant ways, and improved performance significantly by doing so. > > I didn't change APIs, I just change the implementations to be more > > appropriate for .Net, and included generics. > > > > The test suite provided with Lucene/Lucene.Net is a great benefit in > > that regard, and helped me ensure that my changes didn't break > functionality. > > That said, the project need to improve in this regard. The classes > > themselves need to be implemented in a more "testable" manner. > > Abstract base classes instead of interfaces makes the code less > > mockable and thus less testable. It also makes it harder to implement > > customized components into the system. There are a number of things > > that are sealed or internal that do not need to be. > > > > Lucene (for Java) was awesome because it ran well as managed code and > > was elegant and efficient in Java's environment. Any port of Lucene > > should *retain those features* as well. The library should make sense > > and be implemented in the most elegant and efficient way that it can > > be on the platform it's implemented on. Lucene.Net should not be a > > port of Java Lucene to .Net, it should be an *implementation* of > > Lucene running in .Net. > > Porting > > implies line-for-line similarity. Implementing just implies that the > > features are all represented. > > > > For that reason, I support moving to a more idiomatic .Net > > implementation, verified by the unit tests. The argument that "it will > > require smart people" > > to understand the core code -- that's a *GOOD* requirement. If you > > don't understand how it works, conceptually, perhaps you should not be > > attempting to implementing it. Merely porting or auto-converting code > > that "seems to be the same" and "passes the unit tests", without > > really understanding the details is not a safe way to ensure correct > > operation. What if there was a subtle difference between the two > > syntaxes which led to differing (ie > > incorrect) behaviour in some scenarios? What if the unit tests didn't > > cover that scenario? > > > > Regarding the help and support provided by the Lucene community, and > > the books and examples that provide code samples.. Changing to a more > > .Net idiomatic codebase, even if that meant top level API changes, > > would not be a substantial issue that would prevent a .Net developer > > from understanding example code written in Java. If the API is > > *basically* the same, but uses foo.Size instead of > > foo.getSize()/foo.setSize() or List<T> instead of ArrayList... those > > differences are minor and will not cause significant issues for > > groking cross-language examples. People will still get it... and .Net > > developers will be much happier. > > > > > > So, take away is: > > - My team and I will help hack on Lucene.Net and get paid to do it > > - Lucene.Net should not change project status > > - Microsoft should implement IronJava > > - Moving towards idiomatic .Net code is the direction the project > > should go and is not that big of a deal > > > > > > Also, as a side-note. We're hiring in the Portland, Oregon area, and > > could use developers who know Lucene.Net, and want to hack on it on the > clock. > > Send me your resume. > > > > > > Thanks, > > > > Troy Howard > > Director of Software Development | discover-e Legal, LLC | > > thowar...@gmail.com > > > > >
