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. https://builds.apache.org/job/Lucene.Net-Trunk-All-Nightly/ 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. Thanks, Troy On Tue, Jan 15, 2013 at 11:34 PM, Itamar Syn-Hershko <ita...@code972.com>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 <bode...@apache.org> > 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 > > > > >
