Hi Prabath,

On Mon, Aug 10, 2015 at 3:22 PM, Prabath Abeysekera <[email protected]>
wrote:

> Hi Dinusha,
>
> On Mon, Aug 10, 2015 at 3:05 PM, Dinusha Senanayaka <[email protected]>
> wrote:
>
>> 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.
>>
>
> Let me rephrase what I said earlier. MDM team doesn't have any objection
> against "next AppManager version" being shipped on top of Carbon 4.4.1,
> which is orthogonal to what was discussed. All we asked for previously is a
> "app-mgt component" release, which is depending on Carbon 4.4.0, to be
> shipped with EMM 2.0.0.
>
> Anyway, please consider that this is all sorted. Now that both parties
> agree that we can go ahead with 4.4.1, let's please stick to that plan. Can
> you guys also please give us an ETA as to when the next app-mgt component
> release will be out? That'd be helpful to us in terms of planning AppM
> integration bits well in advance.
>

We can do a component release within this week using the appm current
master. But we have few concerns, please check whether it's OK to proceed
with them.
- We are working on some web app new features and those are available in
the current master, but we haven't done proper QA for these yet. I think
this should be OK with you guys since, you don't touch web-app functionality
- We have added some new feature/improvements to mobile apps as well. But
those are properly dev tested.
- We don't have done full QA testing after 4.4.1 migration, only basic
functional testing has done. You might have to test with MDM.

Regards,
Dinusha.


>
> Cheers,
> Prabath
>
>
>>
>> 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/
>>
>
>
>
> --
> 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

Reply via email to