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
Attached FilesTo refer to attachments on a page, use attachment:filename, as shown below in the list of files. Do NOT use the URL of the [get] link, since this is subject to change and can break easily.
You are not allowed to attach a file to this page.