On Wed, Mar 16, 2011 at 11:47 AM, Pradeep Fernando <[email protected]> wrote: > On Wed, Mar 16, 2011 at 11:25 AM, Hiranya Jayathilaka <[email protected]> > wrote: >> >> >> On Wed, Mar 16, 2011 at 11:08 AM, Pradeep Fernando <[email protected]> wrote: >>> >>> Hi hiranya, comments inline, >>> >>> >>> >>> On Wed, Mar 16, 2011 at 10:53 AM, Hiranya Jayathilaka <[email protected]> >>> wrote: >>> > Hi Folks, >>> > I can see a bunch of Orbit bundles have been graduated (moved from trunk >>> > to >>> > a separate location) recently. What is the criteria for selecting >>> > components/Orbit bundles for graduation? >>> >>> We selected the bundles based on the recent active levels. As i have >>> explained you in the offline chat. >> >> This might work for Carbon components. But IMO it's not the right criteria >> for Orbit bundles. We should not graduate an Orbit bundle unless the >> corresponding third party project is dead. We need to keep upgrading the >> Orbit bundles because the users always prefer the latest versions of the 3rd >> party dependencies. > > No it does not work for carbon components. Although, we think carbon > components are stable, they are not. some given days we encounter > issues that affects all the components. The orbit is the perfect > candidate for graduation. Although the third party project is very > alive, as long as we are not using their SNAPSHOT versions (like > axis2) the can be graduated. (we are using a fix version.) due to the > grouping we can get a clear idea, which orbit bundle shipped with what > version of carbon. > > > >> >>> >>> > Also in case of Orbit bundles, we need to upgrade the dependency >>> > versions >>> > time to time. Whenever the corresponding 3rd party projects make a >>> > release >>> > we should look into upgrading the dependency versions. I'm facing this >>> > situation with HAPI library right now (for HL7) which is already >>> > graduated. >>> > What is the process to upgrade a graduated module? Should I un-graduate >>> > it >>> > back to the trunk? >>> >>> you have to do a svn copy in the trunk, modify it, update the >>> versions, and after the release you should graduate your bundle again >>> and remove the source from the trunk. >> >> No this doesn't sound right. This is way too much work for a simple version >> change in a dependency. May be the problem here is the graduation of the >> Orbit bundle itself. > > At this point I'm inclined to simply put this back to >> the trunk and live with it. > > At a later stage someone else will pay the price. That someone will > have to invent a time machine to track back your orbit versions. > > > >> >>> >>> We have put the graduated >>> bundles under released version. that way we can track which version of >>> orbit bundle shipped with which release. otherwise, you cant track >>> something like that and only way to do such thing is to go back in >>> time and check carbon distributions. >>> >>> >>> >>> > It seems currently we don't have any sort of process for graduating >>> > components/bundles. >>> agreed, we havent documented it. >>> >>> Already graduated Orbit bundles have been selected based >>> > on the lack of activity in the recent times which IMO is too ad hoc. I >>> > think >>> > it's time to formalize the graduation process and document it somewhere. >>> > Also the corresponding developers/teams should be in the loop when >>> > graduating a particular module to avoid any future inconveniences. >>> >>> notifying developers is not going to be easy as there are 120+ orbit >>> bundles. I have gradauted ~70 bundles. which is time consuming. >> >> Well we could have at least formed a list of graduation candidates and send >> it to the list for developer review. Or better yet we could have created a >> document and ask the developers to comment on that before moving a bunch of >> stuff out of the trunk. >> >>> >>> Discussing about a bundle in the mailing list is not feasible. The >>> other thing we can do ask developer themselves to do this task after >>> an evaluation of the bundle state. >> >> Well we need to get the developers in the loop somehow. As you have >> mentioned, getting the developers to do it themselves might be the right >> approach. Otherwise a shared google doc or a wiki page should be used to >> communicate this information to the corresponding teams. > > actually, I prepared a document while i was doing this, and have send > this doc[1] over and over again to carbon-dev. > I'm ok with a better process. But I did above changes after discussing > in this very mailing list. > > [1] > https://spreadsheets.google.com/pub?hl=en&hl=en&key=0Aj93FnJ8mzOrdDZ4MGdaODVwQnNjOHl1LTFWWmhmU0E&single=true&gid=0&output=html
the cells coloured as green : graduated bundles. > > --Pradeep. _______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
