On Fri, Oct 18, 2013 at 11:16 AM, Stéphane Desneux <
stephane.desn...@eurogiciel.fr> wrote:
> Hello,
>
> I'm currently investigating with Dominique Le Foll on some ways to improve
> the application launch time (WRT, OSP or core apps).
>
> Before thinking of checking preloaders and other mechanisms
On Thu, Oct 17, 2013 at 8:54 AM, Gerken, Stephen
wrote:
> I wrote an earlier reply which did not go to the mailing list, which reply I
> repeat here. Sorry for any confusion induced by my error.
>
> Hello Mikko,
>
>
>> I am initially interested in understanding what the external interfaces
>> are
I'm fine with that definition. Only one additional suggestion: let's define max
time for that package to be in pending state. :build project is affecting other
new submissions, so even there keeping something not so good for more than day
or two would be counterproductive IMHO.
br, Alexander (m
Hello,
I'm currently investigating with Dominique Le Foll on some ways to
improve the application launch time (WRT, OSP or core apps).
Before thinking of checking preloaders and other mechanisms, I just sat
down and looked at the actual shared libs we can find in tizen/common
(x86_64) and IV
Let me clarify... I am requesting RE to allow a SR to just sit in a
pending state if the package does not build. I am not asking that we
accept the broken package, but to just let it spend some time in the
build project waiting on another package's SR to come in and fix
building of both packages i
It was <2013-10-18 pią 14:17>, when Jussi Laako wrote:
> On 17.10.2013 11:44, Łukasz Stelmach wrote:
>> And is packaged by the organisation that builds the distro. That is what
>> makes it all work together. Tell me how many packages on your computer
>> come packaged for your distribution from a ve
On 10/18/13 18:12 , "Łukasz Stelmach" wrote:
Łukasz, can you provide some example where in such cases package A, B, C
would be needed to submitted together and that would be not an API/ABI
change ?
As for combined submit requests - the code works that people can "join" to
the group request.
Me
It was <2013-10-18 pią 14:07>, when Kanevskiy, Alexander wrote:
> On 10/18/13 14:57 , "Łukasz Stelmach" wrote:
>>
>>I saw this problem few times before and now a teammate of mine told me
>>he's got it too. The problem I'd like to discuss is inter-package patch
>>dependencies.
>>
>>Sometimes we int
Hi, Hyungu,
The following request was reviewed and merged. Mr.Cho also requested the SR for
this commit.
https://review.tizen.org/gerrit/10943
These should be checked from Mr.Won (ky99@samsung.com) and Mr Lim
(byounghui@samsung.com).
They are maintainers for these gits.
https://review
On 10/18/13 16:32 , "Krzysztof Opasiak" wrote:
"Depends On"/"Needed By" in Gerrit and between patches are dependencies
within one component describing internal interfaces and dependencies of
that component.
We are talking here about breaking external dependencies between
components.
Those in Tiz
On Fri, Oct 18, 2013 at 07:06:53AM +, Dong, Junfeng wrote:
> Here is the mobile problem summary on Oct. 18, 2013 :
>
> 1. the image is created today. Could someone have M0 device to flash it and
> report the problems?
>
> 2. the build status:
> Arm: failed: 12 unresolvable: 9
> IA: failed: 7
Hi,
Yes, that is obviously caused by a "broken" pristine-tar branch, generated by a
buggy version of pristine-tar.
There must be dozens (or even hundreds) of packages with broken pristine-tar
branches, because of this. We should go through all the packages and repair the
broken branches in co-
One note about: "Release engineers should not simply decline SRs because of
building issues. Sometimes several SRs should be accepted together to function".
It is true that some components must be accepted together to get it build able.
However, it's not reasonable to accept something that _right
Dear app framework reviewers,
Please see below pending review packages and give +2 point to merge it, if they
have no problems.
osp-app-controlsfailed can't verify it but accoding to mailing list,
it is pending on review.
[1] https://review.tizen.org/ge
> -Original Message-
> From: dev-boun...@lists.tizen.org [mailto:dev-boun...@lists.tizen.org] On
> Behalf Of Rusty Lynch
> Sent: Thursday, October 17, 2013 4:58 PM
> To: Liu, Bing Wei; Karur Mohan, Prajwal; Saxena, Sunil; Michael Kim;
> jinkun.j...@samsung.com; ANUJ MISHRA; 주현구; Dong, Junfe
> -Original Message-
> From: Kanevskiy, Alexander [mailto:alexander.kanevs...@intel.com]
> Sent: Friday, October 18, 2013 3:14 PM
> To: Krzysztof Opasiak; Lukasz Stelmach; dev@lists.tizen.org
> Subject: Re: [Dev] [SCM] inter-package patch dependencies
>
> On 10/18/13 15:21 , "Krzysztof Opa
On 10/18/13 15:21 , "Krzysztof Opasiak" wrote:
The scenario you're describing where package A will be not buildable until
package B and C not submitted means that packages B and C are directly or
indirectly used as build dependencies for package A.
So, scenario 1, as I wrote earlier, with specif
> -Original Message-
> From: dev-boun...@lists.tizen.org [mailto:dev-
> boun...@lists.tizen.org] On Behalf Of Kanevskiy, Alexander
> Sent: Friday, October 18, 2013 2:07 PM
> To: Lukasz Stelmach; dev@lists.tizen.org
> Subject: Re: [Dev] [SCM] inter-package patch dependencies
>
> On 10/18/13
On 17.10.2013 11:44, Łukasz Stelmach wrote:
And is packaged by the organisation that builds the distro. That is what
makes it all work together. Tell me how many packages on your computer
come packaged for your distribution from a vendor other that the creator
of the distribution?
At least I ha
On 10/18/13 14:57 , "Łukasz Stelmach" wrote:
There are few things here:
1. API changes that are not explicitly declared.
Normally it's handled that e.g. Library XYZ starts to provide new API that
supposed to be used by application.
API is provided in version V1. Then, best practice is, if applic
Hi.
I saw this problem few times before and now a teammate of mine told me
he's got it too. The problem I'd like to discuss is inter-package patch
dependencies.
Sometimes we introduce some changes that need other packages to be
changed too. So we change those too. Then, after the changes pass rev
Hi,
Yes, that is obviously caused by a "broken" pristine-tar branch, generated
by a buggy version of pristine-tar.
There must be dozens (or even hundreds) of packages with broken pristine-tar
branches, because of this. We should go through all the packages and repair
the broken branches in co-ope
Here is the mobile problem summary on Oct. 18, 2013 :
1. the image is created today. Could someone have M0 device to flash it and
report the problems?
2. the build status:
Arm: failed: 12 unresolvable: 9
IA: failed: 7 unresolvable: 7
Three main issues: one is compiler doesn't work for "gdb" "get
23 matches
Mail list logo
