Hi Amila, On Tue, Jun 11, 2013 at 10:18 PM, Amila Suriarachchi <[email protected]> wrote:
> > > > On Mon, Jun 10, 2013 at 7:17 AM, Amila Suriarachchi <[email protected]>wrote: > >> >> >> >> On Mon, Jun 10, 2013 at 7:15 AM, Amila Suriarachchi <[email protected]>wrote: >> >>> >>> >>> >>> On Mon, Jun 10, 2013 at 7:09 AM, Afkham Azeez <[email protected]> wrote: >>> >>>> On Mon, Jun 10, 2013 at 7:32 PM, Amila Suriarachchi <[email protected]> >>>> wrote: >>>> > >>>> > >>>> > >>>> > On Mon, Jun 10, 2013 at 3:02 AM, Afkham Azeez <[email protected]> wrote: >>>> >> >>>> >> Unfortunately, our code repo structure & build structure is insanely >>>> >> complex. This is the reason why it is so hard to prevent build >>>> breaks. We >>>> >> need to think of a much simplified structure. Too much complexity >>>> always >>>> >> leads to human error. We need to simplify everything, starting from >>>> the repo >>>> >> structure. >>>> > >>>> > >>>> > +1 to have a simplified repo structure. >>>> > >>>> > But a major problem I see here is that there is no proper process in >>>> > development. In other words one way to handle complex structures is >>>> to using >>>> > proper process. >>>> >>>> The problem there is that people have to know the process. >>> >>> >>> In order to know the process we need to have a process. Having a >>> simplified process is the best one. >>> >> >> If we look at patch creation process. it is complicated but at least have >> a documented process. so people follow that. >> > > I have a possible solution for this. It is some what related to you have > mentioned as well. > > As I chat offline the real problem here is we have a one component space > which suppose to depends only one carbon version. Now what if we divide the > component space and the feature space according to the products. > > common > as > dss > esb > apim > bps > This did came across my mind. But how do we specify the common set. Most of the components are used by atleast two products. So this will end up in having a very large common set and only very few components/features under individual products. May be none for some products. thanks, > > In here we have a set of common components which are shared by all carbon > products. In fact these components and stable and most of the time > development happens at the product level. In other words we bring the > product specific component and features to product level. > > The advantage of this method is there is no requirement product specific > features to depends on the trunk version. People can develop based on a > released carbon platform version while working on the trunk. > > thanks, > Amila. > >> >> thanks, >> Amila. >> >>> >>> thanks, >>> Amila. >>> >>> >>>> When the >>>> process itself is complicated, it becomes easy to miss things & make >>>> mistakes. >>>> >>>> For an example, how one can develop a feature hence a new >>>> > version of a product based on a released carbon kernel? >>>> > >>>> > Current model is to develop at the branch and later commit the code >>>> back. >>>> > For me this is a duplicate issue and can lost many commits. >>>> > >>>> > thanks, >>>> > Amila. >>>> > >>>> >> >>>> >> >>>> >> Azeez >>>> >> >>>> >> >>>> >> On Mon, Jun 10, 2013 at 3:20 PM, Sriskandarajah Suhothayan < >>>> [email protected]> >>>> >> wrote: >>>> >>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> On Mon, Jun 10, 2013 at 1:48 PM, Afkham Azeez <[email protected]> >>>> wrote: >>>> >>>> >>>> >>>> Folks, >>>> >>>> Can somebody let me know how to do this? I seem to have forgotten >>>> the >>>> >>>> process, and everuthing looks very confusing. Some orbit bundles >>>> are in >>>> >>>> trunk, some are in different branches... it is not easy to find >>>> where the >>>> >>>> Hazelcast orbit is :( >>>> >>>> >>>> >>> The Hazelcast orbit[1] was removed as its now graduated >>>> >>> >>>> >>>> This orbit bundle will be needed by all components & the kernel. >>>> >>> >>>> >>> >>>> >>> If you are directly using the the lib to build the bundle then that >>>> need >>>> >>> to be added to the main orbit >>>> >>> The orbits under the dependencies are only used to bundle the >>>> relevant >>>> >>> dependencies >>>> >>> >>>> >>> Suho >>>> >>> >>>> >>> >>>> >>> [1] >>>> https://svn.wso2.org/repos/wso2/carbon/orbit/branches/4.0.0/hazelcast/2.2.wso2v1/ >>>> >>> >>>> >>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> -- >>>> >>>> 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 >>>> >>>> >>>> >>>> _______________________________________________ >>>> >>>> Dev mailing list >>>> >>>> [email protected] >>>> >>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>> >>>> >>>> >>> >>>> >>> >>>> >>> >>>> >>> -- >>>> >>> S. Suhothayan >>>> >>> Associate Technical Lead, >>>> >>> Management Committee Member, Data Technologies Team, >>>> >>> WSO2 Inc. http://wso2.com >>>> >>> lean . enterprise . middleware >>>> >>> >>>> >>> cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/ >>>> >>> twitter: http://twitter.com/suhothayan | linked-in: >>>> >>> http://lk.linkedin.com/in/suhothayan >>>> >>> >>>> >> >>>> >> >>>> >> >>>> >> -- >>>> >> 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 >>>> > >>>> > >>>> > >>>> > >>>> > -- >>>> > Amila Suriarachchi >>>> > >>>> > Software Architect >>>> > >>>> > WSO2 Inc. ; http://wso2.com >>>> > lean . enterprise . middleware >>>> > >>>> > phone : +94 71 3082805 >>>> >>>> >>>> >>>> -- >>>> 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://twitter.com/afkham_azeezlinked-in>: >>>> http://lk.linkedin.com/in/afkhamazeez >>>> >>>> Lean . Enterprise . Middleware >>>> >>> >>> >>> >>> -- >>> *Amila Suriarachchi* >>> >>> Software Architect >>> WSO2 Inc. ; http://wso2.com >>> lean . enterprise . middleware >>> >>> phone : +94 71 3082805 >>> >> >> >> >> -- >> *Amila Suriarachchi* >> >> Software Architect >> WSO2 Inc. ; http://wso2.com >> lean . enterprise . middleware >> >> phone : +94 71 3082805 >> > > > > -- > *Amila Suriarachchi* > > Software Architect > WSO2 Inc. ; http://wso2.com > lean . enterprise . middleware > > phone : +94 71 3082805 > > _______________________________________________ > Dev mailing list > [email protected] > http://wso2.org/cgi-bin/mailman/listinfo/dev > > -- Supun Malinga, Senior Software Engineer, WSO2 Inc. http://wso2.com http://wso2.org email - [email protected] <[email protected]> mobile - 071 56 91 321
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
