On Thu, 27 Sep 2012 13:15:24 +0200 Tom Hacohen said:
> On 27/09/12 13:13, Carsten Haitzler (The Rasterman) wrote:
> > yes - but ... be prepared to have to yank it out. if it breaks something...
> > or fix asap.
> >
>
> Sure. Ok, I think I'll do it next week then.
luckily i'm on holiday so i lik
On 27/09/12 13:13, Carsten Haitzler (The Rasterman) wrote:
> yes - but ... be prepared to have to yank it out. if it breaks something... or
> fix asap.
>
Sure. Ok, I think I'll do it next week then.
--
Tom.
--
Everyone h
On Thu, 27 Sep 2012 13:10:23 +0200 Tom Hacohen said:
> On 27/09/12 04:12, Carsten Haitzler (The Rasterman) wrote:
> > On Mon, 24 Sep 2012 00:05:40 +0200 Tom Hacohen said:
> >
> >> On 23/09/12 23:14, Lucas De Marchi wrote:
> >>> It sounds like an excuse to not do the right thing. The manual
> >>>
On 27/09/12 04:12, Carsten Haitzler (The Rasterman) wrote:
> On Mon, 24 Sep 2012 00:05:40 +0200 Tom Hacohen said:
>
>> On 23/09/12 23:14, Lucas De Marchi wrote:
>>> It sounds like an excuse to not do the right thing. The manual
>>> intervention should be very minimal and it shouldn't be a source o
On Mon, 24 Sep 2012 00:05:40 +0200 Tom Hacohen said:
> On 23/09/12 23:14, Lucas De Marchi wrote:
> > It sounds like an excuse to not do the right thing. The manual
> > intervention should be very minimal and it shouldn't be a source of
> > bugs... once it compiles, it should work as if the paths
On Mon, 24 Sep 2012 10:56:42 +0900 Cedric BAIL said:
> On Sun, Sep 23, 2012 at 6:13 AM, Gustavo Sverzut Barbieri
> wrote:
> > 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 Sun, Sep 23, 2012 at 6:13 AM, Gustavo Sverzut Barbieri
wrote:
> 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
On 23/09/12 23:14, Lucas De Marchi wrote:
> It sounds like an excuse to not do the right thing. The manual
> intervention should be very minimal and it shouldn't be a source of
> bugs... once it compiles, it should work as if the paths haven't
> changed.
It's easier to mis-merge, and that's a sour
On Sun, Sep 23, 2012 at 3:29 AM, Tom Hacohen wrote:
> 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 sa
On Sun, Sep 23, 2012 at 11:10 AM, Tom Hacohen wrote:
> On 23/09/12 16:03, Gustavo Sverzut Barbieri wrote:
>> Do a single diff and a sed to change the path of files. :-)
>
> Yeah, I thought about that, but that's not optimal.
Or use tools that can take prefix and --directory. See svn-git-am
using
On 23/09/12 16:03, Gustavo Sverzut Barbieri wrote:
> Do a single diff and a sed to change the path of files. :-)
Yeah, I thought about that, but that's not optimal.
>
> Another option is to be sure it's stable and just copy files over.
>
... That's what I'm trying to avoid.
--
Tom.
---
On Sunday, September 23, 2012, Tom Hacohen wrote:
> 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 s
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?
>
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
21 matches
Mail list logo
