22:02 < ebassi> everyone's here?
22:02 < jdahlin> now or never
22:02 < kris> I invited mitch
22:02 < kris> I guess he will join at some point
22:03 < rambokid> upfront: i had a dsl outage for 1 week, so i haven't even read emails since last tuesday
22:04 < ebassi> clogged tubes?
22:04 < rambokid> still polling emails from the accounts here...
22:05 < ebassi> okay, I'll paste the agenda points I have gathered
22:05 < ebassi> 1. status of GtkBuilder
22:05 < ebassi> 2. small API additions still pending
22:05 < ebassi> 3. removal of the remaining linux-fb bits
22:05 < ebassi> 4. maemo branch in gtk+ repository
22:06  * mclasen gets coffee
22:07 < mclasen> 5. releases
22:08  * zuh . o O ( maybe there should be some bot (or just someone with a script) that would privmsg the agenda to all who join... )
22:08  * lool summons seb128
22:09 < kris> is it so hard to remember those 5 points? ;)
22:10 < tko_> there were five?
22:10 < jdahlin> shall we move on to the status of GtkBuilder?
22:10 < bratsche> I want to ask about the status of #56070, but I'm not sure if that's appropriate for the meeting.
22:10 < mclasen> hmm, no bugbot
22:10 < bratsche> The status and what I can do to help, because my company is very interested in that one now and I can devote time to it.
22:10 < bratsche> http://bugzilla.gnome.org/show_bug.cgi?id=56070
22:11 < Amaranth> oh, that one
22:11 < ebassi> mclasen: insensitive button bug
22:11 < Amaranth> i ended up just doing the workaround
22:11 < mclasen> I thought so
22:11 < bratsche> I can ask in #gtk+ after the meeting if you want.
22:12 < mclasen> bratsche: I guess I (or somebody else) need to write down some sort of test plan in the bug
22:13 < bratsche> I'd be more than willing to do any kind of testing that's desired for that one in the hopes of getting it closed soon.
22:13 < mclasen> I'll try to find time this week to write something down
22:13 < bratsche> Cool, thanks.
22:14 < xan> great, been hit by that bug lately too :)
22:14 < bratsche> Yeah, it's been bothering us again recently. :)
22:14 < mclasen> ok, should we move to "1. GtkBuilder status" ?
22:15 < jdahlin> sure
22:15 < jdahlin> This is what happened last week wrt gtkbuilder; it went through quite a few revision cycles (thanks mclasen, tristan and zuh)
22:16 < jdahlin> There are still a couple of outstanding issues, reference counting, documentation & pixbuf loading.
22:16 < jdahlin> a little bit of extra API needs to be added for pixbuf loading
22:16 < ebassi> the patch is getting relatively huge to manage; I'm wondering if it could be safer to apply it, close the current bug and open bugs for the remaining stuff
22:17 < mclasen> ebassi: thats what we are about to decide today, no ?
22:17 < ebassi> since it's most api doc and small api additions, now
22:17 < jdahlin> That would make it easier, assuming everyone is happy about the state of it
22:17 < ebassi> mclasen: oh, right :-)
22:17 < rambokid> xan: is the state-propagation-fix patch in svn yet?
22:18 < jdahlin> What are the risks wrt landing of gtkbuilder on trunk?
22:18 < xan> rambokid, in maemo? yes
22:18 < mclasen> as you said, the major outstanding issues are reference handling, documentation, pixbuf loading
22:18 < rambokid> xan: no, in upstream.
22:18 < rambokid> xan: what's the bug # ?
22:18 < xan> rambokid, no
22:18 < tristan> I think builder is in a good state, it might not do everything perfectly, but its a start
22:18 < mclasen> of those, only the reference handling needs to be fixed for a stable release, I think
22:18 < mclasen> the documentation is best effort
22:19 < jdahlin> I am committed to fix this during the next couple of weeks
22:19 < tristan> and I dont see why things cant be improved compatibly in the future also
22:19 < mclasen> and the pixbuf loading could be left out if we have to
22:19 < kris> is the pixbuf loading that much work then?
22:19 < jdahlin> there's nothing preventing users to use gtkbuilder even if it leaks a little bit
22:19 < tristan> mclasen, the pixbuf loading is really trivial though IMHO, and quite usefull
22:19 < jdahlin> kris: no, it's not a lot of work, but it will add API
22:19 < mclasen> my proposal for GtkBuilder is to land it in trunk after this weeks devel release is out
22:19 < tristan> well, I suppose I've seen the code alot and just find it trivial :-S
22:19 < kris> jdahlin: a lot of API? or just two functions?
22:20 < jdahlin> kris: maybe as many as 5
22:20 < kris> ok
22:20 < mclasen> jdahlin: could be done by a single builder property though, I guess, "pixbuf-path" ?
22:20 < tristan> and those APIs might be deprecated if we load GdkPixbufs as proper objects in the future correct ?
22:20 < jdahlin> kris: my idea was to make it similar to the icon theme path handling
22:20 < tristan> or maybe that doenst ever need to happen
22:21 < jdahlin> mclasen: right, but it'd be nice to have a function to append/prepend a directory to the current path
22:21 < jdahlin> mclasen: it'd be nice to support more than one directory
22:21 < mclasen> jdahlin: I guess, yeah. I'm not worried about the pixbuf loading part
22:21 < kris> to me it sounds/feels like this pixbuf stuff can also be nailed in time before the releawe
22:22 < jdahlin> mclasen: would it not be better to get the builder included in the next devel release to get a few more testers?
22:22 < mclasen> I guess the question is if there is general agreement that this is the way to go
22:22 < mclasen> jdahlin: thats a valid point
22:22 < jdahlin> mclasen: it's a developer release after all, people must be prepared for some breakage.
22:23 < jdahlin> Is anyone in here opposed to landing gtkbuilder on trunk?
22:23 < zuh> Was there even much changes to non-gtkbuilder parts?
22:23 < kris> personally I would definitely say, if we are going to include it, the earlier the better
22:23 < ebassi> I agree with kris
22:23 < jdahlin> zuh: no changes, only additions (such as implementing buildable on a gazillion classes)
22:23 < rambokid> jdahlin: i'd like to review its API first
22:24 < jdahlin> rambokid: okay, is it something you could do today or this week?
22:24 < jdahlin> I could send the public headers to gtk-devel and start a discussion there
22:25 < rambokid> it's night here already so not today.
22:25 < mclasen> resending just the api bits would be helpful I guess
22:25 < mclasen> best with some api docs, though
22:25 < rambokid> yeah, like mclasen says
22:25 < zuh> jdahlin: Yeah, so it shouldn't break anything existing and thus should be fairly safe to land in even before it's 100% stable IMO
22:25 < jdahlin> should that be done before or after landing it?
22:26 < jdahlin> I'm afraid that the discussion will drag out and it won't get as much testing as it needs
22:26 < tristan> I think it would be difficult to be perfectly satisfied with the builder, my opinion is we should land it and work from there
22:26 < mclasen> yeah, thats the risk 
22:26 < jdahlin> I'd prefer getting it land before the next development release (and gtk meeting)
22:27 < mclasen> so, realistically that leaves 2 days for rambokid's review
22:27 < jdahlin> rambokid: would it be okay if it got committed to trunk today and I'll commit to sort out any issues raised by the gtk-devel discussion, by you or anyone else ?
22:27 < rambokid> fine, get the discussion started soon then ;)
22:28 < rambokid> jdahlin: i have no idea because i haven't seen the API yet. in general i don't think it's good to commit and release premature APIs, so i'd rather see you present it soon so i can reply in time.
22:29 < tristan> what I've been particularly attentive to, are design decisions that cant be redressed in the future... 
22:29 < tristan> one lingering concern was
22:29 < jdahlin> rambokid: okay, fair enough
22:29 < tristan> packing properties on non-GtkContainer GObjects
22:29 < jdahlin> so this is the suggestion;
22:29 < tristan> but I think they can be done so that satisfies me.
22:29 < jdahlin> I'll send a mail to gtk-devel later today with the public API and documentation and ask for a final API review
22:30 < jdahlin> If nothing serious comes up it'll be committed just before the next development release?
22:30 < rambokid> tristan: isn't that something that can be taken to the API review thread?
22:30 < rambokid> jdahlin: sounds good
22:30 < jdahlin> which is scheduled for thursday or friday, right mclasen?
22:30 < mclasen> ideally, I'd like to do one before the week runs out
22:30 < mclasen> so friday
22:31 < jdahlin> fine, that leaves us with two days of discussion
22:31 < tristan> rambokid, sure, I'll also take another closer look
22:31 < jdahlin> is anyone objecting to that?
22:31 < rambokid> jdahlin: no, issue settled, next point. ;)
22:31 < jdahlin> great!
22:31 < mclasen> 2. small api additions still pending
22:32 < mclasen> anything ?
22:32 < mjc> Any chance of my transform-pixbufs-based-on-orientation-tag patch happening?
22:32 < kris> I added some stuff to the page we started 
22:32 < kris> lemme give the url
22:32 < kris> http://live.gnome.org/GTK%2B/SmallApiAdditions
22:32 < ebassi> mclasen: the gtkrecentmanager API deprecations
22:33 < kris> I guess it would be very nice if we track stuff there
22:33 < ebassi> mclasen: and the radio button value api are my pet small api :-)
22:33 < tml> I would like to add a g_lseek() and perhaps g_ftruncate() that would take gint64. we can be sure that on posix platforms, glib and glib-using programs are compiled in an environment where lseek() and ftruncate take 64-bit offsets, right?
22:34 < rambokid> ebassi: ah, still in my inbox, what's the radoi button bug # again?
22:34 < ebassi> rambokid: 166995
22:34 < mclasen> kris: button sensitivity is not an api issue though
22:35 < kris> I didnt put it on the list
22:35 < mclasen> its there anyway...
22:35 < kris> I can remove it for you ;)
22:35 < mclasen> I can do that myself, but thanks
22:36 < lool> (done)
22:36 < mclasen> wiki sucks for collaborative editing
22:37  * lool . o O ( gobby is great )
22:37 < mclasen> anyway, the small gobject api addition on my list is that people have asked for boxed types for gregex/gmatchinfo
22:38 < mclasen> rambokid: any reservations about that ?
22:38 < rambokid> mclasen: any patch bug # to look at?
22:38  * mclasen looks
22:38  * rambokid compiles his high-prio bug list currently anyway
22:41 < mclasen> rambokid: 446723 and 445065
22:43 < jdahlin> there's also 338024 (glib), but it's pending some work from me
22:43 < jdahlin> I wanted to use that in gtkbuilder, but perhaps it's not that important.
22:44 < ebassi> and #440732 (glib) for me, since I use the list split function a lot
22:46 < mclasen> ok, anything else about api additions ? 
22:46 < mjc> Orientation tag handling = bug 439567. To fix Nautilus thumbnailing of tiff and jpeg images...
22:46 < mclasen> mjc: I'll put it on the list
22:46 < mjc> Thanks.
22:47 < mclasen> ok, time to move on, I guess
22:47 < mclasen> 3. remove remaining linux-fb bits 
22:48 < mclasen> I put that on the agenda, because I noticed linux-fb stuff when I was working on the docs recently
22:48 < mclasen> and I think it would be better if we finally remove it from the docs, from configure, and don't put the gdk/linux-fb code in the tarballs
22:49 < mclasen> since it hasn't compiled for years
22:49 < mclasen> and nobody stepped forward to fix it
22:49 < mclasen> and we have directfb now
22:49 < mclasen> I just wanted to see if there is any opposition to do that
22:50 < mclasen> it seems that is not the case...
22:50 < lool> I suppose no directfb file relies on it?
22:50 < mclasen> no
22:50 < mclasen> they are separate backends
22:51 < ebassi> dump it! :-D
22:51 < rambokid> jdahlin: yeah, ping me when you have the final patch for 338024
22:51 < mclasen> ok, next point 
22:51 < mclasen> 4. maemo branch
22:52 < mclasen> I don't know who wants to talk about that ?
22:52 < tko_> http://mail.gnome.org/archives/gtk-devel-list/2007-June/msg00000.html
22:52 < tko_> I didn't get too conclusive feeling from the one reply I got
22:53 < rambokid> tko_: i don't see a point in a maemo-gtk branch upstream actually
22:53 < mclasen> yeah
22:53 < tko_> just checking for any objections, comments, etc
22:53 < rambokid> i think upstream should just have branches for things that are candidates for trunk inclusion. and that's clearly not the case for maemo-gtk
22:54 < rambokid> tko_: also, we'd loose history/logs/annotate from the maemo repo, which would be fairly bad
22:54 < fer> we could solve it with some git-svn magic I guess :)
22:54 < tko_> I'd like to think in the longer term maemo-gtk would be just a set of configure options
22:54 < lool> (Not sure how you keep them when merging with SVN though; but at least these are in the same repo indeed)
22:54 < tko_> we could move the repository with history
22:54 < lool> fer: right
22:55 < tko_> (svnadmin dump + svnadmin import)
22:55 < xan> we should check the situation again after 2.12, maybe even a configure option is not worth it. Just saying
22:56 < tko_> xan, currently we have tons of little things there, even excluding tap'n'hold and new APIs.. just see treeview
22:57 < mclasen> re-evaluating after 2.12 sounds like a reasonable compromise to me
22:57 < tko_> ok
22:57 < mclasen> I appreciate the intent of shrinking the delta 
22:57 < xan> tko_, yeah, just saying I don't get the feeling we thought very hard about what we could drop from our spec, what not, what's completely un-mergeable, etc
22:58 < xan> but maybe it's just me
22:58 < xan> or s/very hard/as hard we we can/
22:59 < xan> but if checking after 2.12 is ok for everyone we can move on
23:00 < mclasen> last point on my list 
23:00 < mclasen> 5. releases
23:00 < mclasen> we already discussed getting the next devel snapshot out by the end of the week
23:00  * lool would have a couple of questions on the subject of releases and audience
23:00 < mclasen> I also want to do a 2.10.x release
23:00 < mclasen> soon
23:01 < mclasen> so if you have any fixes for the stable branch, please get them in 
23:01 < lool> a 2.10.x release would be really great as the directfb folks backported a bunch of fixes
23:02 < mclasen> will happen soon
23:02 < kris> that possible revert that we are discussing on the mailing list right now might be a good candidate for that
23:03 < mclasen> unless we decide to fix it with an api addition
23:03 < kris> yeah
23:03 < mclasen> lool: what was your question about audiences ?
23:03 < lool> I wanted to ask a couple of things WRT release, audience, and API/ABI stability:
23:03 < lool> Do you mind if the mainline Gtk in Debian has the maemo changes merged?  (The API additions need -DMAEMO_CHANGES but the ABI additions are visible.)
23:03 < lool> Do you have an idea of when you'd likely publish an API stable version (which could be uploaded to Debian experimental)?
23:03 < lool> Basically, I currently wouldn't want to publish to official repositories a dev release, but perhaps you would prefer Debian doing to get more audience
23:04 < kris> On 1; we don't decide about debian packages *at all*
23:04 < lool> The current rationale is to promess ABI stability and to change SONAME anytime the ABI breaks
23:04 < mclasen> lool: seems vaguely incongruent to worry about api instability in mainline but take the maemo changes in...
23:04 < lool> kris: Since we're talking about a popular platform for development with a large amount of users, I thought I would mention the point :)
23:04 < tko_> I think lool is referring to our patch to export filechooser interface for hildon-fm
23:05 < kris> lool: to be honest, I don't see the point at all for a desktop release ...
23:05 < tko_> the entry points are guarded with GTK_FILE_CHOOSER_ENABLE_UNSUPPORTED or such
23:05 < lool> mclasen: I completely agree; one of the things I'm reassured with is that some of these changes require -DMAEMO_CHANGES
23:05 < lool> kris: We don't have "desktop" release really
23:05 < mclasen> lool: anyway, to get back to your question
23:05 < xan> tko_, wasn't that scheduled to be merged too? pending on federico?
23:05 < fer> it needs some review I guees
23:05 < lool> tko_: Right
23:05 < tko_> xan, eventually.. but ubuntu mobile needs it now
23:06 < mclasen> this weeks snapshot will hopefully have GtkBuilder, so it will obviously not be frozen yet
23:06 < lool> Ubuntu published a partially modified Gtk; I /think/ some additional changes will be required in the future
23:06 < mclasen> and I would expect that we need at least one or two further snapshots to sort out GtkBuilder additions
23:06 < kris> lool: I meant to say that I would consider vanilla debian to be used on machines with a full size keyboard and monitor (a "desktop")
23:07 < tko_> lool, we hit 'unbind' gtkrc option being only in trunk.. either ubuntu backports it or edits gtkrc.. haven't figured out yet which way
23:07 < seb128> kris: the point is to make possible to run hildon on a desktop also
23:07 < lool> kris: Oh you don't see the point of merging the maemo changes,
23:07 < kris> tko_: which patch do you mean exactly?
23:07 < tko_> kris, filechooser?
23:07 < kris> tko_: yes
23:07 < kris> lool: yeah
23:07 < tko_> let me pick it up from the list...
23:08 < seb128> tko_: I'll upload 2.11 to gutsy soon which will do the trick ;)
23:08 < kris> lool: I do kind of see the point of putting 2.11.x release in experimental
23:08 < lool> <http://svn.debian.org/wsvn/pkg-gnome/desktop/experimental/gtk+2.0/debian/patches/009_gtk-export-filechooser.patch?op=file&rev=0&sc=0>
23:08 < lool> kris: Ok; I'm glad to hear you support this
23:08 < rambokid> lool: shipping MAEMO_CHANGES in debian packages would be a very bad idea. lots of things in maemo-gtk are still going to be changed a whole lot. either because they will hit trunk in a completely different form (that's been the case for 99% patches from maemo to trunk in the past) or because they are going to be replaced by newer upstream features like the new tooltips code. so baseline is, you can't guarantee API/ABI stability for MAEMO_CH
23:08 < rambokid> ANGES for the future. let nokia handle sorting out the changes and backfold them to upstream first and then re-evaluate the situation in 1 year or later.
23:08 < tko_> kris, https://lists.ubuntu.com/archives/ubuntu-mobile/2007-May/000182.html
23:08 < mclasen> lool: the more early exposure we can get for devel snapshots the better, in general
23:09 < mclasen> lool: personally, I'm fine as long as we have it in Fedora rawhide 
23:09 < mclasen> lool: because that means people come running into my cube if stuff breaks...
23:09 < lool> rambokid: Would I follow your recommendation, I wouldn't be able to package hildon stuff in Debian before one year?
23:10 < kris> ah, right, that's another patch then I had in mind
23:10 < lool> mclasen: Ok; I kind of understood devel releases were in some Fedora repo indeed, and I pondered doing the same in Debian
23:10 < lool> Thanks kris and mclasen; I consider the question of devel releases cleared, you don't need to answer about API stability then :)
23:10 < tko_> I'm definitely not suggesting to take all MAEMO_CHANGES, only the very minimum
23:10 < rambokid> lool: i don't know hildon requirements, i can just say that MAEMO_CHANGES is incompatible with real gtk upstream and doesn't have its API/ABI guarantees either. so it's simply not suitable for the debian audience.
23:11 < lool> rambokid: It's very interesting that you turn it this way, but instead of not including it at all, it makes me think that we should provide it in a separate set of packages
23:11 < tko_> currently only the filechooser is kind of a blocker with no upstream alternative
23:11 < tko_> I'm already telling them to use upstream tap'n'hold instead of ours
23:11 < lool> rambokid: So perhaps you would be more confortable with a libgtk-maemo-dev and a libgtk-maemo instead
23:12 < fer> well, that specific change it's not so _maemo_, it is just exposing some private gtk thing
23:12 < rambokid> lool: yeah, you could do that, ship it e.g. as a libmaemogtk. but keep in mind that you cannot replace normal gtk upstream with it because of incompatibilities.
23:12 < lool> Thanks for the comments, that completely answers my questions
23:13 < rambokid> tko_/fer: making the filechooser bits public is something that upstream badly needs yes. the question is how good it can be accomplished without federico review time
23:13 < seb128> tko_: speaking about upstream tap'n'hold, is it going to land in 2.11?
23:13 < ebassi> tko_: would it be possible to define GtkFilePath in gtkfilechooser.h and have a protected gtk_file_system_get_default()?
23:13 < tko_> seb128, kris has it in the list of things to push for 2.12 but dunno..
23:13 < ebassi> tko_: so we don't have to install gtkfilechooserprivate.h ?
23:14 < mclasen> seb128: the tap-and-hold thing seemed to block on animated cursors 
23:14 < tko_> ebassi, filechooserprivate has lots of more things, I don't really know which ones are really needed
23:15 < kris> mclasen: i will get back to that remaining tap-n-h thing soon
23:15 < mclasen> kris: get your exams done first, though
23:15 < kris> yes
23:16 < ebassi> tko_: it contains the private bits of the default implementation and other widgets; if you just want the GtkFileChooserIface structure it might make sense to move it into gtkfilechooser.h and define gtkfilepath there, so that we expose a minimum of the api
23:16 < ebassi> tko_: I've wanted to tinker with it for a while, now. I can give it a go
23:17 < tko_> ebassi, we also install gtkfilesystem.h, gtkfilesystemmodel.h and gtkfilechooserutils.h in addition...
23:17 < rambokid> lool: take a look at: http://live.gnome.org/Maemo/Gtk210Changes it's supposed to list *all* changes in maemo-gtk, i.e. all MAEMO_CHANGES. you may be able to reuse stock libgdkpixbuf for maemogdk/maemogtk for instance, because the pixbuf changes are small/negligible
23:18 < tko_> I hope no one is seriously considering all MAEMO_CHANGES equal, but look at them one by one and really consider whether it's needed
23:18 < lool> rambokid: So I should try to pull a minimum I suppose; and it's best to keep this in a separate pair of lib packages to ensure we don't break API/ABI of the main gtk
23:18 < rambokid> jup
23:19 < rambokid> tko_: i'm afraid packagers can't afford to do that. that's a huge task...
23:19 < lool> I'll delay the new libs as much as possible and see how it goes with main gtk + filechooser
23:20 < tko_> rambokid, I wouldn't even start considering unless someone comes with a requirement to have something (like the filechooser)
23:20 < rambokid> lool: the more you delay them, the smaller the delta gets
23:20 < lool> tko_: I suppose we'll pull them slowly in instead of pulling all; but it's not easy as a downstream to guess
23:20 < rambokid> tko_: tell lool, not me ;)
23:20 < tko_> I think lool is being pinged with specific needs
23:20  * lool will harass tko_ and rambokid each time it's needed
23:21 < lool> Hehe agoliveira just committed the removal of the unbind commands
23:21 < tko_> currently I know filechooser is needed, tap'n'hold desired (but for ubuntu the upstream API is better) and we stumbled upon missing 'unbind'
23:22 < lool> If it's all, that's great
23:22 < tko_> lool, yeah, I'm sitting next to him atm :)
23:22 < lool> tko_: Please say hi to the ubuntu mobile team :)
23:22 < mclasen> unbind sounds like something that might be feasible to get into 2.12 still
23:23 < mclasen> is there a patch for that ?
23:23 < rambokid> tko_: unbind is not maemo specific but would be a trunk backport
23:23 < tko_> I know
23:23 < lool> It's marked as 2.12 on http://live.gnome.org/Maemo/Gtk210Changes already it seems
23:23 < rambokid> ah ok
23:23  * rambokid shuts up
23:24 < rambokid> mclasen: mitch could cook up a patch i'd guess
23:24 < rambokid> lool/tko_: you could simply drop mitch a line on backfolding unbind i'd say
23:25 < fer> federico: we were talking about making some filechooser bits public
23:25 < lool> (Sorry but what's backfolding?)
23:25 < mclasen> 2006-10-05  Michael Natterer  <mitch@imendio.com>
23:25 < mclasen>         * gtk/gtkrc.[ch]: added new scanner token "unbind" which gets
23:25 < mclasen>         rid of a key binding (in fact, it only lets it appear unbound).
23:25 < xan> lool, move code from upstream to maemo-gtk
23:26 < lool> xan: Thanks
23:26 < mclasen> sounds like we are good wrt to unbind
23:26 < xan> lool, er, the other way around...
23:26 < lool> xan: Ah, that's clearer now
23:26 < tko_> maemo gtk lists three commits backported from trunk as one
23:27 < tko_> ah, but it's implementation + docs + docs
23:29 < rambokid> http://bugzilla.gnome.org/show_bug.cgi?id=358329
23:29 < rambokid> ^unbind
23:29 < xan> so if it's in trunk and in maemo-gtk who needs to do what? I'm slightly confused 
23:29 < rambokid> xan: it's needed in stable gtk
23:29 < rambokid> xan: only gtk trunk (devel) has it
23:30 < xan> ok, so mclasen meant 2.10 instead of 2.12, thanks
23:30 < federico> fer: sure, what do we need?
23:30 < xan> thought that lool was going to upload 2.11.x, but I'm probably missing stuff
23:30 < tko_> and ubuntu is picking up 2.11..
23:31 < federico> fer: (was there a bug for that?)
23:31 < fer> yeah let me check it
23:31 < rambokid> tko_: really? we don't guarantee API stability in 2.11.x, i.e. odd devel branches
23:31 < fer> http://bugzilla.gnome.org/show_bug.cgi?id=382528
23:31 < xan> rambokid, it's a devel release still I think
23:32 < tko_> rambokid, it's a devel release and based on the assumption that gnome2.20 will include it
23:32 < seb128> tko_: GNOME 2.20 will use it, that has been decided
23:32 < tko_> seb128, ah, maybe better you comment on it :)
23:33 < seb128> I'm going to upload GTK+ 2.11 to gutsy tomorrow
23:35  * lool will try to upload 2.11 to experimental soon
23:36  * lool waves good night
23:36 < lool> (or whatever)
23:36 < mclasen> looks like the meeting is over
23:36 < mclasen> any final comments ?
23:37  * mclasen notes GtkBuilder final call on gtk-devel already
23:37 < kris> not from me
23:37 < kris> until next week
23:37 < xan> any comment about the bug reports? something that could made them more useful to the maintainers?
23:38 < kris> xan: O
23:39 < rambokid> xan: for me personally, a per-person list would be interesting. but maybe that's too selfish... i.e. a a list like: "Timj: http...1 http...2" et.c
23:39 < kris> xan: I'd have to teach you how I randomly pick tree view bugs to fix ;)
23:39 < kris> xan: (though it's not that random)
23:39 < rambokid> so i know which ones to click on next to improve on the next weekly bug report ;)
23:39 < xan> if you guys think sorting by maintainer instead of widget/area is better, just tell :)
23:40 < kris> xan: I think sorting by widget is nice (at least for my corner ;)
23:40 < rambokid> xan: i guess we could try and drop the idea if it doesn't work out...
23:40 < mclasen> xan: I think sorting by widget is fine
23:40 < xan> kris, for you it'd be the same actually :P
23:40 < kris> xan: more or less ;)
23:41 < ebassi> xan: same for me - sorting by widget is fine
23:41 < xan> rambokid can always do M-x occur Tim then
23:41 < ebassi> xan: but adding the links makes it easier to jump to the reports :-)
23:42 < xan> ok, full links then
23:43 < xan> thanks for the comments, I guess that's it
23:57 < federico> fer: if you discuss it on the bug, I'll pick it up.  If you want to discuss it in gtk-evel-list, can you please CC me directly?  I follow the list, but only check it directly every few days :)