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. > > > > 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. > 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. Thanks, Hiranya > > --Pradeep > -- Hiranya Jayathilaka Senior Software Engineer; WSO2 Inc.; http://wso2.org E-mail: [email protected]; Mobile: +94 77 633 3491 Blog: http://techfeast-hiranya.blogspot.com
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
