On 8/20/12 12:21 PM, "Om" <bigosma...@gmail.com> wrote:
>
> 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.
Has Apache ruled that this is the case?
> OR
> 2. Send a pull request to ApacheFlex. This is a workflow I would prefer,
> but we cannot do this right now.
Will we be able to do this once we have an official Apache Flex repo that is
read/write? And how will the pull request authorize the contribution in a
trackable way like the JIRA workflow?
>
> 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.
I don't think that was a fair comparison. I don't think there is anything
about Git that makes it more apparent you should develop and contribute unit
tests as well. At least with the JIRA patch we know exactly what is
contributed and that it has been authorized.
>
>> 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.
Has this been verified? It isn't true for SVN branching.
--
Alex Harui
Flex SDK Team
Adobe Systems, Inc.
http://blogs.adobe.com/aharui
