On Wed, Nov 12, 2008 at 11:08 AM, ant elder <[EMAIL PROTECTED]> wrote:
> > > On Wed, Nov 12, 2008 at 6:34 AM, Ramkumar R <[EMAIL PROTECTED]> wrote: > >> Hi Simon, >> My preference would be to "Start with the smallest set of modules possible >> and iterate toward OASIS compliance adding in more function/extensions as >> people address different features/specifications", >> as I believe this option would give us a more clear direction on where we >> are heading towards. >> >> >> On Tue, Nov 11, 2008 at 3:02 PM, Simon Laws <[EMAIL PROTECTED]>wrote: >> >>> Several alternatives have been suggested [1] which I summarize here. >>> >>> A) Start from what we already have in trunk, develop the OASIS function, >>> introduce new improvements or improvements from the Equinox branch as >>> appropriate >>> B) Start from a completely clean trunk and build up from there based on >>> the resources we have in the the 1.x code stream, in the Equinox branch or >>> from new developments >>> C) Start from what is in the Equinox branch >>> >>> Is this correct? Are there other combinations people want to consider? >>> There is a related question of how we develop trunk toward OASIS compliance. >>> I see two extremes; >>> >>> i) Start with a full set of modules and update to OASIS compliance while >>> keeping all the function we have running >>> ii) Start with the smallest set of modules possible and iterate toward >>> OASIS compliance adding in more function/extensions as people address >>> different features/specifications. >>> >>> Again, are there other approaches? >>> >>> The object of this discussion is to agree the starting point for future >>> trunk development. If you don't have other options to add it would be useful >>> for you to express a preference so we can see what people think. If we can't >>> come to a conclusion in the next couple of days though this discussion we >>> will have to identify a small number of options to vote on. >>> >>> Thanks >>> >>> Simon >>> >>> [1] http://www.mail-archive.com/dev%40tuscany.apache.org/msg03215.html >>> >> >> > I liked what was said over on the other thread [1]: > > "...starting afresh in trunk based on the assets that we already have, > primarily that it gives us all the opportunity to feel involved in how > Tuscany v2.0 will look" > > So i guess thats closest to (B ii). Its not that clear yet how this would > actually work but it sounds like a good thing to aim for. > > ..ant > > [1] http://apache.markmail.org/message/apawwigihmpgx7sk > > > > Yes, my choice would be B ii also. How would this work? Firstly I'd like to see us define a relatively short (max two weeks?) timescale for getting the minimal function working in the new trunk. This will focus the mind and help us not get sidetracked with other fluff. I would propose that we set ourselves the objective of getting a simple scenario (e.g. calculator) working to demonstrate the trunk structure and operation. We need to identify those issues that must be addressed in this bring up stage and define a strategy for address them. I believe this will come out of the themes thread. Then work out who wants to tackle each topic and drive the thrashing out of the details on the ML/in the code . We may have to accept that there may be things we can't do in parallel so this has to be a collaborative exercise with those currently active keeping the ML up to date giving the opportunity for others to jump in. Ultimately one person is going to have to commit some initial modules to trunk and we will soon hit the "where do they come from issues". To help me with this question I'd like use to understand 1. What modules from trunk today would be the minimum set needed. I can go an pull the dependency list from the calculator sample. 2. With this minimum set what is the difference between these and what is in the Equinox branch. Can someone familiar with the branch explain please? Once we get to the minimum function stage we can test it and introduce other features and changes in a controlled manner while adopting the best practice that has been established. Simon
