lucenenet-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Troy Howard <>
Subject Re: Long-terms plans for supporting .NET 3.5
Date Wed, 16 Jan 2013 08:09:08 GMT
The main thing is ensuring that we consider the ASF git repo for Lucene.Net
to be the primary source of truth (once we move over to it)  Any PRs on the
Github mirror will need to be merged back into the ASF git repo. This can
be done manually, or possibly automated. If manually, a PR is essentially
no different than an path on a JIRA ticket. In fact, I'd be very surprised
if Github PRs were not inspired originally by the very effective ASF
workflow for that. That said, Github vs patch/JIRA method is much like SVN
vs git... I give full props to the fact that the technology was awesome 5
years ago, but I won't pretend that we don't have better tools now, and IMO
we should using them. One way to think of it is that the ASF model is built
into Github as a first-class feature, instead of having to be layered on
with human processes over JIRA which is not designed for these concerns.

Regarding Travis vs ASF infra CI... Well, we could definitely customize our
CI to be whatever we wanted it to be, but Travis can be used without the
need for us to manage it ourselves. Also, enabling Windows/.NET support on
Travis is a pretty major event for them, and it would be nice for some of
the well known .NET open source projects to at least try it out. The worst
it can do is to not run our tests/builds well and thus not be very helpful.
:) ... and yes, we could start integrating Travis in now, just using the
Apache mirror on GH. CouchDB and Jackrabbit Oak are both doing that
already. That said, there's some serious delay due to the mirroring process
being so far behind the commit. It makes it far less useful. That said,
we're not even really using the CI we have now. looks a bit sad
at the moment.

Anyhow, I don't see this as being an either-or kind of thing, but I do
think Github and Travis are much lower friction compared to the ASF
environment. It'd be worth experimenting with to see if it might improve
our process. I think we should still stick to the ASF "mailing list or it
didn't happen" methodology.

Regarding "drive by contributions", well, I'd prefer to have that than none
at all. Maybe some of those folks will stick around and get more involved.

I think we should vote on PRs on the mailing list before merging PRs, which
would give our committers a chance (and a deadline) to get in there and do
code review. Being able to do that from a browser makes things so much
easier. Also allows for meaningful and detailed discussions about the code
with line-by-line comments, etc.


On Tue, Jan 15, 2013 at 11:34 PM, Itamar Syn-Hershko <>wrote:

> Stefan, there's nothing to worry, really. Usually PRs have discussions on
> them, or its really clear what they are for. Worst case, a PR has been sent
> without a description or proper discussion (which we can always do on JIRA
> / mailing list / github), we deny it.
> Also, the discussion is to move to using git, which is much easier to
> collaborate with than with SVN, hands down. You should have exactly  the
> same concerns with SVN, frankly.
> On Wed, Jan 16, 2013 at 7:23 AM, Stefan Bodewig <>
> wrote:
> > On 2013-01-15, Oren Eini (Ayende Rahien) wrote:
> >
> > > We use github for ravendb and require CLA for anything except tests
> > > We have a LOT of people contributing
> >
> > That's great.
> >
> > Do you experience any of the things I'm concerned about?  I.e. people
> > creating a pull request and never coming back and in particular people
> > spending lots of time on a feature without consulting with the devs
> > first?
> >
> > Stefan
> >
> >

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