What to do with the gobjectification branch

[Mark Doliner]

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.

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.