On 23/09/12 00:13, Gustavo Sverzut Barbieri wrote:
> it shouldn't, but it always do :-(
>
> we don't need major releases, but at least minor we should
>
>
It's not the wait I care about (well, not entirely). The main problem,
as I said, is the annoying merge process because of the relayouting of
On Sat, Sep 22, 2012 at 5:46 PM, Tom Hacohen wrote:
>
> On 22/09/12 17:05, Gustavo Sverzut Barbieri wrote:
> > Isn't better to wait merge, release, then add eo?
>
> Hm... what? I don't quite get it. We just released, we waited until
> after the release just for that, why not upstream our changes t
On Sat, Sep 22, 2012 at 6:11 PM, Tom Hacohen wrote:
> On 23/09/12 00:10, Gustavo Sverzut Barbieri wrote:
>> On Sat, Sep 22, 2012 at 5:46 PM, Tom Hacohen wrote:
>>> On 22/09/12 17:05, Gustavo Sverzut Barbieri wrote:
Isn't better to wait merge, release, then add eo?
>>>
>>> Hm... what? I don't
On 23/09/12 00:10, Gustavo Sverzut Barbieri wrote:
> On Sat, Sep 22, 2012 at 5:46 PM, Tom Hacohen wrote:
>> On 22/09/12 17:05, Gustavo Sverzut Barbieri wrote:
>>> Isn't better to wait merge, release, then add eo?
>>
>> Hm... what? I don't quite get it. We just released, we waited until
>> after th
On Sat, Sep 22, 2012 at 5:46 PM, Tom Hacohen wrote:
> On 22/09/12 17:05, Gustavo Sverzut Barbieri wrote:
>> Isn't better to wait merge, release, then add eo?
>
> Hm... what? I don't quite get it. We just released, we waited until
> after the release just for that, why not upstream our changes that
On 22/09/12 17:05, Gustavo Sverzut Barbieri wrote:
> Isn't better to wait merge, release, then add eo?
Hm... what? I don't quite get it. We just released, we waited until
after the release just for that, why not upstream our changes that add Eo?
--
Tom.
-
I think you should... I'll respond to gustavo in a sec.
On 22/09/12 20:18, Vincent Torri wrote:
> just tell me what you agree on. For now, i don't merge eo.
>
> Vincent
>
> On Sat, Sep 22, 2012 at 4:05 PM, Gustavo Sverzut Barbieri
> wrote:
>> Isn't better to wait merge, release, then add eo?
>
Massimo Maiurana, il 21/09/2012 13:03, ha scritto:
> while we are at it, here's another: what actually does the option "really
> move" in the behaviour tab? I have it unchecked but looks to me that every
> move is really done anyway.
another question from e-intl: what "track launch" for ibar does
just tell me what you agree on. For now, i don't merge eo.
Vincent
On Sat, Sep 22, 2012 at 4:05 PM, Gustavo Sverzut Barbieri
wrote:
> Isn't better to wait merge, release, then add eo?
>
> On Saturday, September 22, 2012, Tom Hacohen wrote:
>
>> To whom it may concern,
>>
>> We plan on merging o
Isn't better to wait merge, release, then add eo?
On Saturday, September 22, 2012, Tom Hacohen wrote:
> To whom it may concern,
>
> We plan on merging our changes to Evas that make it Eo based tomorrow.
> Everything should work the same, except for the new Eo dep. This will be
> easy to handle on
dans le svn
merci :)
Vincent
On Sat, Sep 22, 2012 at 1:39 PM, rustyBSD wrote:
> Hi,
> == e_fm_op.c l.984 ==
> if dst = NULL, strlen() sefaults.
>
> Here is a patch.
>
> --
> How fast is your code?
> 3 out of 4 devs don\
Hi,
== e_fm_op.c l.984 ==
if dst = NULL, strlen() sefaults.
Here is a patch.
--- e_fm_op.c Sat Sep 22 13:31:24 2012
+++ e_fm_op.c Sat Sep 22 13:31:19 2012
@@ -980,6 +980,8 @@
int size, src_len, dst_len;
int ret = 0;
+ if (!dst) return;
+
src_len = strlen(src);
dst_len = st
To whom it may concern,
We plan on merging our changes to Evas that make it Eo based tomorrow.
Everything should work the same, except for the new Eo dep. This will be
easy to handle once we merge Eo into the merged EFL tree.
Please let me know if you have any questions or concerns.
--
Tom.
---
13 matches
Mail list logo
