lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Christopher Currens <currens.ch...@gmail.com>
Subject Re: Long-terms plans for supporting .NET 3.5
Date Mon, 14 Jan 2013 19:39:20 GMT
Moving to git will be easy.  So far, everyone has expressed interest in
moving over to git, and we've even made the decision to do it, we just
haven't contacted infra yet to have them move us over.

I think that moving activity to GitHub _should_ be easy, although there are
still a few "gotchas".  I'm guessing that a large reason the ASF insists on
hosting their own code is for legal reasons, particularly when it comes to
the Contributor License Agreement.  At the very least, we can't accept pull
requests to the project until a CLA is signed by the user.

This kind of workflow has been done before.  This is the same workflow that
Microsoft uses for open source contributions to Asp.Net (
http://aspnetwebstack.codeplex.com/).  While it's using Codeplex instead of
Github, the Asp.Net webstack uses Git and pull requests, and also requires
that committers have a signed CLA before pull requests are accepted.  If a
large corporation like Microsoft, who only just _recently_ started to
seriously embrace OSS, can successfully do it I think that the ASF should
be able to as well.

Ultimately, the workflow between ASF and Github are the same, except that
Github's is easier, more modern and convenient.  Since they wind up moving
toward the same goal, I see no reason why we can't use Github completely.
 A pull request in Github is as a patch to SVN.  I think as long as we
enforce the CLA, we shouldn't have any problems, although it would be nice
to get Stefan's input on this.

Now, when it comes to automating the process, could that be done with a
post-commit hook?  Since we're going to move our repository to git anyway,
seems like it would be a very simple setup.  I'm sure that it would require
more work from infra besides just that, so if this is something that all of
the committers decide we want to pursue, then we'll need to contact them.

I think it's very doable, assuming there isn't any red tape from the ASF.


Thanks,
Christopher


On Sun, Jan 13, 2013 at 12:29 AM, Troy Howard <thoward37@gmail.com> wrote:

> 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