On Thu, Feb 13, 2014 at 2:24 AM, Luca Milanesio <[email protected]>wrote:
> 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. > It wont be one big project. It will be many smaller projects with many smaller teams. Each team is less than 15 members so for a set of components there will be maximum of 15 folks. So IMO it wont be much of a problem for us atm. Regards, /Nuwan > > 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/ >> * <http://www.apache.org/>* >> *email: **[email protected]* <[email protected]> >> * cell: +94 77 3320919 <%2B94%2077%203320919> blog: * >> *http://blog.afkham.org* <http://blog.afkham.org> >> *twitter: **http://twitter.com/afkham_azeez*<http://twitter.com/afkham_azeez> >> * linked-in: **http://lk.linkedin.com/in/afkhamazeez >> <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 BandaraTechnical Lead; **WSO2 Inc. * > *lean . enterprise . middleware | http://wso2.com <http://wso2.com> * > > *blog : http://nuwanbando.com <http://nuwanbando.com>; email: > [email protected] <[email protected]>; phone: +1 812 606 7390 > <%2B1%20812%20606%207390> * > <http://www.nuwanbando.com/> > > _______________________________________________ > 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 BandaraTechnical Lead; **WSO2 Inc. * *lean . enterprise . middleware | http://wso2.com <http://wso2.com> * *blog : http://nuwanbando.com <http://nuwanbando.com>; email: [email protected] <[email protected]>; phone: +1 812 606 7390 * <http://www.nuwanbando.com/>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
