1 * mclasen looks for the agenda 2 < kris> garnacho: carlos is a graaaaaaape carlos is a graaaaape 3 < ebassi> http://live.gnome.org/GTK+/Meetings 4 < aruiz> kris, you bet 5 < ebassi> 1. gobject-performance branch status; 2. gtk+ 2.90 branch; 3. GLib 2.22 branch and future; 4. GtkFileSystemModel branch status; 5. Miscellaneous 6 < kalikianatoli> maybe we could add "reviewers" to the topics? it was mentioned on the list a few days ago 7 < mclasen> I think that may go under 3. "and future" ? 8 < kris> it was mentioned as part of 1. ;) 9 < kris> but i agree with putting it up explicitly 10 < kris> or under 3 11 * mclasen has some 'feature work for 2.20' items 12 < kalikianatoli> no idea what future is exactly. if that includes "who is gtk 3" then I guess it fits 13 < bratsche> I have some feature work in my queue, for whatever is the next major release. 14 < garnacho> me too 15 < kris> I have a snow leopard machine now woooooooo 16 < aruiz> beware 17 < bratsche> :) 18 < kris> so I can make the gtk+ backend more awesome 19 < aruiz> :) 20 < mclasen> ok, shall we start running down the agenda ? 21 < aruiz> mclasen, yes 22 < kris> I also have my tiger machine still, so I can retain compat ;) 23 < mclasen> 1. gobject-perfomance status 24 < mclasen> I believe alex merged the easier parts of that branch to glib master and proposed to look at the rest after branching 25 < mclasen> and I have seen some review activity from timj there, recently 26 < timj> jup, and alex told me the remaining stuff isn't as urgent 27 < mclasen> so, we are over that hump for now, it seems 28 < mclasen> anything else on that topic ? 29 < mclasen> ok, then lets move to the next topic, I guess 30 < aruiz> :) 31 < mclasen> 2. gtk 2.90 branch 32 < kalikianatoli> I haz one 33 < bratsche> I can offer to setup PPA builds of gobject-performance and/or GtkFileSystemModel branches and get someone in Ubuntu to advertise them and get some user testing on them if you think it would be useful. 34 < kalikianatoli> or rather, I started working on that, and I'd like to push it to git.gnome.org and let others join the fun 35 < aruiz> bratsche, that would help a lot 36 < aruiz> at least for the ubuntuers around 37 < aruiz> kalikianatoli, is there anything stopping you to push that branch upstream? 38 < bratsche> It would help get more users testing it, but I'm not sure it's worth the effort of dealing with bug 39 reports from people using the branches since they may not know what issues are being caused by the branch vs. not. 40 < mclasen> can we summarize the purpose of that branch again, quickly ? 41 < kalikianatoli> aruiz, The lack of having discussed it :) 42 < mclasen> this is for dropping deprecated stuff and build with gseal, right ? 43 < kalikianatoli> Yes 44 < kalikianatoli> like the # in the wiki page 45 < mclasen> and we are going to keep it otherwise in sync wiht master ? 46 < kalikianatoli> Yes, that's the idea 47 < ebassi> kalikianatoli: do you plan merging or periodically rebasing it? 48 < kalikianatoli> I think javier also suggested to get some patches to master where it makes sense 49 < kalikianatoli> ebassi, Yeah 50 < kalikianatoli> s/javier/jjardon 51 < jjardon> hello all 52 < kalikianatoli> jjardon mentioned applying some of the accessors/ 2.9 things onto master 53 < bratsche> Is the idea to have a GtkFooPrivate* member in your GtkFoo instance struct, and internally call foo->priv->x? Or to call priv = FOO_GET_PRIVATE() and access priv->x that way? 54 < bratsche> Currently the code rewriter is doing the second way I think. 55 < ebassi> bratsche: no, don't use FOO_GET_PRIVATE() (if it maps to G_TYPE_INSTANCE_GET_PRIVATE()) 56 < kris> bratsche: as far as I know the latter has proven to be a performance bottleneck, so I guess we should definitely go with the former 57 < kalikianatoli> GET_PRIVATE at runtime is a performance nightmare :) 58 < bratsche> Okay, then I'll change the rewriter. 59 < ebassi> kalikianatoli: yeah to which one? merging or rebasing? :-) 60 < kalikianatoli> ebassi, Oh, rebasing :) 61 < ebassi> kalikianatoli: ok, good to know 62 < ebassi> kalikianatoli: having the 2.90 branch on git.gnome.org would certainly be good - one less remote to check :-) 63 < kalikianatoli> Yep, definitely 64 < kalikianatoli> Btw did we discuss the pkgconfig name yet? 65 < bratsche> Not that I've seen. 66 < bratsche> I assumed it would be gtk+-3.0 67 < jjardon> kalikianatoli, yeah the idea is only use -> (direct acces) to access own variables, and accesor functions for the rest 68 < mclasen> who is going to take on the job of keeping master and 2.90 in sync ? 69 < bratsche> I don't mind sharing this responsibility, but I can't take on the entire job. 70 < mitch> um, too bad i'm late 71 < bratsche> mitch: We've assigned all the work nobody else wants to do for you. ;) 72 < kalikianatoli> Maybe we can see that one out of n people does 73 < kalikianatoli> Otherwise I will try to find the time for it 74 < mitch> was the issue of adding api to 2.18.x i brought up on #gtk+ already discussed? 75 < ebassi> kalikianatoli: I can also volunteer for that 76 < bratsche> mitch: No. 77 < mitch> ok 78 < kris> mitch: could you be more specific as well maybe? :) 79 < mitch> yes 80 * mclasen envisions 2.90 to be a relatively minor branch that gets rebased periodically. am I wrong with that ? 81 < mitch> i'm suggesting to add missing accessors for sealed member to 2.18.x 82 < ebassi> mclasen: I'd expect that as well 83 < bratsche> http://live.gnome.org/GTK+/Meetings (we're on the 2.90 item now) 84 < mitch> mclasen: no that's mostly right 85 < mitch> mclasen: minus removal of all deprecated api 86 < kalikianatoli> ebassi, I'd like to have names and tasks somewhere in the wiki, to organise this a bit 87 < kalikianatoli> ie. roughly see who can do what 88 < ebassi> kalikianatoli: sure 89 < mclasen> mitch: ah right, the deprecated stuff is going to be large 90 < mitch> rationale for adding api to stable: we expect people to port to sealed gtk during the 2.18 period, and they can only do that if the needed api is there 91 < bratsche> mclasen: The changing of internal functions from foo->x to foo->priv->x is going to be a lot I would imagine. 92 < kalikianatoli> ebassi, I'll update http://live.gnome.org/GTK+/3.0/Tasks after the meeting, and add you with a new item there :) 93 < ebassi> kalikianatoli: sure 94 < mitch> any opinions about my suggestion? 95 < mclasen> I'd rather do an intermediate 2.20 to pick up remaining api additions 96 < kalikianatoli> I'd rather see an intermediate release of Gtk than new API in stable 97 < kalikianatoli> heh 98 < mitch> so what about new unstable features that are in master at that point? 99 < aruiz> I sort of agree there, also, there are deprecations that we might want to add before 2.90 100 < mclasen> mitch: we won't merge them to master before they are stable enough for a release ? 101 < mitch> mclasen: who decides that they are stable given nobody tests branches? :) not going to work... 102 < kalikianatoli> unit tests! 103 < mitch> i'm really talking *exclusively* about accessors 104 < mitch> like gtk_foo_get_bar() 105 < mclasen> mitch: realistically, new features in master won't be really tested until apps start using them in the next cycle either 106 < mitch> that's not "new features" 107 < mitch> mclasen: granted 108 < kalikianatoli> mitch, even you make typos, don't you? :) 109 < jjardon> I really need mitch accesors to complete some patches 110 < mclasen> mitch: maybe it would help to look more concretely at the 'unstable features' we've actually lined up for merging... 111 < bratsche> Do you have any idea how long until you want to do a 2.20 release? Or is it too early to ask that? 112 < mitch> yea, and from gimp experience i can definitely say that i can't 113 port gimp to sealed gtk 2.18 because there is so much stuff missing 114 < mitch> mclasen: indeed, but i didn't see that line so far 115 < Company> would it make sense to do a quick 2.20 with all those features? 116 < mclasen> mitch: off the top of my head, I know at least the toolpalette stuff, xi2, and filesystemmodel 117 < mitch> mclasen: which all looks safe apart from xi2, sorry garnacho ;) 118 < bratsche> Depending on the time frame, I was hoping to get decorations stuff into 2.20. 119 < mitch> mclasen: is there anything that speaks against a really quick 2.20 release? 120 < bratsche> But if it's really soon then I guess it waits. 121 < mclasen> there are probably more things that would be nice to have, but not ready, like the extended geometry stuff 122 * aruiz wants to deprecate the tab-pack child property before 3.0 123 < mitch> i mean, now is the time to ask people for missing accessors 124 < mclasen> mitch: not from my perspective 125 < aruiz> for GtkNotebook that is 126 < mitch> i need about 10-20 accessors to seal gimp's gtk call completely 127 < mitch> that's almost nothing compared to 2.16 128 < mitch> calls* 129 < mclasen> do we have one of those gnome love pages to track the progress of building gnome with gseal ? 130 < mitch> yes, a pretty good one actually iirc 131 < mclasen> http://live.gnome.org/GnomeGoals/UseGseal 132 < aruiz> http://live.gnome.org/GnomeGoals/UseGseal 133 < aruiz> heh 134 < mitch> but but but 135 < mitch> we really need regular meeting like this one if we want to push this 136 < kalikianatoli> aruiz, bug 596083 137 < ebassi> I'd rather have the new geometry negotiation between 2.90 and 3.0, if it also means cleaning up GtkWidget, SizeGroup and Label 138 < mclasen> mitch: we can try to reestablish that 139 < mitch> mclasen: please, it's really a motivation push 140 * mclasen is still short on time, though 141 < mitch> me too :/ 142 < aruiz> kalikianatoli, I'd assume that patch is not upstream, is it? 143 * mclasen adds to the end of the agenda: schedule next meeting 144 < aruiz> mclasen, yeah :-) 145 < kalikianatoli> aruiz, Unfortunately not, but I'd hope to have it in the "quick" release 146 < aruiz> yeah 147 < aruiz> so we have a couple of reasons to have a quick 2.20 release 148 < mclasen> so, how quick are we talking about ? before the end of the year ? 149 < kalikianatoli> I have other deprecations as well =) 150 < mclasen> is that too late ? 151 < aruiz> mclasen, way to late imho 152 < mitch> aruiz: what? 153 < mitch> aruiz: do you have time to add all the accessors? 154 < mitch> let's rather aim for 6 instead of 12 months, to be more realistic 155 < ebassi> before the end of the year sounds good to me; leaves a month and a half for porting applications before 2.30 156 < mclasen> end of year seems realistically the best we can do 157 < jjardon> I have some bugs here to request some accesor and complete the patches to build with GSEAL enabled if anyone interested 158 < bratsche> I can add accessors if there is a known list of what needs to be added. Figuring out what's missing sounds like the part that would take a lot of time. 159 < mclasen> if we branch now, and establish the dual-branch setup 160 < ebassi> and eventually deprecate/add more stuff 161 < mitch> yes, the very best 162 < mclasen> and merge the features that are ready 163 < jjardon> I post them in http://live.gnome.org/GnomeGoals/UseGseal if you want 164 < mclasen> then we'll have a month or so left to accumulate accessors and deprecations 165 < mclasen> might be a good idea to target a few 'big' apps to be completely sealable as a goal 166 < bratsche> seb128 said we could queue up a build of everything on an Ubuntu build server with GSEAL set and collect the output, but I think that may not be as useful as it sounds. 167 < mclasen> like gimp, epiphany and one more... 168 < mitch> mclasen: i volunteer to do that for gimp 169 * mclasen figured 170 < jjardon> mclasen, I've already created patches for some of them 171 < kalikianatoli> should we have a meta bug? 172 < jjardon> see http://live.gnome.org/GnomeGoals/UseGseal for a complete list 173 < kalikianatoli> to track all these issues 174 < mclasen> jjardon: I know, thanks for doing that 175 < jjardon> kalikianatoli, https://bugzilla.gnome.org/show_bug.cgi?id=585391 176 < kalikianatoli> jjardon, I mean for 2.20 specifically 177 < kalikianatoli> ie also with features and deprecations 178 < mclasen> so, do we agree on this plan, as far as gtk 2.20 is concerned ? 179 < kalikianatoli> ++ from me 180 < bratsche> Do you have any idea how far away you want 2.20 to be? 181 < mclasen> and do we aim for a "2.80" to go along with it ? 182 < kalikianatoli> what is 2.80? 183 < aruiz> kalikianatoli, 2.90 for 2.20 184 < aruiz> :) 185 < mitch> mclasen: a clear nope from here, we should just try to make 2.20 what 2.18 was supposed to be 186 < kalikianatoli> and it would be experimental? 187 < mclasen> clearly 188 < mclasen> just a testrun for 2.90... 189 < mitch> yea 190 < kris> if we want to merge new features into 2.20, I would guess that that branch should be opened about nowish ... 191 < mclasen> right 192 < kris> if the intention is to release before the end of the year 193 < mitch> yeah 194 < mclasen> kris: rather, I'll do a 2-18 branch, so master can take 2.20 features 195 < kris> if its just accessors, it can wait for a bit i would say 196 < ebassi> sounds good to me 197 < kris> mclasen: yea, that's what I aimed at :) 198 < kris> I think we usually branch off other .2 anyway 199 < mclasen> I'll get that gtk-2-18 branch in place this week 200 < kris> s/opther/after/ 201 < bratsche> Anything more to discuss in the 2.90 bullet point, or should we move on? 202 < mclasen> yeah '0 csw regressions' is a nice branchpoint, anyway 203 < bratsche> Item #3 is GLib 2.22 branch and future 204 * mclasen scrolls back to agenda 205 < ebassi> 3. GLib 2.22 branch and future 206 < mitch> um, speaking of glib, we need class private data for a proper gtk 3.0 207 < ebassi> I guess: when we branch for 2.22, what features should land and will there be a GLib 3.0 in the future? 208 < kris> mitch: there's a patch for that 209 < kris> mitch: which I pre-reviewed 210 < kris> mitch: it completely makes sense to me 211 < mclasen> I will do a stable glib branch at the same time 212 < kris> mitch: the final word for that is with timj 213 < mitch> kris: yes i've seen it too, looks totally sane 214 < kris> mitch: oh yea and we even found a bug when i reviewed, hah 215 < kris> ;) 216 < mitch> heh 217 < ebassi> I'd like to propose a DOM based on GMarkup for 2.22 218 < mitch> oh and gmarkup needs my patch to deprecate the old vtable 219 < ebassi> GBookmark in GIO and GBookmarkFile would use it 220 < danw> you mean 2.24. 2.22 is now stable 221 < kalikianatoli> is there a bug for that? 222 < ebassi> yeah, 2.24 223 < mclasen> ebassi: where did that come from ? 224 < ebassi> mclasen: people have been asking for a DOM based on GMarkup; I know that desrt wrote one as well 225 < ebassi> mclasen: the format used by GBookmarkFile has support for external metadata sections that KDE has recently started using 226 < ebassi> if you load a file saved by KDE into GBookmarkFile and then save it back, you'll loose the KDE-specific metadata 227 * mclasen not really positive on the idea of including two xml parsers in glib 228 < ebassi> because a SAX-like parser does not really work 229 < ebassi> mclasen: it's not another parser; it's a DOM on top of GMarkup 230 < mitch> ebassi: does that work without gmarkup being a general parser (meaning it is capable of ignoring/externally handling unknown stuff)? 231 < mclasen> ebassi: oh, sorry, I somehow read 'parser' up there 232 < ebassi> mitch: yes 233 < mitch> ebassi: um, it doesn't even handle unknown entities 234 < ebassi> mitch: if you need a proper XML parser then you should be using a proper XML parser :-) 235 < ebassi> mitch: a DOM based on GMarkup would have the same limitations as GMarkup 236 < mitch> ebassi: well there is only this little bit missing to make it parse any valid xml :/ 237 < kalikianatoli> there is a patch for namespaces iirc, that would be nice to have 238 < ebassi> mitch: that's mostly orthogonal to having a DOM tree, though 239 < ebassi> kalikianatoli: there's a bug open about namespaces 240 < mitch> maybe, but with the same limitations 241 < ebassi> kalikianatoli: and GBookmarkFile implements a somewhat naive namespace resolution internally 242 * mclasen thinks namespaces are nicer to avoid than to have... 243 < mitch> good point :) 244 < ebassi> mclasen: true :-) 245 < kalikianatoli> ebassi, yeah, I know about the hack, but it's still just a hack :) 246 < mitch> but it doesn'T choke on namespaces, but it does choke on unknown entities 247 < mclasen> so, I don't think we are going to be able decide the 'gmarkup dom' idea today, should probably be developed on the list 248 < ebassi> kalikianatoli: doing it inside GMarkup would be better, but last time I tried it implied changing GMarkup's API 249 < mclasen> do we have other things that need to land in glib ? 250 < mclasen> I've already heard class private data 251 < danw> I am planning to add TLS (SSL) and proxy support to GSocket 252 < ebassi> mclasen: I'll bring it up on the list, and will try to get desrt's code as well 253 < mclasen> danw: how is that going to work out dependency-wise ? 254 < danw> they'll use extension points, so they won't drag any new dependencies into glib itself, but we'll need to put the gnutls-using and libproxy-using code somewhere. the libproxy stuff would make sense in gvfs since it would be unix-only, but the gnutls code might be used on windows too, so it fits there less well 255 < danw> (gvfs already depends on both gnutls and libproxy indirectly via libsoup) 256 < mclasen> danw: that sounds less scary than I thought... 257 < ebassi> about GIO and glib-next: how's GSetting? 258 < mclasen> danw: is that ready to ready to land ? 259 < danw> the glib-level tls API will be not-quite-fully featured; you'll be able to say "accepted certs from this trusted CA file" or "accept all certs", but if you want to pop up confusing "do you trust verisign" dialogs, your app will need to link to gnutls (or openssl or nss) directly so that it can parse the binary blog that gsocket gives it to validate 260 < danw> mclasen: no, not yet. before new year 261 < danw> mclasen: maybe *much* before that, but definitely by then 262 < danw> binary *blob*, not blog :) 263 < mclasen> just asking to figure out if it makes sense to try for glib-2.24 at the same time as gtk 2.20 264 < mclasen> I hope to pick up the gdbus idea that was floated on the list earlier 265 < mclasen> but I'll have to see how that fits in the schedules of davidz and alexl 266 < bratsche> So 2.24 would pull in dbus? Or is this after 2.24? 267 < mclasen> in what form it will pull in dbus is still an open question, I think 268 < bratsche> Fair enough. 269 < mclasen> and it might indeed be after 2.24 270 < mclasen> that seems more realistic 271 < bratsche> People at work have been asking about this and if I know anything yet, so was just curious. :) 272 * mclasen notes we have passed the 1 hour mark, time to speed up 273 < bratsche> Next item: GtkFileSystemModel branch status 274 < ebassi> that would be one of the candidate features for gtk+ 2.20 at this point 275 < mclasen> no update on that from me; I have run it for a few days without noticing any obvious problems 276 < bratsche> Company or federico have any comments? 277 < mclasen> I haven't looked at the code yet 278 < mclasen> federico has, and was also supposed to test it 279 < Company> can be merged fine :) 280 < mclasen> but, since we decided to branch _now_ and have a quick 2.20 it makes indeed more sense to merge it into 2.20 281 < Company> but then, i might be biased ;) 282 < aruiz> ebassi, sorry, was afk, gsettings is progressing quite good, ryan is going to make a release soon 283 < ebassi> aruiz: cool 284 < mclasen> the main problem with gsettings is not one of code, but of communication :-( 285 < mitch> i'd merge it right after the branch 286 < mclasen> it doesn't help to have desrt work in his closet for years on this... 287 < aruiz> mclasen, I can help with that 288 < Company> yeah, i think with 2.20, we should just merge the gtkfilesystem branch asap 289 < aruiz> mclasen, any particular course of action you would like him to take? 290 < Company> it's had quite some testing and code review from federico and me, so i suppose it's solid 291 < jjardon> I've created this page for Gsettings migration: http://live.gnome.org/GnomeGoals/GSettingsMigration 292 < jjardon> if helps 293 < mclasen> I agree, I will try to find federico and sort out the merging with him 294 < ebassi> jjardon: it helps, in part 295 < mclasen> I don't know that we can talk about migrating to gsettings yet, if we haven't even agreed to the design yet... 296 < aruiz> mclasen, I can ask him to come to the next meeting, or arrange one between the interested people just for that purpose 297 < mclasen> desrt seems to be marching on with his gvariant thing, despite early less-then-perfect reception to that... 298 < ebassi> aruiz: some of the collateral information is lacking; the schema format, how is going to support translations, how do we write a gconf-editor replacement, etc. 299 < mclasen> so I don't foresee a 'just merge it' in the near future... 300 < Company> mclasen: i'll volunteer to cleanly rebase the filesystemmodel branch onto master 301 < mclasen> Company: thanks 302 < federico> mclasen: I've been running it, not actually explicitly testing it, but it runs just fine (no crashes; I can open/save files, etc.) 303 < federico> I need to make some time to test it 304 < jjardon> bratsche, I've created a tracker bug for missing accesor functions: https://bugzilla.gnome.org/show_bug.cgi?id=597610 305 < bratsche> jjardon: Thanks dude.. can you CC me to it? 306 < bratsche> firstname.lastname@example.org 307 < federico> so, should we just merge it or rebase it? it's an old branch... 308 < jjardon> bratsche, sure 309 < mitch> jjardon: me too email@example.com 310 < aruiz> ebassi, I will send him those questions and send the answers to gtk-devel/ddl 311 < ebassi> aruiz: gtk-devel-list; d-d-l is just bad for that kind of discussion 312 < ebassi> aruiz: and thanks, that's much appreciated 313 < Company> federico: i'd like to rebase it (it only really touches one file that's not completely rewritten after all) 314 < aruiz> ebassi, you're welcome 315 < Company> federico: the incremental changes to GtkFileChooserDefault will certainly help bisecting regressions should there be any 316 < ebassi> should we move to: 5. patch reviewers 317 < ebassi> ? 318 < mclasen> yes, lets move on 319 < Company> can anyone pastebin the gobject-performance discussion for me? 320 < aruiz> Company, I will 321 < aruiz> Company, http://pastebin.valadoc.org/353.html 322 < mclasen> so, patch reviewers 323 < mclasen> the problem is most pressing in gobject, but far from limited to it 324 < kalikianatoli> I think a system with n reviewers needed to decide what commit-now from mclasen does today would be cool 325 < mitch> it's not that only mclasen can grant commit-now, the other trusted people are just lazy ;) 326 < mclasen> I mostly use that as a marker for myself really 327 < jjardon> bratsche, I've created a tracker bug for missing accesor functions: https://bugzilla.gnome.org/show_bug.cgi?id=597610 328 < bratsche> jjardon: Thanks dude.. can you CC me to it? 329 < bratsche> firstname.lastname@example.org 330 < federico> so, should we just merge it or rebase it? it's an old branch... 331 < jjardon> bratsche, sure 332 < mitch> jjardon: me too email@example.com 333 < aruiz> ebassi, I will send him those questions and send the answers to gtk-devel/ddl 334 < ebassi> aruiz: gtk-devel-list; d-d-l is just bad for that kind of discussion 335 < ebassi> aruiz: and thanks, that's much appreciated 336 < Company> federico: i'd like to rebase it (it only really touches one file that's not completely rewritten after all) 337 < aruiz> ebassi, you're welcome 338 < Company> federico: the incremental changes to GtkFileChooserDefault will certainly help bisecting regressions should there be any 339 < ebassi> should we move to: 5. patch reviewers 340 < ebassi> ? 341 < mclasen> yes, lets move on 342 < Company> can anyone pastebin the gobject-performance discussion for me? 343 < aruiz> Company, I will 344 < aruiz> Company, http://pastebin.valadoc.org/353.html 345 < mclasen> so, patch reviewers 346 < mclasen> the problem is most pressing in gobject, but far from limited to it 347 < kalikianatoli> I think a system with n reviewers needed to decide what commit-now from mclasen does today would be cool 348 < mitch> it's not that only mclasen can grant commit-now, the other trusted people are just lazy ;) 349 < mclasen> I mostly use that as a marker for myself really 350 < mclasen> I may try to come up with the beginning of such a list... 351 < kalikianatoli> btw jjardon do you mind me putting you in the 3.0/Tasks page as sealing person? 352 < kalikianatoli> you seem to be on it 353 * mclasen also thought that the bug cleanup lists or whatever it was called that some people sent to the list semi-regularly helped a bit in getting me to look at patches 354 < ebassi> mclasen: some automated summary for patches in need of review 355 < jjardon> kalikianatoli, go ahead ;) 356 < ebassi> mclasen: would be a good start 357 * mclasen needs to go in a few minutes 358 < Company> :/ 359 < mclasen> before I drop off, lets get the next meeting scheduled 360 < Company> i'd like to have picked up the gobject-performance stuff again 361 < kalikianatoli> So is there any chance we can establish "reviewers"? 362 < ebassi> two weeks from now? 363 < mclasen> 2 weeks from now ? 364 < mitch> heh 365 < ebassi> kalikianatoli: I think it'll require some discussion on the list 366 < Company> but i guess it can wait till the next meeting 367 < kalikianatoli> ebassi, Okay 368 < ebassi> kalikianatoli: or off-list but with a concrete proposal for a review team 369 < mclasen> ebassi: will you invite ? 370 < ebassi> mclasen: sure 371 < mclasen> cool, thanks 372 < Company> i just don't agree with alex's notion that the other stuff isn't important 373 < Company> in fact, the critical parts for gstreamer aren't merged yet, only the boring stuff 374 < mclasen> I think he also said 'far from trivial' and 'needs much more review' ? 375 < ebassi> Company: s/important/as urgent/ 376 < mclasen> so it seems very appropriate to delay those parts to the unstable branch 377 < Company> ebassi: i think the gstreamer guys were pondering rewriting some stuff to accomodate for the slowness, so i'd describe it as rather urgent 378 < Company> but yeah, i wouldn't wanna push it into stable 379 < mclasen> it won't be forgotten, definitively on the agenda for early 2.23 380 * mclasen about to drop off 381 < Company> that's great then 382 < Company> let's talk about it in 2 weeks 383 < mclasen> thanks everybody for coming, and ebassi for inviting, and legwork 384 < ebassi> thanks everyone
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.