What to do with the gobjectification branch
nwalp at pidgin.im
Sat Jan 19 09:27:58 EST 2013
On 01/19/2013 02:11 AM, Mark Doliner wrote:
> My preference:
> - We should not try merging into or out of the current gobjectification branch
> - We shouldn't worry about gobjectification for 3.0.0
> - If there is still interest in gobjectification after 3.0.0 is
> released, then we should:
> - Change one struct at a time (preferably directly in main. Or, if
> it's done in a separate branch, it should be done in a short amount of
> time (a few days) and merged into main as soon as possible.)
> - Get things working and merged and happy. Make sure people like
> the way its done. Make sure everyone is on board with the switch.
> - Then move onto the next struct, and continue doing them one at a time.
> My reasoning:
> I think using GObjects makes sense for a lot of our structs. I think
> it's a good idea. I think our code would probably benefit from using
> these conventions. And I would definitely like to get rid of the
> signals system we built and use glib signals. But I feel like the
> change will take a lot of developer hours, and we don't seem to have a
> lot of developer hours.
> I'd rather we focus on finishing 3.0.0 and get that out the door, wait
> at least a few months, THEN maybe start working on the next.major
> I worry that having this hanging over our heads causes us to hesitate.
> "Should I avoid making large changes because it's going to be hard to
> merge into the gobjectification branch?" Etc. And that's why I think
> we should not try merging into or out of the current gobjectification
> branch. And when the time comes to switch to GObjects I think it
> definitely makes sense to use the code in that branch as a starting
I agree wholeheartedly.
> On Thu, Jan 17, 2013 at 3:29 PM, Jorge Villaseñor <salinasv at gmail.com> wrote:
>> What do you think we should do about the issue with glib-mkenums?
>> a) ship our own patched version of glib-mkenums and compile using it until
>> glib fixes the issue?
>> b) add a hardcoded enums.h and enums.c?
> I'm not familiar with this problem. If everyone decides to postpone
> gobjectification for now then we can wait to decide this later.
> Otherwise, I don't know, either option sounds acceptable to me. (b)
> seems maybe a little better.
> Devel mailing list
> Devel at pidgin.im
More information about the Devel