On Mon, Nov 17, 2008 at 11:12 AM, ant elder <[EMAIL PROTECTED]> wrote:
> I think its important that we understand what changes have been made in the > branch, but I'm having some trouble working out the detail and questions > asking for more detail are not getting many answers. > > In the past when asking what would happen with the branch there have been > answers like: "we'll have something to look at and reflect on in the branch. > It's always much easier to do things a second time, when somebody has > already been through the pain of exploring it for you and you can take a > look at the result." > > I think that could be the best approach. Instead of a wholesale replacing > of trunk modules with the modules from the branch start with the trunk > modules and try to replicate the functional changes one by one so we can all > see and understand the changes. This approach is much more community > friendly and avoids anything like a divisive vote on replacing trunk. I'm > going to start trying to do this now. > > ...ant > > > On Mon, Nov 17, 2008 at 3:54 AM, Luciano Resende <[EMAIL PROTECTED]>wrote: > >> On Sun, Nov 16, 2008 at 1:39 PM, Raymond Feng <[EMAIL PROTECTED]> >> wrote: >> > Hi, >> > >> > Thank you for the assessment. What about we do the following? >> > >> > 1. Start with an empty trunk. >> >> +1 >> >> > 2. Try a best-effort merge to pull the delta from 1.x branch into >> > sca-equinox branch (potentially leave some hard-to-merge changes to the >> > bringup phase) >> >> I' m not sure exactly how to handle this as a community effort, maybe >> the best way would be for each individual that have changes in trunk >> to verify what needs to be merged and help with that portion ? Well, >> just a thought... >> >> > 3. Copy the sca-equinox branch into the new trunk and move modules into >> > "java/sca/contrib" >> >> I don' t know exactly what' s the benefit of a contrib folder, but I' >> m ok with this. Note that, we should have all modules loaded in >> eclipse when doing clean up/refactoring to allow the IDE tools to help >> with refactoring the dependencies. >> >> > 4. Move the core set of module into "java/sca/modules" and clean them up >> > thoroughly (we already have a list of actions) >> > 5. Incrementally bring up other modules from contrib into >> "java/sca/modules" >> > >> >> Overall, sounds like a good strategy... >> Does anybody have any objections ? >> What should be our next step ? >> >> >> > Thanks, >> > Raymond >> > -------------------------------------------------- >> > From: "Luciano Resende" <[EMAIL PROTECTED]> >> > Sent: Friday, November 14, 2008 9:56 PM >> > To: <dev@tuscany.apache.org>; <[EMAIL PROTECTED]> >> > Subject: Re: [PROPOSAL] A staged approach to create the OASIS >> development >> > stream in trunk >> > >> >> On Thu, Nov 13, 2008 at 9:38 AM, ant elder <[EMAIL PROTECTED]> >> wrote: >> >>> >> >>> >> >>> On Thu, Nov 13, 2008 at 5:18 PM, Simon Laws < >> [EMAIL PROTECTED]> >> >>> wrote: >> >>>> >> >>>> >> >>>> On Thu, Nov 13, 2008 at 4:30 PM, haleh mahbod <[EMAIL PROTECTED]> >> wrote: >> >>>>> >> >>>>> 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 >> >>>>> ...snip >> >>>> >> >>>> Re. point 2 running the dependency lister on samples/calculator in >> trunk >> >>>> gives. >> >>>> >> >>>> tuscany-assembly-1.4-SNAPSHOT.jar >> >>>> tuscany-assembly-xml-1.4-SNAPSHOT.jar >> >>>> tuscany-assembly-xsd-1.4-SNAPSHOT.jar >> >>>> tuscany-binding-sca-1.4-SNAPSHOT.jar >> >>>> tuscany-binding-sca-xml-1.4-SNAPSHOT.jar >> >>>> tuscany-contribution-1.4-SNAPSHOT.jar >> >>>> tuscany-contribution-impl-1.4-SNAPSHOT.jar >> >>>> tuscany-contribution-java-1.4-SNAPSHOT.jar >> >>>> tuscany-contribution-namespace-1.4-SNAPSHOT.jar >> >>>> tuscany-contribution-xml-1.4-SNAPSHOT.jar >> >>>> tuscany-core-1.4-SNAPSHOT.jar >> >>>> tuscany-core-databinding-1.4-SNAPSHOT.jar >> >>>> tuscany-core-spi-1.4-SNAPSHOT.jar >> >>>> tuscany-databinding-1.4-SNAPSHOT.jar >> >>>> tuscany-databinding-jaxb-1.4-SNAPSHOT.jar >> >>>> tuscany-definitions-1.4-SNAPSHOT.jar >> >>>> tuscany-definitions-xml-1.4-SNAPSHOT.jar >> >>>> tuscany-endpoint-1.4-SNAPSHOT.jar >> >>>> tuscany-extensibility-1.4-SNAPSHOT.jar >> >>>> tuscany-implementation-java-1.4-SNAPSHOT.jar >> >>>> tuscany-implementation-java-runtime-1.4-SNAPSHOT.jar >> >>>> tuscany-implementation-java-xml-1.4-SNAPSHOT.jar >> >>>> tuscany-implementation-node-1.4-SNAPSHOT.jar >> >>>> tuscany-interface-1.4-SNAPSHOT.jar >> >>>> tuscany-interface-java-1.4-SNAPSHOT.jar >> >>>> tuscany-interface-java-jaxws-1.4-SNAPSHOT.jar >> >>>> tuscany-interface-java-xml-1.4-SNAPSHOT.jar >> >>>> tuscany-monitor-1.4-SNAPSHOT.jar >> >>>> tuscany-node-api-1.4-SNAPSHOT.jar >> >>>> tuscany-node-impl-1.4-SNAPSHOT.jar >> >>>> tuscany-policy-1.4-SNAPSHOT.jar >> >>>> tuscany-policy-xml-1.4-SNAPSHOT.jar >> >>>> tuscany-sca-api-1.4-SNAPSHOT.jar >> >>>> tuscany-xsd-1.4-SNAPSHOT.jar >> >>>> >> >>>> I expect the list from the equinox branch might be slightly different >> >>>> but >> >>>> it shows the scale of things. It's not a very long list. If we get >> the >> >>>> overall principles documented as they stand at the moment the we can >> >>>> review >> >>>> the individual modules. I realize this sounds like a compromise >> between >> >>>> Raymond's and Ant's suggestions but I think we will have to take it >> >>>> module >> >>>> by module. There are probably some less controversial ones that we >> can >> >>>> put >> >>>> in place to start with, sca-api (even this though there were the >> license >> >>>> changes in trunk that we need to make sure we get)? However I was >> just >> >>>> diffing assembly, which I thought would be straightforward, but >> noticed >> >>>> that >> >>>> it has the builder pluggability changes in there in the branch. I >> think >> >>>> we >> >>>> want them but we need to understand them. >> >>>> >> >>>> So against each of these I think it warrents a summary of the changes >> >>>> (given this restricted list I hope someone familiar with the branch >> can >> >>>> just >> >>>> do this off the top of their heads). >> >>> >> >>> +1, i don't think its enough to say we can just look at an svn diff as >> >>> there >> >>> are so many changes, even a diff on just a single random module - >> >>> assembly-xml - gives a 180K diff file which runs at 64 full screens >> of >> >>> text >> >>> to work out. >> >>> >> >>> >> >>>> >> >>>> We may actually find it easier to go from trunk in terms of unpicking >> >>>> all >> >>>> this but I hold an open mind. >> >>>> >> >>> >> >>> I'm leaning to that as well, with diffs showing so many changes mixed >> >>> together or would be easier to understand descrete changes merged into >> >>> the >> >>> existing trunk - eg each module needs the correct manifest this merge >> >>> shows >> >>> one, now lets do the same for each other module etc. >> >>> >> >>> ...ant >> >>> >> >>> >> >> >> >> >> >> I did some research around the delta between trunk and the equinox >> >> branch, and also possible ways to merge, below are my findings : >> >> >> >> >> >> Equinox/Trunk developer streams >> >> >> >> >> >> /---------------------------> 345 commits to equinox branch >> >> / >> >> / SVN Revision #694816 - Sep 12 - Equinox branch created >> >> / >> >> --------------------------------------> 203 committs to trunk >> >> >> >> >> >> The detailed list of changes that went in equinox branch is available >> at : >> >> >> >> >> >> >> http://people.apache.org/~lresende/tuscany/sca-equinox/sca-equinox-changes.txt<http://people.apache.org/%7Elresende/tuscany/sca-equinox/sca-equinox-changes.txt> >> >> >> >> Trying to execute a merge from trunk to the equinox branch : >> >> Conflicted:86 Skipped:227 Added:654 Deleted:11 Updated:370 >> >> >> >> The merge details are on the link below >> >> >> >> >> >> >> http://people.apache.org/~lresende/tuscany/sca-equinox/sca-equinox-merging-from-trunk.txt<http://people.apache.org/%7Elresende/tuscany/sca-equinox/sca-equinox-merging-from-trunk.txt> >> >> >> >> Trying to execute a merge from equinox branch to trunk >> >> Conflicted:159 Skipped:264 Added:570 Deleted:26 Updated:314 >> >> >> >> The merge details are on the link below >> >> >> >> >> http://people.apache.org/~lresende/tuscany/sca-equinox/sca-trunk-partially-merging-from-equinox.txt<http://people.apache.org/%7Elresende/tuscany/sca-equinox/sca-trunk-partially-merging-from-equinox.txt> >> >> >> >> >> >> My recommendation would be to start with a clean trunk, move >> >> sca-equinox/modules/ to the new trunk and then define a subset of >> >> modules to work on. Having all the modules available would allow us to >> >> take advantage of IDE tools, and have code refactoring being applied >> >> to dependent modules easily. Also, any issues in the affected modules >> >> can be handle when we still have the changes fresh in our heads :) >> >> >> >> As for merging, from the exercise described above, starting from the >> >> equinox branch code makes a less painful merge, but I don't think >> >> there is any way that we can come up with an easy and simple way to >> >> execute the merge, and the less painful option that comes to mind is >> >> to evaluate changes done in a given module when working on it, and >> >> identify witch changes need to be applied to the current code in the >> >> new trunk, and then either merge or port the changes. I also have a >> >> feeling that it's probably not a good idea to try batch-merge of a >> >> large range of revisions, as this might be timing consuming, bring >> >> unnecessary changes or changes that need to be refactored to be a good >> >> citizen in a modular OSGi environment. >> >> >> >> >> >> Thoughts ? >> >> >> >> -- >> >> Luciano Resende >> >> Apache Tuscany, Apache PhotArk >> >> http://people.apache.org/~lresende<http://people.apache.org/%7Elresende> >> >> http://lresende.blogspot.com/ >> > >> > >> >> >> >> -- >> Luciano Resende >> Apache Tuscany, Apache PhotArk >> http://people.apache.org/~lresende <http://people.apache.org/%7Elresende> >> http://lresende.blogspot.com/ >> > > Hi Luciano, thanks for taking a look at the diffs.It does seem that we pretty much have agreement on the approach apart from the important question of whether we start from the equinox branch and apply changes from the existing trunk or start from the existing trunk and apply changes from equinox. Looking at Luciano's post it looks like which ever way we go we will still apply the sequence of changes manually. Can we then take this opportunity to go ahead and do that based on the trunk code as it stands taking whatever changes we need from the equinox branch. Gives slackers like me who haven't caught up with the equinox branch to watch all the changes as they happen. I've put time aside this week to help get the 2.0 bring up in trunk underway so I can contribute effort as appropriate. So leads to a slight change to Raymond's list of steps; 1. Start with current trunk (will be notionally contain the minimum set of modules when we move the majority of modules into /contrib) 2. Try a best-effort merge to pull the delta from sca-equinox branch into trunk (potentially leave some hard-to-merge changes to the bringup phase) 3. move modules into "java/sca/contrib" 4. Move the core set of module into "java/sca/modules" and clean them up thoroughly (we already have a list of actions). Includes creating minimal distriibution directory contents 5. Incrementally bring up other modules from contrib into "java/sca/modules" A question based on the comment about using tooling to refactor all the modules. Sounds ok to me and shouldn't be adversely affected by having some modules in /contrib. In the equinox branch, as things have been refactored, have you been testing all the modules or just committing changes with a view to testing them at some point in the future? Simon
