On Sun, Jan 19, 2014 at 9:53 AM, Selvaratnam Uthaiyashankar < [email protected]> wrote:
> > > > On Sun, Jan 19, 2014 at 11:02 PM, Sameera Jayasoma <[email protected]>wrote: > >> Hi Azeez, >> >> +1 for this model. This will solve most of the issues that we are facing >> in the current system. >> >> >> Senaka, see my comment below. >> >> On Sat, Jan 18, 2014 at 10:48 AM, Senaka Fernando <[email protected]>wrote: >> >>> Hi Azeez, Eranda, >>> >>> +1 for the proposed changes. So, as discussed we have two options. >>> >>> 1. In the git repo, go for wso2/carbon/feature or wso2/carbon/product >>> model and then have features such as registry, governance and products such >>> as esb. >>> >> >> >> I am + for the Option 1 if possible. >> > > > With this option, shouldn't we checkout the whole components? AFAIK, GIt > doesn't support checking out part of the repo. Also, the release, branching > etc. will be at the repo level, can't be at a sub repo level. Above > structure is what we have now and is the reason for most of the trouble we > are having, isn't it? > No Shankar, all the components will be separate projects on their own. But this is just a matter of organizing them in a proper order without putting everything to the top level. (only if this is possible.) e.g. https://github.com/wso2/carbon/components/identity If this is not possible, then I prefer *carbon-component-* instead of carbon-feature-*. * Because IMHO, components are what we develop and features are just a way of installing these components to projects. We may end up multiple features for a given component or features which combine multiple components. > > > >> That will allows developers to easily navigate to the relevant >> component. >> >> How about using wso2/carbon/components instead of features. What we >> really develop is components? I would prefer to use the word component >> rather than using the word feature. >> >> WDYT? >> >> >>> 2. Go with the model Azeez wrote in e-mail. >>> >> >> With option 2, we will end up with many top level projects under wso2/. >> >>> >>> We need to figure out whether git supports #1 and if not go for #2. >>> >>> Also, wanted to highlight that we will no longer have service-stubs, and >>> separate features categories. There will be no concept of parent, since >>> each feature will define its own dependencies *excluding transitive >>> dependencies*. The development governance system that we put in place >>> will ensure we reuse the same versions and a separate pom is unwanted. >>> >>> Further, all branched dependencies and orbits will reside outside of our >>> code structure, and those should follow separate release models as >>> discussed previously. >>> >>> Next, we will integrate GerritHub for code reviews. >>> >>> Thanks, >>> Senaka. >>> >>> On Sat, Jan 18, 2014 at 10:31 AM, Afkham Azeez <[email protected]> wrote: >>> >>>> Shall we name those as; >>>> >>>> - carbon-feature-registry >>>> - carbon-feature-governance >>>> - carbon-feature-identity >>>> - carbon-feature-mediation >>>> - carbon-feature-analytics >>>> - carbon-feature-data >>>> - carbon-feature-apis >>>> - carbon-feature-business-process >>>> - carbon-feature-business-messaging >>>> - carbon-feature-rules >>>> - carbon-feature-deployment >>>> - carbon-feature-qos >>>> - carbon-feature-utils >>>> >>>> and also have; >>>> * carbon-product-appserver >>>> * carbon-product-esb >>>> >>>> and so on. >>>> >>>> Also; >>>> carbon-p2-repo >>>> >>>> carbon-platform-integration-tests >>>> >>>> >>>> >>>> >>>> On Sat, Jan 18, 2014 at 9:12 AM, Eranda Sooriyabandara <[email protected] >>>> > wrote: >>>> >>>>> Hi Infra, >>>>> Can we have following projects created in the git repo. Additionally >>>>> >>>>> - registry >>>>> - governance >>>>> - identity >>>>> - mediation >>>>> - analytics >>>>> - data >>>>> - apis >>>>> - business-process >>>>> - business-messaging >>>>> - rules >>>>> - deployment >>>>> - qos >>>>> - utils >>>>> >>>>> Additionally please add me (erandasooriyabandara) to WSO2 member list. >>>>> >>>>> thanks >>>>> Eranda >>>>> >>>>> >>>>> On Fri, Jan 17, 2014 at 9:26 PM, Afkham Azeez <[email protected]> wrote: >>>>> >>>>>> [Sorry for the very long mail. I want to document all that I had in >>>>>> mind & the stuff we discussed. I would recommend all devs to take some >>>>>> time >>>>>> to read this] >>>>>> >>>>>> >>>>>> I would like to summarize he discussion we had a couple of days back. >>>>>> >>>>>> *The Problems* >>>>>> The problems we are trying to solve are as follows: >>>>>> >>>>>> 1. Trunk & branches structures being completely different >>>>>> 2. Branches containing directories with version numbers >>>>>> 3. It is impossible to move to GitHub with the current structure >>>>>> because of #2 >>>>>> 4. It is very easy to break the build by changing already released >>>>>> code. The room for human error is high. >>>>>> 5. Bamboo builds are eternally broken because the build fails at some >>>>>> point & Bamboo cannot continue any further >>>>>> 6. When we branch, the trunk quickly becomes obsolete, and remains in >>>>>> that broken state until the next major platform release. >>>>>> 7. Everybody has to build all components/features, even if those are >>>>>> not related to their products >>>>>> 8. Fixed versions in branches instead of using SNAPSHOT versions. >>>>>> This makes it impossible to upload build artifacts to Maven/Nexus repos. >>>>>> This leads to #7. >>>>>> 9. Impossible to integrate code quality tools such as EraInsight >>>>>> because of #5 >>>>>> >>>>>> *Proposed solution* >>>>>> We have come up with the following solution after much deliberation & >>>>>> thought. >>>>>> >>>>>> Rationale: >>>>>> We started looking at other open source projects out there. We took >>>>>> Axis2 as an example. Axis2 had many dependencies including Axiom, >>>>>> XmlSchema, Woden, WSS4J etc. Those 3rd party dependencies were also >>>>>> developed by some Axis2 contributors, but we never branched all of those >>>>>> together and brought them into the same code branch. We used to start >>>>>> what >>>>>> we used to call a release train, where the upstream code would have to be >>>>>> released first before the downstream code such as Axis2 & Synapse could >>>>>> be >>>>>> released. This way, we never had any of the problems outlined above. >>>>>> >>>>>> If you look at the WSO2 product releases, again, the scenario is not >>>>>> that much different from the Axis2/Synapse releases. Components & >>>>>> features >>>>>> are simply dependencies of the products. In order to get product releases >>>>>> out, we first need releases of those dependencies (components/features). >>>>>> So >>>>>> the proposal is to identify the top level components/features, and first >>>>>> release that code before doing product releases. Each of those components >>>>>> will have a GitHub repo. All active development will be done on the main >>>>>> branch of those components, and will be branched when they are close to >>>>>> the >>>>>> release. Instead of granting commit rights to all, we could only allow >>>>>> the >>>>>> primary developers of those components to commit, and others can send >>>>>> pull >>>>>> requests, which will be merged in by the primary owners after reviewing. >>>>>> These component teams could even have an internal Git repo or clone, and >>>>>> commit to that, run all tests, and when they are satisfied that the code >>>>>> is >>>>>> in a good state to be merged into the main branch, they can send a pull >>>>>> request & merge the changes. We would run Bamboo which would build the >>>>>> components several times a day & deploy them to the Nexus repo. That way, >>>>>> you would not have to build code that is not directly related to what you >>>>>> are working on, which would save 100s of valuable dev hours. >>>>>> >>>>>> In the majority of the cases, the P2 features correspond to one or >>>>>> more related components. So we would keep the feature close to the >>>>>> component. There are some cases where these components & features belong >>>>>> in >>>>>> the product itself. AppFactory components are a good example. >>>>>> >>>>>> Products will also have their own GitHub repos. We will have separate >>>>>> GitHub repos for platform integration tests. Products such as API Manager >>>>>> may opt to have the API Management feature in the product itself. We >>>>>> would >>>>>> have a separate P2-repo GitHub repo which would build & deploy the >>>>>> compatible set of P2 features. >>>>>> >>>>>> We will have Bamboo plans at multiple levels; components, products, >>>>>> platform, p2-repo and so on. >>>>>> >>>>>> We will not change any package structures at this time. We would >>>>>> defer that to Carbon 5 (if necessary). We will get rid of the chunk based >>>>>> release model. Continuous delivery is our ultimate aim & for that to >>>>>> happen, we have to release a compatible set of features. We are going to >>>>>> rely heavily on automation, automated builds & deploys to Maven. The >>>>>> developers will do the majority of the QA (just like the Apache Stratos >>>>>> team is doing now). >>>>>> >>>>>> We will use the Maven release plugin to create releases & upload them >>>>>> to the Maven repo. >>>>>> >>>>>> *Implications to WSO2 code developers* >>>>>> 1. Life becomes easier because you don't have to spend a lot of time >>>>>> building unrelated stuff >>>>>> 2. General development would happen in the main branch. >>>>>> 3. Close to a release, branches would be cut. >>>>>> 4. Once release branches are cut, fixes would be done in the main >>>>>> branch, and pull requests would be sent to the branch & merged in. This >>>>>> will be easy because we no longer have the trunk & branch structure being >>>>>> different. >>>>>> >>>>>> >>>>>> *Implications to users* >>>>>> Users will not see any difference in the components & features >>>>>> because we are not changing packages or binary structure. In fact, we >>>>>> would >>>>>> have a P2 repo with compatible features which all work together. >>>>>> >>>>>> Senaka, Isuruwan & Harshana have already started working on a PoC. >>>>>> >>>>>> Thoughts welcome. Those who were in these discussions, please add >>>>>> anything I may have missed. >>>>>> >>>>>> -- >>>>>> *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 >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> >>>>> *Eranda Sooriyabandara*Senior Software Engineer; >>>>> Integration Technologies Team; >>>>> WSO2 Inc.; http://wso2.com >>>>> Lean . Enterprise . Middleware >>>>> >>>>> E-mail: eranda AT wso2.com >>>>> Mobile: +94 716 472 816 >>>>> Linked-In: http://www.linkedin.com/in/erandasooriyabandara >>>>> Blog: http://emsooriyabandara.blogspot.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* >>>> >>> >>> >>> >>> -- >>> *Senaka Fernando* >>> Senior Technical Lead; WSO2 Inc.; http://wso2.com >>> >>> >>> >>> * Member; Apache Software Foundation; http://apache.org >>> <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1 >>> 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*; >>> >>> >>> *M: +94 77 322 1818 <%2B94%2077%20322%201818> Linked-In: >>> http://linkedin.com/in/senakafernando >>> <http://linkedin.com/in/senakafernando>* >>> Lean . Enterprise . Middleware >>> >> >> >> >> -- >> Sameera Jayasoma, >> Architect, >> >> WSO2, Inc. (http://wso2.com) >> email: [email protected] >> blog: http://sameera.adahas.org >> twitter: https://twitter.com/sameerajayasoma >> flickr: http://www.flickr.com/photos/sameera-jayasoma/collections >> Mobile: 0094776364456 >> >> >> Lean . Enterprise . Middleware >> > > > > -- > S.Uthaiyashankar > VP Engineering > WSO2 Inc. > http://wso2.com/ - "lean . enterprise . middleware" > > Phone: +94 714897591 > -- Sameera Jayasoma, Architect, WSO2, Inc. (http://wso2.com) email: [email protected] blog: http://sameera.adahas.org twitter: https://twitter.com/sameerajayasoma flickr: http://www.flickr.com/photos/sameera-jayasoma/collections Mobile: 0094776364456 Lean . Enterprise . Middleware
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
