As I watch the different threads it is clear that there is a common goal of encouraging everyone to be involved in creating the base line for OASIS code base and there is also a desire to create a working baseline in a timely manner.
Here is an idea that came to my mind that might help. 1. Whoever worked on Equinox branch writes down the principles used to OSGI enable 1.x in Equinox branch. This becomes the guide. 2. Define a subset of the modules *as the goal* of what will first be brought to the trunk. 3. Of that subset define a few modules that everyone can focus on at a time. For example let's bring in module x, y, z into the trunk in the next day. This enables everyone to be focused on the same thing and the work becomes a group effort. 4. Everyone who is interested to get involved will do a diff of the selected equinox modules against the latest 1.x. Review the code while also remembering the principles that were used to make the changes. 5. Post questions if any 6. Move on to the next set if there are no major concerns. This will definitely give people who are interested to be involved a chance to participate, learn and ask questions. With everyone involved in this important base line work, OASIS base line will come to life faster. Haleh On Thu, Nov 13, 2008 at 6:29 AM, ant elder <[EMAIL PROTECTED]> wrote: > > > On Thu, Nov 13, 2008 at 11:20 AM, Simon Laws <[EMAIL PROTECTED]>wrote: > >> Hi Raymond >> >> Thinking about two phases sounds right. Creating the basis for future >> development and then exploiting it. Comments in line. >> >> Simon >> >> snip... >>> >>> >>> Stage 1: Foundation under Construction >>> >>> Community expectations >>> - Focus on cleaning up the core areas (such as assembly model, >>> contribution, core, core-spi, and implementation-java). >>> - Good amount of refactoring may occur >>> - Not ready for adding new functional features before the core is >>> settled. Don't rush to bring it up to the same functionalities as 1.x. >>> - Code will be unstable and/or broken for a couple of weeks >>> >>> >>> 1. Start from empty trunk (after the current trunk is branched off to >>> 1.x) >>> * This gives us the opportunity to start from fresh without being >>> contaminated by what we have in 1.x. >> >> >> I would probably say that this gives us an opportunity to improve what we >> have in 1,x ;-) >> >> >>> >>> 2. Establish processes in the project to keep the code of the foundation >>> clean, simple and interesting to work with. >>> * Some guidelines for package visibility, cross module dependencies, SPI >>> principles >>> * We are producing a guide to help develop Tuscany modules with OSGi >>> - >>> http://cwiki.apache.org/confluence/display/TUSCANY/OSGi+Aware+Programming+in+Tuscany >>> >> >> Agreed. If you have some of these in mind already from the equinox branch >> I would like to see them documented. I would also say there there are plenty >> of existing "patterns" and "processes" that we should add to the list from >> 1.x that are embodied in the Tuscany code base but which are not documented. >> E.g. provider pattern, separation of model from runtime, model >> relationships, runtime creation pattern(although I hope we change this last >> one), >> >> >>> >>> 3. Get the right set of tools from sca-equinox branch to help us enforce >>> and maintain modularity with clean SPIs. >>> * We already have a fairly good developer story in sca-equinox branch: >>> - Leverage Eclipse PDE to develop Tuscany modules as OSGi bundles >>> - Adopt Eclipse JDT compiler with OSGi bundle resolution in maven >>> build >> >> >> Does this approach mandate these tools or are they optional? >> >> >>> >>> >>> 4. Copy modules from sca-equinox branch into trunk >>> * Most of the modules in sca-equinox branch has been converted into OSGi >>> bundles >>> * We have fixed the access violations reported by PDE OSGi validation >>> * Some level of clean-ups have been done >>> * No functional deviations from the modules in the current trunk (1.x) >> >> >> I personally don't mind using the modules that from the branch as a >> starting point however one of my objectives here would be to make sure >> everyone is on board and feels able to contribute to the future development. >> I would propose the following >> >> - Have the minimum set of modules only in trunk to start with. This allows >> us to focus, without distraction, on what changes are really required and >> also gives us the opportunity to think about how these modules should be >> (re)structured. >> - Have a detailed explanation of how these modules differ from those in >> 1.x so that those of us who haven't been intimately involved in the equinox >> work can be brought up to speed with what changes were made and why. >> - Review this minimum set of modules in for the various issues from the >> "themes" thread that we think need to come in stage 1. >> - Once done we are ready to move to stage 2 with a set of bet practice in >> place. >> >> > > I agree with making sure everyone is on board and feels able to contribute > to the future development, and that there is no feeling of control or > ownership. So, if it was an ideal world my preference would be to start with > the minimum modules being from the existing trunk and then do small discrete > changes to merge changes from the sca-equinox branch with clear explanations > so its really easy for everyone to see what changes are being made. > > ...ant > >
