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. Same applies for Orbit too. Every now and then we realize that certain bugs are actually caused by 3rd party libraries and we need to fix/upgrade them. > 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. Ok let me rephrase my question. What do you intend to achieve by graduating the Orbit bundles? If it's simply saving some build time then the right thing to do is temporarily removing them from the Orbit POM. Removing it altogether from the trunk makes the life lot difficult, because sooner or later we have to upgrade them and move on when the 3rd party projects do releases. > (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. > Can you please explain how this works? I'm sorry I'm not getting it clearly. As far as I can see, there's a bunch of Orbit bundles at https://svn.wso2.org/repos/wso2/graduated/carbon/orbit which used to be in trunk. How do you trace them back to Carbon versions. > > > > > > >> > >> > 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. > Well we have been living with this model for past 2-3 years and I'm still not aware of anybody having to invent a time machine to deal with it :) At worst case one can extract and old distro to find out the exact versions of the dependencies shipped with it. In general product builds were setup to pick up the latest Orbit bundle version in the trunk. If there hasn't been any changes in the Orbit bundle we simply pick the last released version from the M2 repo. > > > > > > >> > >> 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 Ok thanks for pointing this out and sorry for my ignorance. The document does not list why these bundles were selected for graduation and other necessary whereabouts, so you might want to add them. However please note that having a discussion and requesting mandatory feedback are two different things. You cannot do latter properly on a mailing list with ~100 developers involved. I don't even have edit permissions on the doc which leads me to think that development teams haven't thoroughly reviewed and commented on this. However going through the list I can also see quite a number of stuff that we should have actually graduated. So good job on that. But there are several things we might have to un-graduate (unless there is a better way to handle them). The very fact that we have to upgrade a particular library is an indication that it shouldn't have been graduated. 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
