What to do with the gobjectification branch
salinasv at gmail.com
Thu Jan 17 18:29:48 EST 2013
On Sun, Mar 20, 2011 at 7:05 PM, Mark Doliner <mark at kingant.net> wrote:
> Some facts:
> * We have a branch called im.pidgin.gobjectification
> * It contains lots of changes to make some of our internal data
> structures gobjects
> * Propagating changes from im.pidgin.pidgin and
> im.pidgin.pidgin.next.major to im.pidgin.gobjectification frequently
> causes merge conflicts that require manual intervention
> * Manual intervention while merging isn't a serve problem, but it IS
* It does not compile right now because of a bug in glib-mkenums in (at
least) glib 2.34.3. ( https://bugzilla.gnome.org/show_bug.cgi?id=674119 )
* Last propagate from main was done by Elliot in 2011-09-01. After that
there were few changes but no merges.
I have tried to merge from default to gobjectification few times but it is
Now I have been thinking in doing gradual merges from that last merge to
today but will be painful and I worry I can mess a lot of stuff. AND, it
does not compile because of this glib-mkenums bug.
> Does everyone agree on the above points?
> The problem I have is that:
> 1. I want to start making large changes to im.pidgin.pidgin.next.major
> because I like forward progress
> 2. I want to avoid making large changes to im.pidgin.pidgin.next.major
> because it will cause merge conflicts with the gobjectification branch
> How do we resolve this problem? It seems like we should either merge
> the gobjectification branch into next.major now, or we should go ahead
> with making large changes to next.major and disregard any merge
> problems that might arise propagating to the gobjectification branch.
I would like to add some options here since we have bumped 3.0.0
3. Drop gobjectifications work (I would not like this but have heard the
4. Merge gobjectifications with main directly and fix what is broken in
5. Try to propagate main to gobjectifications and try to improve it (I
think it is unlikely to happen)
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 think we should decide some of this issues ASAP since it makes our
efforts to get 3.0.0 out to diverge.
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?
Q: What is the most annoying thing on usenet and in e-mail?
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Devel