lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Troy Howard <thowar...@gmail.com>
Subject Re: Long-terms plans for supporting .NET 3.5
Date Sun, 13 Jan 2013 08:29:32 GMT
One thing to consider is that the ASF workflow is a bit stodgy to work
with. It really does make a difference to collaboration, as any small
barrier makes it too easy to opt out of contributing and collaborating.

For me, it's a huge change of context. For work, I use Github. For open
source projects I use Github. For snippets of code and random ideas, I use
Gists, which are just little Github repos. I'm even in the process of
migrating my blog over to Github. A substantial portion of my development
experience is focused there.

Recently, when I went to contribute the docs, I found that I couldn't
remember my password, so I did the reset password process, which sends an
encrypted email. Then I couldn't find my PGP key to decrypt the email.
Luckily I found it on an older machine, and got all that worked out but it
took a few days to get back into the ASF context. Then I had to install and
remember how to use SVN, and had to wait forever to checkout, do status, do
a commit, etc. because our repo is large. Sure, if I was more active with
the project, and working with it everyday, this might not be as big of a
problem for me. But as it stands, it's a noticeable barrier, and enough of
one that I find it hard to get motivated to work on the project. I think
this problem would be even greater for folks who have never spent a
significant amount of time with ASF tooling or don't have a strong vested
interest in dealing with it.

Part of this is svn vs git, but it's also Github vs ASF's workflow. Pull
requests are great, and Github's interface for that makes things easy. The
idea of having to create a patch and then attach to a JIRA ticket so that a
committer can merge it into a central repo is totally backwards, and IMO
not a modern way of working.

Since we're talking about ways to get more people engaged and to ease
collaboration and management of the version 4 porting process, I'd like to
suggest that for version 4 only, we try to centralize work around Github
and find a reasonable process for merging that back into ASF's repo. A
number of ASF projects are already on git, and our repo is already mirrored
over there. I think we should move over, fully, to git via the normal ASF
process for that. That removes SVN from the picture, and should make
working between ASF git and Github git easier.

Then, the only issue would be finding a good way to merge changes back into
the ASF repo from the Github master. Ideally, the ASF repo could just
pull/merge those changes in, in a automated fashion. But that would require
some infra changes. In the mean time, we could just do periodic patch
extractions and commits via the established process.

Also, being on Github would mean we could take advantage of TravisCI for
build/test. They are just about to release support for Windows/.NET and it
would be great to have our project be part of that.

Thanks,
Troy


On Sat, Jan 12, 2013 at 5:47 PM, Christopher Currens <
currens.chris@gmail.com> wrote:

