lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Michael Herndon <mhern...@wickedsoftware.net>
Subject Re: [Lucene.Net] Graduation
Date Fri, 03 Feb 2012 21:43:09 GMT
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 <jsboige@aricie.fr>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:robertj@gmx.net]
> Envoyé : jeudi 2 février 2012 12:22
> À : lucene-net-dev@incubator.apache.org
> 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
>
>

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