gtg-gsoc team mailing list archive

[Lionel Dricot <ploum@xxxxxxxxx>]

Hi Paul,

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.

I will have a look today. Could you point out precisely branch you want
to merge currently ?

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 !


Thanks a lot for your patience,

Lionel


Le samedi 31 juillet 2010 à 23:30 -0400, Paul Natsuo Kishimoto a écrit :
> Hi all,
> 
>   I just tried the following:
> 
> $ bzr branch lp:~gtg-user/gtg/liblarch_migration
> Branched 870 revision(s).
> $ cd liblarch_migration/
> $ bzr merge lp:~khaeru/gtg/liblarch_migration
> +N  GTG/tests/test_tree.py.OTHER
>  M  GTG/gtk/browser/tagtree.py
>  M  GTG/tests/test_liblarch.py
>  M  GTG/tools/liblarch/__init__.py
>  M  GTG/tools/liblarch/filteredtree.py
>  M  GTG/tools/liblarch/filters_bank.py
>  M  GTG/tools/liblarch/tree.py
> Text conflict in GTG/tests/test_liblarch.py
> Contents conflict in GTG/tests/test_tree.py
> Text conflict in GTG/tools/liblarch/__init__.py
> Text conflict in GTG/tools/liblarch/filteredtree.py
> 4 conflicts encountered.
> 
> ...basically it seems that the branch Lionel and Luca worked on during
> GUADEC, and the branch I'm working on, have been diverging.
> 
>   I've sent some longer e-mails as well as an ODF spreadsheet trying to
> explain the changes I was making in my branch, but haven't got any
> responses. Lionel and I had a discussion on Thursday about conventions
> for object attribute access, but I didn't get a sense of whether my
> edits, as a whole, were welcome or not. No one else has said anything.
> Combined with the fact that the ~gtg-user branch sidesteps my own, this
> makes me a bit worried.
> 
>   Normally I wouldn't mention this at all, but it's the THIRD such
> situation. The first two were the new date class
> (https://code.launchpad.net/~gtg-contributors/gtg/new-date-class/+merge/28009) and the second set of code-layout changes (https://code.launchpad.net/~gtg-contributors/gtg/code-layout-2/+merge/30136).
> 
>   In one of those cases, I've got an "approve" from Bryce (2 weeks ago)
> but no one has committed the code; in the other one we are in
> disagreement and someone is needed to broker a compromise.
> 
>   But in both cases my code is "in limbo". I am left not knowing whether
> I can use it as a basis for future work. In the code-layout situation,
> other changes were made to trunk that partially duplicate what I did;
> this represents wasted effort.
> 
>   I'm worried the same thing will happen to my liblarch improvements. I
> was hoping to use those changes as a basis for replicating the
> server-side trees on the client-side; but if they will be "in limbo" as
> well, there's no basis to start that replication, and I am back to
> square one.
> 
>   So, two requests: first, could the three branches above please get
> some input? Can they be merged (for liblarch, I mean merged with
> gtg-user)? Do I give up on them, rewrite them, ask for more reviews?
> Will it help if I explain again why they are necessary?
> 
>   Second, how to avoid these situations in the future? Should I join
> gtg-developers, like Luca, so I can merge my own changes? (Lionel
> earlier said the GTG GSoC policy should be to have students propose
> merges for mentors to approve, so I haven't tried to do this.) Should I
> bug people even more persistently to review code? Something else? Your
> guidance on this point would be very much appreciated.
> 
> Cheers,
> _______________________________________________
> Mailing list: https://launchpad.net/~gtg-gsoc
> Post to     : gtg-gsoc@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~gtg-gsoc
> More help   : https://help.launchpad.net/ListHelp