Can we also elaborate how the release train will come together based on the proposed structure? Best to look at the end to end picture and optimize before we conclude and implement.
There are two release mechanisms we need to support: 1. Hosted packs - we probably will limit these to 2-3 releases per year as discussed at the offsite. Products that are ready when the release branch is cut and have aligned all dependency releases accordingly will get released on fixed release dates through the year. 2. Cloud releases for components/products. This will be much more frequent and will leverage continuous delivery mechanisms to enable small changes and bug fixes to get released, may be every two weeks to start with. Whats the best way to support both of these in parallel with the proposed repository and branching structure? We need to consider how to version the smaller releases that go on the cloud and also the larger hosted versions that combine changes released to the cloud over several months. WDYT? On Tue, Jan 21, 2014 at 2:05 AM, Selvaratnam Uthaiyashankar < [email protected]> wrote: > One issue is, we will loose commit information (svn blame) when we move to > github. Any way to import the code with those information? > > Regards, > Shankar > > > On Mon, Jan 20, 2014 at 10:59 AM, Eranda Sooriyabandara > <[email protected]>wrote: > >> Hi All, >> As a PoC I just completed the carbon-component-governance. Please find it >> in [1] and let me know your comments and suggestions. Please keep in mind >> that this is not in a buildable state since other components need to build >> before this. >> >> thanks >> Eranda >> >> [1] https://github.com/wso2/carbon-component-governance >> >> >> 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/ >> >> >> >> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > S.Uthaiyashankar > VP Engineering > WSO2 Inc. > http://wso2.com/ - "lean . enterprise . middleware" > > Phone: +94 714897591 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Shevan Goonetilleke Director of Engineering WSO2, Inc. lean.enterprise.middleware m: +94777340680 w: http://wso2.com
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
