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 --Pradeep. _______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
