Yes, that would work, we routinely get a PR for github.com/ravendb/ravendb, I pull this locally, merge it to github.com/ayende/ravendb, and when we merge back to ravendb/ravendb it is closed.
On Thu, Jan 24, 2013 at 10:34 PM, Itamar Syn-Hershko <[email protected]>wrote: > Just a few more notes... > > On Wed, Jan 16, 2013 at 10:09 AM, Troy Howard <[email protected]> wrote: > > > 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. > > > We don't have to work against github. Actually, perhaps we better work > against an ASF's git repo and have it auto-mirrored to github. The way git > works, all you have to do to merge a PR is add the other repo as a remote, > fetch and merge. Github should detect that as closing the PR - and we can > probably verify that with them. > > Perhaps one benefit of working on github is there is no lag and you can > immediately use their excellent history and diff tools. > > Either way, I would recommend setting up a hook to email this list with > notifications about incoming PRs, just so everyone is notified. We can > continue the discussion here or there, whatever we find more convenient. > > > > > 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. > > > > +1 > > The rest of Stefan's worries are all covered by good guidelines on how to > work with PRs / github tools - voting etc. > > So, how do we proceed? >
