What to do with the gobjectification branch

[Nathan Walp]

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
> branch.
>
> 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
> point.

+1

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
> http://pidgin.im/cgi-bin/mailman/listinfo/devel