Prabath, we don't have any ball pass here. AppM next release is based on kernel-4.4.1 that's our road map decision and we don't see any reason to go with 4.4.0 while 4.4.1 available and I pointed set of issues/reasons in previous mail as well.
Anyway, I thought problem is already sorted since you said, 4.4.1 upgrade didn't give you any issues and gonna proceed with it ? On Mon, Aug 10, 2015 at 2:33 PM, Prabath Abeysekera <[email protected]> wrote: > > On Mon, Aug 10, 2015 at 12:09 PM, Dinusha Senanayaka <[email protected]> > wrote: > >> Hi Prabath, >> >> Regarding the option 2 given and your feedback on it, >> >> IMO, the solution given by you doesn't fit us because of following >> reasons, >> - We got to know that there are lot of fixes included in kernel-4.4.1 >> over 4.4.0. Hazelcast upgrade, Registry life cycles are not working on >> mounted environment and the list of L1 fixes done [1] are the best >> examples. So knowingly kernel-4.4.0 is buggy with these issues and fixes >> are already available with kernel-4.4.1, we do not want to do AppM new >> release with kernel-4.4.0. >> > > AFAIK, quite a few teams have already started developing on top of 4.4.0. > The model put forward after discussing with all is that, you depend on a > specific kernel version and if there's going to be any issue, the > underlying kernel functionalities have to be patched. If we're not > following this practice, I don't really see why the aforementioned practice > was recommended, in the first place. Further, as I've already pointed out, > if we are forced to update the kernel version we're currently depending on > just because of some bug in a one component, that's pretty unfortunate and > has to be fixed in an appropriate manner. > > Not only that, if 4.4.0 is considered to be buggy, we would expect an > official notification from people who are maintaining the same to update > all on going developments with Carbon Kernel 4.4.1 related dependencies. > However, couldn't find anything of that sort, and also, didn't come across > any blocking issues so far upon any of the MDM related functionalities, so > why do you think we need to go out of the recommended practice? > I'm not sure whether issues given in here [1] should consider for MDM and whether patches are available for kernel-4.4.0. [1] https://wso2.org/jira/browse/CARBON-15146?filter=12323 > > >> >> [1] https://wso2.org/jira/browse/CARBON-15146?filter=12323 >> >> - And we suggest to create a new branch and maintain by your team because >> AppM product doesn't have a requirement of releasing 4.4.0 based repo for >> AppM product release. MDM having the requirement. Several teams have done >> this as their requirements even though it's not the best option and cause >> trouble for product team (here AppM) in support etc. >> eg : 1. ES team had created separate branch for AppM 1.0.0 release and >> we send pull requests for ES team. >> https://github.com/wso2/product-es/tree/app-manager >> >> > No, we don't intend to maintain any source branch owned by the AppM team, > which doesn't scale as I'd pointed out already. > > >> 2. IS team had created a separate branch for APIM/ AppM releases based on >> kernel-4.2.0 since their release is based on kernel 4.4.x. >> https://github.com/wso2/carbon-identity/tree/release-4.2.5 >> >> 3. APIM team had created new synapse version for their release and took >> the responsibility of it. >> >> There should be many other scenarios like this as per the situation. >> > > What we expect is not to "ball-pass" but to get the appropriate components > released by the teams who are owning them. So, I'd be glad if we could > urgently have some help from your team to get this sorted out. > > Cheers, > Prabath > > >> >> Anyway, I think the problem is sorted now, since kernel-4.4.1 upgrade >> works for you. >> >> Regards, >> Dinusha. >> >> >> >> >> >> On Mon, Aug 10, 2015 at 10:27 AM, Prabath Abeysekera <[email protected]> >> wrote: >> >>> Hi Chanaka, >>> >>> On Monday, August 10, 2015, Chanaka Fernando <[email protected]> wrote: >>> >>>> Hi Prabath, >>>> >>>> We have upgraded from kernel 4.4.0 to 4.4.1 with the ESB 4.9.0 Beta >>>> release. We were using 4.4.0 up until Alpha release and we have upgraded >>>> carbon-mediation, wso2-axis2-transports and product-esb to use kernel 4.4.1 >>>> with Beta release. We haven't encountered any issue after upgrading into >>>> 4.4.1. Your arguments might be correct. But I think you can give it a try >>>> to upgrade your components to kernel 4.4.1. I am suggesting this to you >>>> from the experience we gained from ESB beta release. >>>> >>> >>> Thanks for the feedback. Sure, let me give it a try and see. >>> >>> Cheers, >>> Prabath >>> >>> >>>> >>>> >>>> Thanks, >>>> Chanaka >>>> >>>> >>>> >>>> On Mon, Aug 10, 2015 at 8:50 AM, Prabath Abeysekera <[email protected]> >>>> wrote: >>>> >>>>> Hi Dinusha, >>>>> >>>>> Thanks for taking time to help us with this. Please find my comments >>>>> inline. >>>>> >>>>> On Sun, Aug 9, 2015 at 11:38 PM, Dinusha Senanayaka <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi MDM Team, >>>>>> >>>>>> Initial plan was to release AppM-1.1.0 release based on carbon-4.4.0. >>>>>> But due to some issues in the synapse version released with carbon-4.4.0, >>>>>> we need to move to Synapse 2.1.3.wso2v6 which will be released with >>>>>> ESB 4.9.0. For that the the carbon.meadiation.feature should >>>>>> be 4.4.3 which eventually depends on carbon 4.4.1. And there are some >>>>>> registry related issues that fixed in carbon-4.4.1. Because of these >>>>>> reasons we have to move AppM release to carbon-4.4.1. >>>>>> >>>>>> Since you guys need AppM mobile features to be included into MDM, you >>>>>> have two options here, >>>>>> 1. Move MDM release also into carbon-4.4.1 >>>>>> >>>>> >>>>> The team can surely consider going for this option, but, only as the >>>>> last resort. We'd already released a number of milestones upon Carbon >>>>> 4.4.0, so if we're forced to upgrade everything to use Carbon 4.4.1 (In >>>>> other words, adapting a "new" kernel release) just to fix a bug in one of >>>>> the dependent components, approaching EMM 2.0.0 Alpha in less than a >>>>> month, >>>>> then there's a problem in the system that needs to be fixed. I do >>>>> understand the fact that the release number (i.e. 4.4.1) suggests that it >>>>> is a patch release, so, unlikely that there'd by any API changes, etc >>>>> around. Therefore, one might think it is a straight forward task to >>>>> upgrade >>>>> all "device-mgt" components to use the latest version of Carbon kernel. >>>>> However, unfortunately, it's not only about device-mgt related components, >>>>> but quite a few other stuff as well. In other words, there should be quite >>>>> a few other components that depend on 4.4.0, which would need to be >>>>> upgraded as well. I wouldn't take that risk to upgrade them all at this >>>>> stage of the release, just to get an issue fixed in one of the components. >>>>> >>>>> >>>>>> 2. Since MDM doesn't require AppM gateway features, we could create a >>>>>> separate branch for you only with store/publisher/mobile features based >>>>>> on >>>>>> carbon-4.4.0 and you have to maintain the branch. (AppM master is still >>>>>> based on carbon-4.4.0, we could create this branch before we upgrade it >>>>>> to >>>>>> carbon-4.4.1) >>>>>> >>>>> >>>>> AFAIK, the process demands us to release all components maintained in >>>>> a particular repository at once. So, I don't quite think releasing >>>>> individual components is possible. On the other hand, this just appears to >>>>> be a "patch solution", which doesn't seem scale well going forward. >>>>> >>>>> Also, I'm a little concerned by the statement, "*based on >>>>> carbon-4.4.0 and you have to maintain the branch*". Why would some >>>>> other team "maintain" app-mgt source branches? If this is about fixing >>>>> bugs, etc that the EMM team comes across while adapting app-mgt related >>>>> components, we ourselves would anyway go for it as time permits. However, >>>>> creating some branch and asking other teams to "maintain" the same is >>>>> against collaborate development, IMO. If you create a new version of the >>>>> components, that will at some point be used by the "whole platform". So, >>>>> asking some other team to "maintain" the components owned by your team, as >>>>> you can obviously see, does not seem to scale. >>>>> >>>>> With all the above considered, I'm suggesting the following, which I >>>>> think is the best option. >>>>> >>>>> * Update "carbon.mediation.feature" to use "2.1.3.wso2v6" and make >>>>> its version something like "4.5.*" (ESB team can probably decide on a >>>>> proper version number if what's suggested doesn't appear to be good). The >>>>> idea is, even though 4.4.1 appears to be a patch release of Carbon 4.4.0, >>>>> it has to be a big deal for a component to adapt to a new kernel version. >>>>> Also, IMO, each and every component should let us have enough room to fix >>>>> bugs of an already released version that depends on the Kernel version it >>>>> was originally released upon. >>>>> >>>>> * Next, create a new version of "carbon.mediation.feature", which >>>>> depends on Carbon 4.4.0 and upgrade its synapse version to be " >>>>> 2.1.3.wso2v6". This is what needs to be used by the app-mgt >>>>> components. >>>>> >>>>> * Get the app-mgt repo released so that the EMM can then adapt all >>>>> required components on top of Carbon Kernel 4.4.0. >>>>> >>>>> >>>>> Please do let me know if you think it's going to be challenging to get >>>>> the above to work, or if you need further clarifications. >>>>> >>>>> Cheers, >>>>> Prabath >>>>> >>>>> >>>>>> >>>>>> Let us know the preferred option for MDM release. >>>>>> >>>>>> Regards, >>>>>> Dinusha. >>>>>> >>>>>> -- >>>>>> Dinusha Dilrukshi >>>>>> Associate Technical Lead >>>>>> WSO2 Inc.: http://wso2.com/ >>>>>> Mobile: +94725255071 >>>>>> Blog: http://dinushasblog.blogspot.com/ >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Prabath Abeysekara >>>>> Technical Lead >>>>> WSO2 Inc. >>>>> Email: [email protected] >>>>> Mobile: +94774171471 >>>>> >>>>> _______________________________________________ >>>>> Dev mailing list >>>>> [email protected] >>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev >>>>> >>>>> >>>> >>>> >>>> -- >>>> -- >>>> Chanaka Fernando >>>> Senior Technical Lead >>>> WSO2, Inc.; http://wso2.com >>>> lean.enterprise.middleware >>>> >>>> mobile: +94 773337238 >>>> Blog : http://soatutorials.blogspot.com >>>> LinkedIn:http://www.linkedin.com/pub/chanaka-fernando/19/a20/5b0 >>>> Twitter:https://twitter.com/chanakaudaya >>>> Wordpress:http://chanakaudaya.wordpress.com >>>> >>>> >>>> >>>> >> >> >> -- >> Dinusha Dilrukshi >> Associate Technical Lead >> WSO2 Inc.: http://wso2.com/ >> Mobile: +94725255071 >> Blog: http://dinushasblog.blogspot.com/ >> > > > > -- > Prabath Abeysekara > Technical Lead > WSO2 Inc. > Email: [email protected] > Mobile: +94774171471 > -- Dinusha Dilrukshi Associate Technical Lead WSO2 Inc.: http://wso2.com/ Mobile: +94725255071 Blog: http://dinushasblog.blogspot.com/
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
