On Wed, Nov 21, 2012 at 10:10 AM, Greg Reddin <gred...@gmail.com> wrote:
> On Wed, Nov 21, 2012 at 11:46 AM, Alex Harui <aha...@adobe.com> wrote: > > > I am new to Git/GitHub, but I am wondering whether Infra considered using > > its own GitHub (see [1]). > > > I know they looked into that and were in talks with GitHub for a while. I > don't remember the details and probably couldn't share them on a public > list anyway, but for some reason that didn't work out. > > > > Another angle to explore is whether it would be ok from an Apache > > perspective to simply do our work on the public GitHub and only copy > > released sources back to either Apache SVN or some simpler Apache Git > > installation > > > I would have trouble with that approach and I suspect the board would too. > We want development to be open and transparent. It would be open and transparent as it would be in a publicly viewable and forkable GitHub repository for anyone with a GitHub account to fork for themselves. > The way we accomplish that > at Apache is for commit messages and code discussions to take place on the > mailing list. In this way we know code is being developed in the open by > watching the mailing lists. I know it's a somewhat antiquated methodology > in today's world, but it's the current implementation of the Apache Way. > Many Apache members understand the disadvantages and people do want to > change it. But they want to change it without sacrificing core tenets of > the Apache Way. So this is not easy and it won't happen overnight. But > there's good reasons IMO for us to stick with the program instead of trying > to do an end-run around it. > This could also continue to work as in the "Apache Way". GitHub has a lot of service hooks, over 100 of them, including JIRA and emailing hooks for moderated lists. GitHub can be set up to email the moderated list on each commit by simply providing an email address and a secret string to allow the posting to the moderated list. The code discussions can be had on our mailing lists and the commits would continue to flow to the flex-commits@address. I dont see how this would be "sacrificing core tenets of the Apache Way", and is in fact an easy set up. -p,ar
