If all devs would then start forking in GitHub and opening pull requests, 
you'll possibly have quite an explosion of repos though: 20 repos x 150 devs = 
3000 forks. This is one of the reason why popular OpenSource projects such as 
OpenStack and Jenkins do not use Pull Requests.

How are you planning to cope with that problem ? Are you assessing other code 
reviews that does not require forking ? (I.e. Gerrit Code Review)

What would be approach for bad pull requests (flagged by WSO2 Users as negative 
review) created by WSO2 committers ? (The ones you mentioned before that have 
proved to adopt good code practices and thus granted that role)

Luca


On 13 Feb 2014, at 04:35, Nuwan Bandara <[email protected]> wrote:

> Hi Luca,
> 
> 
> On Wed, Feb 12, 2014 at 2:32 AM, Luca Milanesio <[email protected]> 
> wrote:
>> Would it be a public review of the changes ? Team member vs non team member 
>> does not seems an objective validation of the code quality.
>> 
>> Changes should be merged because they make sense and not based on the email 
>> domain ownership IMHO.
> 
> Ofcause that will always be the case if an internal team member produce bad 
> code it wont be merged. Actaully within WSO2 internal developers will not get 
> commitership until they prove themselves with quality code and best 
> practices. We regularly have code reviews, and with git migration we can 
> comment on the code publicly and if its good only we will merge.
> 
> Regards,
> /Nuwan
>  
>> 
>> Luca
>> 
>> On 12 Feb 2014, at 03:40, Afkham Azeez <[email protected]> wrote:
>> 
>>> 
>>> 
>>> 
>>> On Wed, Feb 12, 2014 at 8:47 AM, Shevan Goonetilleke <[email protected]> 
>>> wrote:
>>>> Hi Sagara,
>>>> 
>>>> The pull request sent from a non-team member will have to be merged 
>>>> manually by the respective team right? The automated validate and merge 
>>>> will be only at the company level?
>>> 
>>> Any pull requests to the team repos have to be manually merged.
>>>  
>>>> 
>>>> Thanks
>>>> Shevan
>>>> 
>>>> 
>>>> On Tue, Feb 11, 2014 at 11:31 PM, Sagara Gunathunga <[email protected]> 
>>>> wrote:
>>>>> 
>>>>> Please find proposed Validate & Merge architecture for platform projects 
>>>>> based on a POC we did during last few days. Once we implemented, this 
>>>>> will be a huge step to reach continuous delivery mode.       
>>>>> 
>>>>> <repo.png>
>>>>> 
>>>>> 
>>>>> Example workflow is given below based on "carbon-deployment" project own 
>>>>> by AS team. 
>>>>> 
>>>>> 
>>>>> - In WSO2 organisation level there will be a GitHub repo[1], Jenkins 
>>>>> build server and Nexus server available and those are common for all 
>>>>> projects and own by Infra/Admin team. 
>>>>> 
>>>>> - There will be a build VM given for each team and they can run their own 
>>>>> Jenkins server. 
>>>>> 
>>>>> - There will be a "GIT Proxy" available on organisation level  Jenkins 
>>>>> server that can accept pull request in behalf of  organisation level 
>>>>> GitHub repo[1]
>>>>> 
>>>>> 
>>>>> 
>>>>> 
>>>>> 1.) Responsible person from AS team fork  "carbon-deployment"  project 
>>>>> from WSO2 repo [1] to team level repo [2] ( This is a one time task).
>>>>> 
>>>>> 2.) Each team member clone team level GIT repo[2] locally. 
>>>>> 
>>>>> 3.) Each team member modify code and frequently commit to their local 
>>>>> cloned repo.
>>>>> 
>>>>> 4.) When a feature reach do Done-Done state team member can  push to AS 
>>>>> team level repo. 
>>>>> 
>>>>> 5.) Team level Jenkins server automatically trigger a build based on SCM 
>>>>> change just happened and team can validate the change based on build 
>>>>> results. ( In addition to carbon-deployment job team may create Jenkins 
>>>>> jobs for downstream projects to validate the change further )  
>>>>> 
>>>>> 6.) When the team wish to merge above feature to organisational level 
>>>>> repo, a responsible person from the team can send a GIT pull request from 
>>>>> Team repo[2] to GIT proxy available on organisation level Jenkins. 
>>>>> 
>>>>> 7.) "GIT Proxy" accept pull requests from team level repo and trigger a 
>>>>> Jenkins build with  the changes received from current pull request.    
>>>>> 
>>>>> 8.) Eventually Jenkins builds all downstream projects and validate pull 
>>>>> request.
>>>>> 
>>>>> 9.) If any downstream projects build fail then discard the pull request 
>>>>> and notify authors of pull request/commit about the failure.
>>>>> 
>>>>> 10.) If all downstream projects build succeed Jenkins will automatically
>>>>> 
>>>>>         a.) Merge pull request to organisation level  GitHub repo[1] 
>>>>>       
>>>>>         b.) Deploy built artefacts in to Nexus snapshot repo 
>>>>> 
>>>>> 
>>>>> 
>>>>> NOTE - When it come to NON team member contribution, only change is 
>>>>> during the step-4 he can't push to team repo directly instead he will 
>>>>> send a pull request to Team level repo [1].
>>>>> 
>>>>> 
>>>>> Right now we are evaluating number of  solutions to implement  "GIT 
>>>>> Proxy" component and there is a high chance that we will end up writing a 
>>>>> Jenkins plugin to cater this requirement.  In future this 
>>>>> plug-in/solution can be used with AF to cater similar requirements.       
>>>>>   
>>>>> 
>>>>> [1] - https://github.com/wso2/carbon-deployment 
>>>>> [2] - https://github.com/wso2as-developer/carbon-deployment 
>>>>> 
>>>>> 
>>>>> Thanks ! 
>>>>> 
>>>>> 
>>>>> -- 
>>>>> Sagara Gunathunga
>>>>> 
>>>>> Senior Technical Lead; WSO2, Inc.;  http://wso2.com
>>>>> V.P Apache Web Services;    http://ws.apache.org/
>>>>> Linkedin; http://www.linkedin.com/in/ssagara
>>>>> Blog ;  http://ssagara.blogspot.com
>>>> 
>>>> 
>>>> 
>>>> -- 
>>>> Shevan Goonetilleke
>>>> Director of Engineering
>>>> WSO2, Inc.
>>>> lean.enterprise.middleware
>>>> m: +94777340680
>>>> w: http://wso2.com
>>> 
>>> 
>>> 
>>> 
>>> -- 
>>> Afkham Azeez
>>> Director of Architecture; WSO2, Inc.; http://wso2.com
>>> Member; Apache Software Foundation; http://www.apache.org/
>>> 
>>> email: [email protected] cell: +94 77 3320919
>>> blog: http://blog.afkham.org
>>> twitter: http://twitter.com/afkham_azeez
>>> linked-in: http://lk.linkedin.com/in/afkhamazeez
>>> 
>>> Lean . Enterprise . Middleware
>>> _______________________________________________
>>> Architecture mailing list
>>> [email protected]
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>> 
>> _______________________________________________
>> Architecture mailing list
>> [email protected]
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
> 
> 
> 
> -- 
> Thanks & Regards,
> 
> Nuwan Bandara
> Technical Lead; WSO2 Inc. 
> lean . enterprise . middleware |  http://wso2.com 
> blog : http://nuwanbando.com; email: [email protected]; phone: +1 812 606 7390
> 
> _______________________________________________
> Architecture mailing list
> [email protected]
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Reply via email to