← Back to team overview

gtg-gsoc team mailing list archive

Re: Liblarch — what's going on?

 

Paul,

I don't know if it's a misunderstanding but I've seen that you have
commited to liblarch_migration without being reviewed. That's a problem
because some part of your commits are not acceptable (the now infamous
len(children) ;-) ).

I'm sorry if I was not clear about that but I want to review everything
before any commit. I was reviewing Luca's code directly at GUADEC, that's
why he commited.

Well, the good point is that, besides the len(children), everything looks
good. I appreciate some refactoring you did with the filters_bank and the
tree. It looks a really good idea.

Also, as long as the tests are OK, this should be fine (else, it means
that we need more test.). So, I propose to keep your commits but just clean
all the len() and use the proper get.

Oh, btw, please do not care too much about liblarch-gtk : it's currently a
huge mess of work in progress !


Thanks for your work :-)

Lionel


On Sun, 01 Aug 2010 21:30:04 -0400, Paul Natsuo Kishimoto
<mail@xxxxxxxxxxxxxxxxxxx> wrote:
> On Sun, 2010-08-01 at 11:53 +0200, Lionel Dricot wrote:
>> I haven't merged your branch at GUADEC because of the little point we
>> were discussing. 
>> 
>> I'm deeply sorry about not being responsive but it has been a crazy
>> week. At some point, also, we decided to write code before anything
>> because we had to do it. But indeed, we missed a lot of your stuffs.
> 
>   That was my first guess — it's easier to work from familiar code,
> instead of my unfamiliar code. That's 100% understandable, I would
> probably do the same. It was only the lack of comment that bothered me.
> 
>> I will have a look today. Could you point out precisely branch you want
>> to merge currently ?
> 
>   For liblarch, I would like to roll ~khaeru/gtg/liblarch_migration into
> ~gtg-user/gtg/liblarch_migration. If you don't mind, I will merge them
> manually, myself (preserving all the GUADEC additions) and push the
> results into ~gtg-user. Please have a look at the resulting API (my
> spreadsheet, attached again) and let's talk about if it needs more
> public methods.
> 
>   For the new-date-class merge, if it's OK, please commit.
> 
>   For the code-layout-2 merge, people will have to look at my comments
> vs. Bryce's on the merge, and see who is more convincing.
> 
>> I agree that diverging sucks but, so far, this is the price we have to
>> pay for having to many brights coders on the same stuff. That liblarch
>> development is a bit chaotic right now but we are seeing the light !
> 
>   Yup, I agree we are making good progress — with a little more
> coordination, we can be more than the sum of our individual efforts.
> That's all I hope for :)



References