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> bratsche@gnome.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 mitch@gimp.org
 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> bratsche@gnome.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 mitch@gimp.org
 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