> I started working on porting 3.1 in another branch.  The porting work is
> weird, and I would have no idea how to coordinate people working on the
> same project as other developers.  There are so many classes that are
> shared between namespaces, I think it would be difficult to do it without
> doubling work.  Plus, who REALLY wants to do porting work? :)
>
> There was talk in another thread where it was suggested that porting each
> version of 3.x up to 4.0 would take too long...it does seem to take
> _forever_ to get stuff released on this project.  So it really makes more
> sense to jump right into the 4.0 code, for quite a few reasons.  I actually
> think we should start over from scratch(ish).
>
> We have a lot of things we want, we've discussed it many times, it involves
> API changes and probably some design changes as well.  There has also been
> expressed desire for supporting other platforms, like Windows Phone, RT or
> Azure.  Supporting these would require pulling out common code into a core
> library and having platform-specific ones for some of the features (ie.
> File I/O).  We could pull out existing code from our current trunk, mainly
> support classes and other things that haven't changed drastically.  I
> already have some methods I've added to the Character support class I can
> add, related to utf32 and surrogate characters.
>
> We want API changes as well, which might be less daunting to implement if
> we were writing 4.0 from a fresh perspective.  This would require active
> organization and planning from every committer that wants to work on the
> port, but ultimate, I think it might be a good way to do it.
>
> I want to hear input from everyone on this and what would be the best way
> to organize our group to make this project even more desirable.  Also, it's
> nice to see the list getting a little bit more active than it was last half
> of the year.  We've had a nice vacation.  Let's get back to work. :)
>
>
> Thanks,
> Christopher
>
>
>
>
> On Fri, Jan 11, 2013 at 5:56 PM, Troy Howard <thoward37@gmail.com> wrote:
>
> > I agree regarding framework versions. Lucene 4 == .NET 4 ... Simple. :)
> >
> > On Fri, Jan 11, 2013 at 3:58 PM, Prescott Nasser <geobmx540@hotmail.com
> > >wrote:
> >
> > > I'm on the same page with 3.x and 4.x supporting differing versions.
> > > For actual effort, where do we put it now? Do we get up to speed with
> 3.6
> > > quickly, then try to do the 4.x?
> > >
> > > > Date: Tue, 8 Jan 2013 10:27:04 -0800
> > > > Subject: Long-terms plans for supporting .NET 3.5
> > > > From: currens.chris@gmail.com
> > > > To: lucene-net-dev@lucene.apache.org
> > > >
> > > > There was an email thread last week (Lucene v3.6
> > > >
> > >
> >
> http://mail-archives.apache.org/mod_mbox/lucenenet-dev/201301.mbox/browser
> > > )
> > > > where the feasibility of continuing support of .NET 3.5 was put into
> > > > question.  There are a few design patterns in Lucene 4.0 that would
> not
> > > > only be difficult to port to a .NET 3.5 target, but would also likely
> > > > complicate and clutter the code if trying to support both runtimes.
> > > >
> > > > The most used pattern deals with variance, which is only really
> > supported
> > > > in .NET 4.0, and still differently than it is in Java.  Since generic
> > > > variance is not supported at all in .NET 3.5, it would make the
> porting
> > > > process a pain.
> > > >
> > > > Here is what I think, which I've already stated in that last email
> > > thread.
> > > >  I think that the port of Lucene 4.0 should be limited exclusively to
> > > .NET
> > > > 4.0 or greater frameworks.  I _do not_ think that we should drop .NET
> > 3.5
> > > > support in the entire project.  I know that we have many people that
> > > still
> > > > rely on having a library targeting the 2.0 runtime.
> > > >
> > > > Instead, I think we should maintain two branches of lucene, similar
> to
> > > how
> > > > the java team does it, once for 3.x and one for 4.x.  The 3.x branch
> > > would
> > > > support both .NET 3.5 and .NET 4.0, whereas the 4.x branch would only
> > > > support .NET 4.0 or greater.  The 3.x branch would likely not be a
> > > perfect
> > > > port, since the later versions of lucene 3.x do start to include some
> > > > features that are difficult to translate into pre-.NET 4.0 targets.
> > > >
> > > > There were also requests in that thread to make the Lucene 4.0 port
> > > include
> > > > features like async/await API support, lambdas, and other .NET
> > features.
> > >  I
> > > > think that those with busier schedules and/or less time to devote to
> > the
> > > > project would be able to give valuable feedback when it comes to
> making
> > > > design decisions for the API.
> > > >
> > > > I think that this could be a good plan, and for those who are less
> than
> > > > thrilled to work on porting lucene 3.x, I'm willing to do the bulk of
> > > that
> > > > myself, if it's more desirable to work on the 4.0 branch.  I think
> > it's a
> > > > relatively large investment, though, since the jump from where we are
> > now
> > > > to lucene 4.0 is large enough that it will take a good amount of time
> > and
> > > > effort from everyone to keep it going.
> > > >
> > > > Hopefully there are comments on this.  If there's not much discussion
> > > about
> > > > this in the next few days, I'm just going to set up a vote and go
> from
> > > > there.
> > > >
> > > >
> > > > Thanks,
> > > > Christopher
> > >
> > >
> >
>

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