On Mon, Aug 20, 2012 at 11:43 AM, Alex Harui <aha...@adobe.com> wrote:
> > > > On 8/20/12 11:34 AM, "Om" <bigosma...@gmail.com> wrote: > > >> > >> What would be the steps to integrate a proposed change if we didn't use > >> GitHub and we retired the GitHub mirror? > >> > > > > I am sorry, but why would we want to retire the GitHub mirror? Right > now, > > it is read-only. If we leave it like that, the community can at least > fork > > the projects and work on it. > > > Why couldn't the community make forks/branches from the official Apache > Flex > Git repo? > The one cool thing about GitHub lets me easily host my personal project on a publicly available repository. Take this scenario for example: Contributor A has an idea for a feature. He forks ApacheFlex on Github into ApacheFlexContributorA He works quite a bit on this new feature and is ready for community feedback. He posts on the dev list about this and generates interest. Contributor B likes what she sees and wants to help Contributor A. She forks the project: ApacheFlexContributorA into ApacheFlexContributorB on GitHub. She adds a slew of new features. Contributor B sends a pull request to Contributor A. Contributor A code-reviews the changes B has done and asks Contributor B to make a few changes. Contributor B makes the changes and sends a new pull request to Contributor A. Contributor A likes what Contributor B has done and merges the code into ApacheFlexContributorA Contributor C follows the same process and writes a whole lot of unit tests for the new feature. Contributor A merges Contributor C's changes into ApacheFlexContributorA ContributorA now can do one of two things: 1. Make a patch of ApacheFlexContributorA codebase and attach it to a JIRA ticket. In the JIRA ticket the CLA of only Contributor A is sufficient. OR 2. Send a pull request to ApacheFlex. This is a workflow I would prefer, but we cannot do this right now. Committer X jumps in, applies the patch OR pulls the code from ApacheFlexContributorA repo on GitHub, tests everything on her local machine and commits the code into the main repo. He sees that this is a high quality patch with well thought out functinalities + a nice unit test suite. It makes the CommitterX's job much more easier. In this scenario, we are fostering community collaboration by letting non-committers work together on things they care about. Apache Flex's committers' workload is thus reduced. To do the same thing in the non-GitHub way, this is what it would take: ContributorA forks ApacheFlex from apache git into his local machine. He works on the new feature. He posts on the flex-dev list and generates interest. To get a Committer to look at this code, he HAS to generate a patch file. Committer X looks at the patch and says he wont touch it until there is a bunch of new additions/modifications. ContributorA goes back and works on the above mentioned things alone. He attaches a new patch. CommitterX now says that there needs to be more unit tests. ContribturA goes back and adds unit tests and attaches a new patch. CommitterX likes what he sees and commits the patch. Now does the rest of the community gets a look at the new feature and provides feedback. As you can see in approach 2, the community i.e. non-committers are not able to collaborate freely on development. And it serializes the workflow when it does not necessarily have to. > It would save a step, prevent issues from mirror delays, reduce > bandwidth on Apache infra. How would it reduce Apache infra bandwidth? In fact the other way does reduce bandwidth on Apache Servers. Once the github mirror is made, all the other github forks would be made from the github mirror and not from the apche flex git repo. > Would we have to make mirror requests of Infra > for every branch in GBM? That would also be painful. > No. Any branching would be updated in the next github mirror refresh. > > >> > >> GitHub might be great for sharing, if the committers have lots of extra > >> steps to deal that will be a dis-incentive for reviewing patches. > >> > > > > Agreed. We will have to come up with a way and put pressure on infra > (ha!) > > to use such a workflow. > > > > From my side, I am HIGHLY interested in removing the barriers for > community > > participation. Getting an acceptable GitHub workflow is something I will > > be working on soon (after I wrap up what I am doing right now) > > > I am also interested in getting the community involved, but not at the > sacrifice of the Apache Way. As the mentors have warned, we need to make > sure folks have legally and willingly contributed changes and that only the > committers can make those changes. We have to make the workflow safe and > efficient for the committers as well. It will likely require some > balancing. > Which is why we need to come up with an "acceptable github workflow", i.e. that does follow the Apache way AND integrates nicely into the GitHub workflow. Once again, Git != GitHub. Github work can be done after we make the move to Git. Thanks, Om
