1 <aruiz> night lads
   2 <aruiz> :)
   3 <ebassi> hey aruiz 
   4 <aruiz> hey ebassi 
   5 <ebassi> as usual, the meeting agenda is available on the wiki: http://live.gnome.org/GTK%2B/Meetings
   6 <desrt> hi everyone
   7 * mclasen goes for coffee
   8 <behdad> hey
   9 <ebassi> hey behdad 
  10 <mclasen> who is cheerleading today ?
  11 <desrt> i like ebassi for that :)
  12 <ebassi> heh
  13 <ebassi> I'd make a fantastically bad cheerleader :-)
  14 <ebassi> anyway, the agenda points for the meeting are:
  15 <ebassi> 1. fundamental types for gint16/guint16 (bug: 562498)
  16 <ebassi> 2. use target milestone field in bugzilla
  17 <ebassi> 3. features set for gtk-next
  18 <ebassi> 4. features set for glib-next
  19 <ebassi> points 3. and 4. are fallout from last week's meeting
  20 <kalikiana> looks like someone cheated and avoided settling on actual points :P
  21 <ebassi> point 1. I think has been requested by davidz for GDBus mapping to the DBus type system
  22 <desrt> do we have any platforms where short != 16?
  23 <ebassi> point 2. is part of jjardon's set of queries for glib and gtk+ bugzilla products, which are fantastic
  24 <davidz> ebassi: well, yeah, for a type mapping from C/GObject <-> D-Bus it's kinda needed
  25 <ebassi> timj was notably against it when the bug was filed
  26 <ebassi> now, also the Vala people have been asking for it
  27 * mbt notes that #1 makes it possible to be more consistent about type strength (such as in Vala, for consistency)
  28 <kalikiana> so how true is timj's assertion that it's the wrong way to map types?
  29 <desrt> bug # for reference?
  30 <desrt> ah.  nm.
  31 <desrt> bug #562498
  32 <desrt> davidz: i disagree with your assertions in comment #6 there
  33 <Company> timj's argument is kinda broken, because we wouldn't have G_TYPE_CHAR that way
  34 <desrt> for a lot of the same reasons that timj gives in comment #15
  35 <davidz> desrt: that comment is pretty old
  36 <davidz> desrt: I think I disagree it with myself nowadays
  37 <desrt> ok
  38 <davidz> e.g. for D-Bus you want to pass the signature anyway
  39 <desrt> exactly
  40 <desrt> tim's "or use your own metainfo system"
  41 <davidz> right
  42 <mclasen> considering that gvariant will bring its own anyway, is this such a blocker ?
  43 <davidz> lacking fundamental types it's not a big deal for C/GType <-> D-Bus mappings - the only downside is that properties on the GObject will have type guint32 with a range [0, 65535]
  44 <desrt> the gvariant branch already contains code to serialise/deserialise gint/glong/gwhatever to dbus int16 without extra help
  45 <desrt> you just give the right type to the serialiser function and *magic*
  46 <davidz> desrt: I see you still haven't fixed the spelling ;-)
  47 <desrt> it even does the boundschecks and errors out as appropriate
  48 <davidz> desrt: btw, did you add the GError to the Serializer yet? would be neat
  49 <kalikiana> davidz, you can set limits on the paramspec regardless of the type
  50 <desrt> davidz: no.  aruiz has been slave-driving me to work on another project this past couple of weeks, so i've done very little gvariant work :p
  51 <davidz> kalikiana: yes
  52 <aruiz> desrt, :P
  53 <davidz> desrt: maybe it's time to send some goons to talk to aruiz ;-)
  54 <desrt> davidz: but i absolutely agree that it's a good idea
  55 <desrt> only blocking on my free time right now
  56 <aruiz> davidz, in my defense I'd say, that work would be done already if desrt didn't chewed nicotine gums
  57 <Company> gtype should decide if it wants to follow C conventions or space conventions for naming its integers
  58 <desrt> aruiz: hah.
  59 <Company> but that's 3.0 stuff
  60 <desrt> Company: i think the current mix that we have now is appropriate
  61 <Company> desrt: i disagree
  62 <davidz> so, from the gdbus side of things not having fundamental types for guint16/gint16 is not a big deal - 
  63 <davidz> however it's just pretty ugly having to use a guint32 with limits for GObject properties instead of, hey, a guint16
  64 <davidz> as a general sentiment even
  65 <Company> desrt: long is useless for example
  66 <desrt> i love long
  67 <mclasen> so, are we done with 1. ? not urgent for gdbus, thus timj wins ?
  68 * Company agrees with mclasen
  69 <davidz> mclasen: I guess
  70 <desrt> as someone who has written serialiser code, i have to agree with the point of "please no more new int types to put in my switch statement"
  71 <mclasen> ok then
  72 <davidz> yeah, but it just feels incomplete this way
  73 * davidz OCD but meh
  74 <mclasen> 2. 'target milestones' - what is that about ?
  75 <mbt> I don't think that's OCD, I think it's just consistent. 
  76 <mclasen> who presents that point ?
  77 <desrt> jjardon, i guess
  78 <Company> that's jjardon's job
  79 <desrt> and he's not here....
  80 <ebassi> I can talk about that
  81 <mclasen> mbt: that'd make it CD - consistent disease
  82 <ebassi> it's basically a request, when we are planning a release, to use the target milestone for bugs
  83 <davidz> ebassi: I'd like that very much
  84 <ebassi> so that we can have queries to check the status of the release
  85 <ebassi> and also when writing the release notes
  86 <ebassi> it's mostly QA stuff
  87 <ebassi> but requires some developers time
  88 <ebassi> by the way, if you want to look at the current queries, here: http://live.gnome.org/GTK%2B/BugzillaLinks
  89 <ebassi> the queries can also partly replace the patch nagging emails on the mailing list, or at least make them easier to write
  90 <ebassi> I've been using them and splinter to review trivial patches, and it's really easy to get things going
  91 * mclasen has some doubt how well this is going to work in the giant pile of bugs that we have...
  92 <ebassi> mclasen: bugzilla is faster nowadays, and this mostly helps tracking down unreviewed patches - which, sadly, are a minority of the bugz
  93 <ebassi> bugs, even
  94 <mclasen> I'm open to trying it
  95 <kris> did we start at 21?
  96 * kris is so confused
  97 <ebassi> e.g. the unreviewed query returns 501 bugs
  98 <mclasen> but I'm unclear on what we would target milestone, beyond the handful of big features we target for a release
  99 <Company> kris: utc has no daylight savings
 100 <aruiz> kris, time shift this week
 101 <kris> ....
 102 <aruiz> kris, to the winter time
 103 <kris> and the meeting time doesnt switch?
 104 <desrt> meeting time is set in UTC
 105 <desrt> north america and the entire southern hemisphere changes timezones differently than europe :p
 106 <ebassi> mclasen: jjardon was asking if the TM could be set when the maintainers decided to plan to land a bug for a release
 107 <ebassi> I'm mostly worried of abuse from non-team members
 108 <mclasen> ebassi: I don't really ever decide to 'land a bug in a release'...
 109 <kalikiana> mclasen, but there are things like widgets or features that are planned for a release
 110 <kalikiana> so it just makes it easier to track
 111 <kalikiana> and you don't have to collect old mails for that
 112 <kris> blah, timezonres
 113 <mclasen> kalikiana: yeah, thats the 'handful of features' I mentioned....
 114 * kris continues debugging his compiler
 115 <ebassi> I think it can also be tracked retroactively
 116 <ebassi> for distributors
 117 <ebassi> anyway, I'm just reporting the suggestion :-)
 118 <mclasen> as I said, I'm open to trying this, though I'm a bit dubious on how useful it will turn out to be
 119 <kalikiana> and it can help people who are not up to date and attending meetings
 120 <kris> what's the use case for setting the target milestone on bugs?
 121 <kris> just for release-based queries?
 122 <ebassi> kris: yes
 123 <kris> I mean, its an extra hassle and handling
 124 <kris> and what do you do if you put the fix in two releases?
 125 <kris> (ie. stable and stable-1)
 126 <ebassi> kris: tracking releses progress and see what's still pending
 127 <kris> haven't we tried milestones in the past?
 128 <kris> I recall setting them in the 1.3 / 2.0 times
 129 <kris> and we also had to punt half of them ...
 130 <kris> changing milestones again
 131 <ebassi> yey bugmail :-)
 132 <kris> but if it helps people, why not
 133 <Company> you should just do it on the visible tracker bugs
 134 * kris shouldnt speak up so loudly since he does only 1% of the work ...
 135 <ebassi> kris: you should really check out http://live.gnome.org/GTK%2B/BugzillaLinks
 136 <kris> ebassi: oh, what a list
 137 <ebassi> bugzilla in being actually useful shocker :-)
 138 <kris> ebassi: I use only two bugzilla links
 139 <kris> ebassi: 1. tree view bugs
 140 <kris> ebassi: 2. mac bugs
 141 <kris> ebassi: and I barely manage to keep up with only those unfortunately
 142 <kris> Company: that might make sense
 143 <ebassi> kris: I think these are mostly useful for new contributors, to easily grok what's going on, and for drive-by reviews
 144 <ebassi> anyway, I'll shut up now :-)
 145 <kalikiana> kris, I think there's no problem if you keep doing that. jjardon does a good job at tracking bugs
 146 <kalikiana> and others can also do that
 147 <ebassi> kalikiana: and he's leaving the breadcrumbs behind for new people joining :-)
 148 <kris> ebassi: it will only help if the milestones are kept up to date, which basically fell apart in the past
 149 <ebassi> kris: fair point
 150 <kalikiana> I think we have mostly overcome the point where gtk was stalling
 151 <bratsche> Yeah, I like what jjardon's doing except for how he links all the bugs together and if one bug changes then you get a shitload of emails for all the linked bugs. :)
 152 <kris> kalikiana: it even fell apart when we had 3 full-time maintainers
 153 <kalikiana> kris, but bug triaging doesn't have to be done by a maintainer as you can see
 154 <kris> kalikiana: but I assume maintainers are in charge of setting and updating the milestone?
 155 <kalikiana> in charge of decisions, sure. but that doesn't mean they have to do every part of the work
 156 <Company> it's only 10 bugs total per release anyway, no?
 157 * kalikiana wonders why this kind of topic always causes this extremely loud silence.
 158 <ebassi> hehe
 159 <Company> next point!
 160 <bratsche> I'm not saying much because it doesn't affect me that much and I don't care enough.
 161 <desrt> did we come to a satisfactory resolution yet?
 162 <mclasen> desrt: I think we all agreed that its cool if jjardon puts milestones on the bugs we work on... :-)
 163 <bratsche> And I'm busy hacking in another window anyway. :)
 164 <desrt> ok.  so gtk-next features?
 165 <mclasen> next == 2.20 ? or 2.20 + 1 ?
 166 <desrt> agenda just says "gtk-next" :)
 167 <ebassi> it says next because I screw up the version number
 168 <Company> i'm pretty sure we're talking 2.20 + 1
 169 <ebassi> next stable release for gtk and glib
 170 <bratsche> Next stable is 2.20.
 171 <Company> as the featureset for 2.20 was pretty much set in stone 3 weks ago
 172 <mclasen> quick summary for 2.20 is that we have landed spinner widget + cell renderer
 173 <kalikiana> yay
 174 <bratsche> mclasen: Are the things that were on your blog for F12 things going into 2.20?  (is F12 using 2.20?)
 175 <mclasen> and tbf promised to brush up the tool palette before end of november
 176 <kris> what spinner?
 177 <mclasen> and I would like to propose some tooltip refresh, indeed
 178 <ebassi> bratsche: F12 is using 2.18
 179 <mclasen> F12 is using 2.18 + patches
 180 <kris> mclasen: the one you blogged about?
 181 <mclasen> kris: GtkSpinner
 182 <mclasen> kris: the tooltip stuff, yeah
 183 <bratsche> mclasen: Minor thing, but I want to add some API for getting the primary display, as I talked to you one night.
 184 <bratsche> Err.. primary monitor.
 185 <mclasen> sounds like a good idea to me
 186 <mclasen> we're still lacking the setter ui for that though
 187 * mclasen looks at federico
 188 <kris> mclasen: I am unsure about the blue, but thats a theming thing really
 189 <bratsche> I'm back home as of yesterday so I can test it out since I have an extra monitor now.
 190 <kris> mclasen: I would love to help out reviewing the updates to the positioning algorithm
 191 <mclasen> kris: the color is entirely theme-land
 192 <mclasen> https://bugzilla.gnome.org/show_bug.cgi?id=599617 has the patch about visual things
 193 <ebassi> mclasen: the new tooltip stuff is pretty cool
 194 <mclasen> https://bugzilla.gnome.org/show_bug.cgi?id=599618 has the positioning patch
 195 <mclasen> if people want to review, that would be great
 196 <ebassi> metacity tooltips still kind of suck, though :-)
 197 <kris> I can put the positioning thing on my list
 198 <mclasen> ebassi: oh, I patched that as well :-)
 199 <ebassi> ah, nice
 200 <mclasen> to finish up the 2.20 feature list, I have no idea where we stand wrt to missing accessors 
 201 <mclasen> any progress on that ?
 202 <bratsche> Uh, kind of tangentially related.. gtk_button_pressed() and similar API is deprecated since those signals moved into GtkWidget.  What was the purpose of that API anyway, and does there need to be gtk_widget_pressed() type stuff?
 203 <bratsche> Or at least that's my understanding of what I read in irc late last night, so was just curious.
 204 <kalikiana> we have gtk_button_clicked
 205 <federico> hum
 206 <kalikiana> not that I know what for :P
 207 <federico> mclasen: oh, BTW, I meant to ask you about fedora's fixes for the RANDR stuff
 208 <bratsche> At first I thought maybe it's used for testing, but I guess stuff like Strongwind and Dogtail does everything through ATK so I'm not sure what those functions are used for now.
 209 <federico> mclasen: you know, for now I guess it's fine to commit your patch to enable the "primary monitor" checkbox... I don't have time to do the full UI rework I want to do :(
 210 <mclasen> federico: I lost that patch :-(
 211 <mclasen> the only other significant randr fixes i've done lately is to make gnome-screensaver actually work with hot-plugging multihead
 212 <kalikiana> bratsche, for testing there are gtk_test_ functions
 213 <kalikiana> the only thing gtk_button_clicked does anyway is g_signal_emit
 214 <bratsche> Okay
 215 <desrt> anything else for gtk?
 216 <desrt> we move to glib 2.24 features?
 217 <kalikiana> possibly diagnostic mode, if I find time for that
 218 <kalikiana> at least I intend to
 219 <ebassi> kalikiana: if you can get me a list of requirements and ideas on that I'd gladly give a hand
 220 <kalikiana> ebassi, I have a long document about that, I should try to get that on the list or bugzilla I suppose
 221 <ebassi> kalikiana: I remember discussing it a GUADEC in Istanbul, but I never got a solid list of what the diagnostic mode would require
 222 <ebassi> kalikiana: cool, thanks
 223 <kris> ebassi: there's a list of ideas, but nothing concrete
 224 <aruiz> may I ask, what's diagnostics mode?
 225 <kalikiana> giving out warnings about using old properties and signals
 226 <kalikiana> or poking inside widgets
 227 <ebassi> aruiz: something that will tell you if you're using obsoleted signals, properties
 228 <ebassi> for runtime checks, as opposed to compile-time ones
 229 <aruiz> uh, funky
 230 <desrt> #521707?
 231 <desrt> (class private data)
 232 <mclasen> didn't we talk about that last week ?
 233 <desrt> ah.  i missed that.  and it's sitll on the list as 'to do'
 234 <ebassi> jjardon: hey :-)
 235 <desrt> i guess that means that it's decided to be included but needs more work?
 236 <kris> okay, i can once more re-iterate that status on that bug
 237 <kris> there's a patch
 238 <kris> it has been pre-reviewed
 239 <kris> we even found a bug during that pre-review
 240 <kris> and that bug was fixed
 241 <kris> its valgrind clean
 242 <jjardon> ebassi, hello ;) and hello all
 243 <desrt> kris: so what holds up the commit?
 244 <mclasen> timj uncloaked a while ago, so maybe we can get him to approve ?
 245 <desrt> also, if we are going to use this functionality for adding new vfuncs as the table gets full, do we have 'best practice' for that?
 246 <desrt> also, also, does it become customary to have a *priv; pointer in class structs now?
 247 <jjardon> desrt, Are you seeing the http://live.gnome.org/GTK%2B/Roadmap ? I've set todo because Class private data bug is still not fixed, but I don't know the real status. Feel free to modify it if you want
 248 <kalikiana> I created http://live.gnome.org/GTK+/BestPractices to collect suggestions on how to do things
 249 <kalikiana> ^^ desrt 
 250 <desrt> jjardon: yes.  that's exactly what i was looking at.  understood.
 251 <desrt> timj: ?
 252 <kalikiana> I think priv is an obvious choice, unless you hide structures in c files
 253 <desrt> danw: anything to say about gnio issues?
 254 <kalikiana> otherwise the sealing would be moot :P
 255 <desrt> kalikiana: obvious choice for new sturctures that have space for it...
 256 <kalikiana> yes, not old ones of course
 257 <kalikiana> looking up private data has always been costly, I doubt that will change
 258 <danw> desrt: not beyond what i said a few weeks ago. (planning to work on tls and proxies)
 259 <desrt_> sorry.  linode chose a very bad time to start having connectivity problems.
 260 <desrt> did i miss anything?
 261 <ebassi> 21:17 < kalikiana> looking up private data has always been costly, I doubt that will change
 262 <ebassi> 21:18 < danw> desrt: not beyond what i said a few weeks ago. (planning to work on tls and proxies)
 263 <ebassi> nothing else
 264 <desrt> cool.
 265 <desrt> i want to merge gvariant to master asap
 266 <desrt> several people have been using it now and they all seem to like the API a lot
 267 <desrt> and it has been stable for a fairly long time
 268 <desrt> so i think in that regard it's ready to go
 269 <desrt> it's also strictly an addition so it's not going to break anything that exists
 270 * mclasen will give it another look 
 271 <mclasen> where do I find the current merge candidate ?
 272 <federico> mclasen: oh, interesting - I thought gnome-screensaver already did that
 273 <federico> mclasen: ok, no problem - I'll redo the primary monitor thing
 274 <desrt> 'gsettings' branch
 275 <desrt> but i propose only to merge the stuff in glib/
 276 <desrt> i can make a separate branch for that if you prefer
 277 <desrt> one blocker, though, is the 1-bit mutex lock stuff
 278 <desrt> http://bugzilla.gnome.org/show_bug.cgi?id=548967
 279 <jjardon> mclasen, http://git.gnome.org/cgit/glib/log/?h=gsettings
 280 * mclasen goes to look
 281 <desrt> i can do the merge without the 1-bit mutex locks if you prefer
 282 <federico> mclasen: refresh my memory, please - that info is already in the XML and there is a gnome_rr*() API to get the primary value, correct?  we just need to select that in the GUI?
 283 <desrt> (and add thread-safety later)
 284 <mclasen> hmm, theres also a gvariant branch
 285 <jjardon> desrt, Could you create a bug to integrate gsettings branch and then we can set  http://bugzilla.gnome.org/show_bug.cgi?id=548967 as a blocker?
 286 <mclasen> federico: yes, I think thats accurate
 287 <federico> mclasen: ok, should be easy
 288 <federico> bratsche: so from GTK+'s viewpoint you just want to add an API to get the primary monitor?
 289 <desrt_> *sigh*
 290 <kalikiana> cats biting in your internet cable? :)
 291 <desrt_> when linode went down i wondered if it was the local connection
 292 <desrt_> so i tried one of my neighbour's
 293 <desrt_> not so reliable there either :p
 294 <aruiz> desrt, <jjardon> desrt, Could you create a bug to integrate gsettings branch and then we can set  http://bugzilla.gnome.org/show_bug.cgi?id=548967 as a blocker?
 295 <desrt_> jjardon: sure.  i'll do that.
 296 <desrt_> i can also create a branch that contains exactly the parts that i want to commit ASAP (ie: no gobject/ or gio/ changes yet) if that would help
 297 <jjardon> desrt_, great 
 298 <desrt_> with gsettings and gdbus both inside glib wanting to use this...
 299 <desrt_> and dconf outside of glib already shipping its 4th tarball...
 300 <desrt_> would be really helpful to get this into master branch soon
 301 <mclasen> desrt_: having such a branch would be nice
 302 <desrt_> ok.  i'll have that ready for the next meeting, then
 303 <desrt_> should i include the 1bit mutex stuff on that branch or leave it out for now?
 304 <desrt_> (i don't currently have any code that uses GVariant multi-threaded, so i don't care)
 305 <bratsche> federico: Yeah, that's what I was going to do.
 306 <bratsche> (sorry, was afk for awhile)
 307 <bratsche> federico: I'll file a patch soon and ask you and mclasen for review.
 308 <kalikiana> desrt, waiting for an application to stumble into threading once it's in glib isn't attractive, though :)
 309 <kalikiana> imho
 310 <desrt> but it's easy to fix in the future
 311 <desrt> since the design was made to allow it easily
 312 <desrt> and for the time being, i'm happy enough to say "not threadsafe yet"
 313 <kalikiana> Yes, the point is that it will be a pain for the one trying to use it
 314 * desrt just trying to remove blockers to a speedy merge :)
 315 <kalikiana> hehe
 316 * bratsche tries to start thinking of new blockers just to annoy desrt
 317 <desrt> "merge must be performed by someone in dallas"
 318 * desrt is all over that one
 319 * mclasen would rather see threadsafety issues worked out first...
 320 <desrt> mclasen: i'll include the mutex stuff in the branch i make and mark that bug as a blocker ,then
 321 <desrt> davidz: poke
 322 <davidz> desrt: yes?
 323 <desrt> davidz: gdbus is marked 'further discussion'
 324 <davidz> desrt: for today? or what?
 325 <desrt> on the roadmap
 326 <davidz> desrt: I talked to mclasen and we seemed to agree it should be reviewed, then merged for this cycle
 327 <desrt> ok.  i'll move it out of the 'more discussion required' section, then
 328 <davidz> my branch is basically feature complete sans some GDBusProxy surgery/fixes
 329 <davidz> the plan is to get alexl to review it once he is back
 330 <desrt> nice.
 331 <jjardon> davidz, Do you mind if I post that info in GTKRoadmap page?
 332 <desrt> jjardon: already editing :)
 333 <jjardon> desrt, oh, great :)
 334 <desrt> it's late
 335 <desrt> does anyone have anything else they want to discuss?
 336 <jjardon> I'd like to show you this page, maybe It's useful to review patches and bugs: http://live.gnome.org/GTK%2B/BugzillaLinks
 337 <bratsche> It was posted earlier.
 338 <ebassi> jjardon: already pimped it :-)
 339 <desrt> jjardon: if i'm to understand this milestone stuff correctly, i target my gvariant bug against that?
 340 <desrt> for 2.24.0...
 341 <jjardon> desrt, exactly
 342 <desrt> cool
 343 <desrt> ebassi: want to call it?
 344 <jjardon> but someone should add 2.24 to posible target milestores in glib
 345 <jjardon> and 2.20 in gtk+
 346 <ebassi> desrt: let's call it then :-)
 347 <desrt> sweet
 348 <ebassi> thanks everyone
 349 <desrt> food time :)
 350 <mclasen> jjardon: I can do that
 351 <desrt> ebassi: thanks, as always :)
 352 <bratsche> Yum.
 353 <jjardon> mclasen, thank you
 354 * ebassi ate in front of the laptop
 355 <davidz> jjardon: go for it ;-)
 356 <davidz> desrt: btw, should I file bugs for the gvariant issues I have? is there a gvariant component in bugzilla?
 357 * jjardon forgot the change to GMT+2 to GMT+1 in his country :/
 358 <desrt> yes
 359 <davidz> desrt: (not really 'issues' per se - just the stuff raised on the list)
 360 <desrt> to keep the issues from annoying everyone i made the gvariant component under 'dconf' for now
 361 <davidz> desrt: okey-dokey, I'll file away
 362 <desrt> i'll move the bugs over when the merge happens
 363 <jjardon> davidz, please use the target milestore field and set it to 2.24 ;)
 364 <davidz> will do
 365 <jjardon> will any of the feature branches get merged for 2.20? Extended layout, xi2, Resolution Independence or Client Side Decorations? Sorry if this was discussed before
 366 <federico> bratsche: sure
 367 <ebassi> jjardon: whatever is ready and reviewed
 368 <desrt> davidz: have you looked at gvariant past the API?
 369 <desrt> davidz: like, implementation....
 370 <davidz> desrt: only very briefly
 371 <ebassi> jjardon: that was discussed three weeks ago
 372 <desrt> davidz: probably will be helpful to have at least one other person familiar with it
 373 <desrt> davidz: and you are obviously the best choice
 374 <davidz> desrt: increasing the bus-factor is always good ;-)
 375 <jjardon> ebassi, The question is if I can move them out of the 'more discussion required' section?
 376 <desrt> davidz: i'm working on data model API stuff for at least the next couple of days
 377 <desrt> davidz: but i'd be happy to schedule some sit-down time with you on thursday or friday?
 378 <desrt> block out a couple of hours and bring you completely up to speed
 379 <davidz> desrt: that might work - I need to finish some polkit stuff but that should be done tomorrow - still, let's say Friday?
 380 <desrt> ok
 381 <desrt> 1pm?
 382 <davidz> desrt: sounds good to me
 383 <Company> jjardon: have there been any bugs wrt the filesystemmodel merge?
 384 <jjardon> Company, no, as far I know
 385 <Company> so noone is using git master yet
 386 <Company> or our code is bugfree
 387 <jjardon> our code is bugfree :)
 388 <desrt> what is FSModel?
 389 <jjardon> maybe when 2.19.0 will be released
 390 <jjardon> we will have more testers
 391 <Company> desrt: filechooser rewrite i did
 392 <mclasen> about that...
 393 * mclasen meant to do releases this week
 394 * desrt was under the impression that GIO *was* the filesystem model for gtk
 395 <mclasen> but so far not sufficient breathing room to do it
 396 <Company> desrt: gio didn't implement GtkTreeModel last i checked :p
 397 <desrt> oh.  i see.
 398 <desrt> it'll all be a moot point when i propose the model API next week :p
 399 <Company> as long as it has the same performance characteristics for 40k entries
 400 <jjardon> mclasen, Is there any plan to do gtk 2.19.x releases based in time, instead by features?
 401 * desrt wanders away
 402 <jjardon> maybe we can use target milestore field to 2.19.x releases too. As "objectives" between meetings
 403 <ebassi> sorry, jjardon - same linode issues desrt had
 404 <ebassi> I lost everything after "can I move the branches from the needs discussion"
 405 <mclasen> jjardon: there's just not that much going on for 2.19.x from my perspective; get the remaining accessors in and get toolpalette merged, anything beyond that is just extra goodies
 406 <jjardon> ebassi, no problem :). So can move feature branches out of the 'more discussion required' section? (in http://live.gnome.org/GTK%2B/Roadmap)
 407 <jjardon> mclasen, only a idea to focus the development between releases: if something can't be done for 2.19.1, it can be converted as a objective for 2.19.2
 408 <mclasen> man, you must have been a fedora developer in a former live
 409 <mclasen> so much love of process :-)
 410 <jjardon> mclasen, only a student for now :) Think: if I'm a new contrinutor and I want to help, I need a list of bugs to focus, because bugzilla database is quite big: and a list of bugs that are important for the next release is quite motivating
 411 <Company> do developers really turn up and say "i'm gonna implement a new feature" and deliver without having any previous hacking experience?
 412 <Company> usually they either know what they want or they start small
 413 <jjardon> and I think that would be useful for core devels too
 414 <mclasen> its ok, just making fun...
 415 <jjardon> Company, not only for newbies. Imagine a experience GTK+ hacker that want to help in gtk+ development: they can take a look in the bugs targeted for the next release to see what the people is working on. I think this is more easy than search in bugzilla for a bug
 416 <bratsche> mclasen :)
 417 <Company> jjardon: i've never seen any of the gtk devs do that
 418 <Company> jjardon: they usually have their own todo lists
 419 <kalikiana> I look at easy bugs sometimes, whether I hit them myself or not. But then again, I do have my own list based on gtk bugmail
 420 <kalikiana> I would guess for someone not receiving all gtk bugmail it should be useful