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 > À : [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 > >
