1  * mclasen looks at the time
   2 < ebassi> oh, right
   3 < ebassi> wow, already 30 minutes?
   4  * ebassi pokes
   5 < bratsche> ouch
   6 < jdahlin> go go go
   7  * jdahlin summons rhult
   8  * mclasen looks for the agenda
   9 < ebassi> http://live.gnome.org/GTK+/Meetings - agenda for tonight
  10 < ebassi> 1. 2.14 release (mclasen)
  11 < ebassi> 2. 3.0 plannin
  12 < ebassi> g
  13 < ebassi> 3. miscellanea
  14 < mclasen> ok, do we have enough people ?
  15 < bratsche> I forget, was something decided about the version number?  Was there going to be a 2.90 or something before 3.0?
  16 < bratsche> All the insanity of the angry people about OpenGL 3.0 made me think of that yesterday. :)
  17 < mclasen> lets talk about 2.14 first
  18 < mitch> i noticed the gtkhsv i just made fully public has not a single property
  19 < mitch> dunno how relevant that is
  20 < mclasen> didn't I mention that earlier
  21 < mitch> it's easy enough to add if wanted
  22 < mclasen> I meant to say that it could do with some love...
  23 < mitch> mclasen: i didn't see it
  24 < mitch> it could also need an auto-size mode where it follows its allocation
  25 < mitch> like size = -1 or so, without any new api
  26 < mclasen> thats a nice segway into my question: is there any api that we absolutely have to get into 2.14 still ?
  27 < mclasen> I kinda declared 2.13.6 to be api frozen when I released it...
  28 < mitch> somebody should check all new files and see if they have proper class padding etc.
  29 < mclasen> but we already bent that declaration with gtkhsv and the gtk_status_icon_get_gicon change...
  30 < bratsche> Sorry, I have to save iconentry for the next series.. I got a really big assignment at work that's taking all my time now.
  31 < mclasen> the one commit-ready api-adding patch that I remember seeing is the invisible char change
  32 < pbor_> not a major thing, but if we want a sealed 2.14 to be usable by gedit, sourceview and many others programs specializing the textview, we need  http://bugzilla.gnome.org/show_bug.cgi?id=163251
  33 < kalikiana> mclasen: I'd like 408244 to go in, it's only a style property, accepted but not yet committed
  34 < mclasen> pbor_: can I convince you to work on a patch for that ?
  35 < pbor_> mclasen: yes, but I need suggestion on the api to use
  36 < mitch> mclasen: that IM request sounds like "if i stick a needle in here, it magically starts to work"
  37 < mitch> err pbor_ 
  38 < mclasen> mitch: yeah, its not really nice to have to use needles
  39 < mitch> we need somebody who can claim he understands how the Im stuff *really* works :)
  40  * mclasen claims some understanding, minus xim
  41 < kalikiana> is that person also riding a pink pony?
  42 < mitch> yes
  43 < pbor_> mitch: well, I am not saying it's nice, but I am saying it's needed... if that's get sealed we are screwed
  44 < mclasen> pbor_: do you have a list of use cases where you currently have to set that flag ?
  45 < mitch> i'm sure there will be quite a few places where sealing itches, and they all need a proper solution
  46 < mitch> perhaps wait with these solutions?
  47 < mclasen> it begs the question how we are going to advertise the sealing in 2.14
  48 < pbor_> mclasen: for sure the original bug that triggered that workaround: http://bugzilla.gnome.org/show_bug.cgi?id=154039
  49 < mclasen> is that just an opt-in feature at this point ?
  50 < kalikiana> I understood sealing 2.14 is not meant to be complete
  51 < mitch> mclasen: yes it's opt in, and we should advise in big fat letters that everybody tries it and reports problems
  52 < kalikiana> More like the big part part, for trying out, something like that
  53 < mclasen> in that case, I think the need-im-reset is probably not a release blocker, just one of the problems that people should report...
  54 < mitch> mclasen: i agree
  55 < mclasen> mitch: do we have some language for that in the README already ?
  56 < pbor_> mclasen: ok
  57 < mitch> mclasen: nope, and i don't think README is enough, we should also have a visible section on "best practices" on gtk.org
  58 < mclasen> pbor_: I'll have a look at possible apis in that area, anyway. there was some more things that other people wanted
  59 < mitch> mclasen: e.g. "how to get your code clean and ready for 3.0"
  60 < mclasen> mitch: right, can you work on both ? 
  61 < mclasen> :-)
  62 < mitch> i will give the website task to martyn ;)
  63 < pbor_> mclasen: thanks... maybe we should have a tracker bug for this issues that need fixing with seal
  64 < mitch> i can do the README
  65 < mclasen> pbor_: there is a wiki page, I believe
  66 < jdahlin> A wiki page would probably be the best, so people without commit access can contribute
  67 < mclasen> moving beyond 2.14 api
  68 < mclasen> are there any blocker-worthy regressions or other severe bugs to keep an eye on ?
  69 < mitch> to infinity and beyond!
  70 < mclasen> I know at least the file chooser resizing regression
  71 < mclasen> federico was looking at that earlier today
  72 < timj> ebassi: can we make ' visible section on "best practices" on gtk.org' an ACTION item?
  73 < mitch> and there is an evil filechooser bug i reported to carlos
  74 < mitch> as in really evil
  75 < mitch> remote files stopped to work
  76 < mitch> damn my memory :/
  77 < mitch> will sort that tomorrow
  78 < ebassi> timj: sure
  79 < mclasen> mitch: carlos had a set of patches for remote file handling
  80 < ebassi> timj: already added
  81 < mclasen> mitch: thats in bugzilla
  82 < mclasen> almost ready to go
  83 < mclasen> I don't know if that adresses your issue, though
  84 < mitch> mclasen: great :) i was offline a few weeks, didn't notice
  85 < mclasen> let me find the bug
  86 < mitch> mclasen: i pointed him, so i guess it does
  87 < mclasen> I don't know what our schedule called for in terms of release date of 2.14
  88 < mclasen> did we say end of august ?
  89 < mitch> ebassi: can you make "mitch to check if carlos patches fix gimp" an action item too?
  90 < mclasen> http://bugzilla.gnome.org/show_bug.cgi?id=545980 is the bug
  91 < ebassi> mitch: heh, sure
  92 < jdahlin> I haven't gotten a clear answer to this: are we going to break ABI/API in glib for 3.0 too?
  93 < mitch> jdahlin: i would say yes, but can't we finish the 2.14 stuff first ;)
  94 < jdahlin> oh sorry
  95  * jdahlin waits
  96 < mitch> mclasen: i think we did (end of aug)
  97 < pbor_> what about gio? are there show stoppers for 2.16?
  98 < mclasen> ok, that gives us 2 more weeks of bugfixing, and I should probably do another devel snapshot before then...
  99  * pbor_ is undecided about committing or not the patch that switched gedit from gnome-vfs to gio...
 100 < mitch> maybe have an ACTION itam to look over all new classes again (padding, etc)
 101 < mclasen> pbor_: for gio, I really want tbzateks file monitoring fixes in
 102 < garnacho> oh, btw, could bug #83935 get in 2.14? or is it too rushed in?
 103 < garnacho> sorry if I'm late
 104 < pbor_> garnacho: mclasen already mentioned that one
 105 < ebassi> mitch: okay, ACTION: review newly added classes
 106 < mclasen> garnacho: the patch looks certainly ready, but we kinda closed the door on api additions at this point...
 107 < garnacho> pbor_: oh, didn't notice :)
 108 < mclasen> garnacho: of course, if everyone absolutely wants see it in, I could be convinced...
 109 < garnacho> aha, ok :)
 110 < mclasen> pbor_: do you have any specific gio bugs in mind that would keep you from switching /
 111 < mclasen> ?
 112 < pbor_> mclasen: not really, I am just worried about stability (but more in gvfs)
 113 < pbor_> we alreday found different bugs
 114 < pbor_> there are also missing api, but no show stoppers in that regard
 115 < jdahlin> pbor_, I'd say do the same as nautilus did, release with known bugs
 116 < mclasen> if there is anything sufficiently serious, let me know. I can ask tomas to look at potential blockers like that...
 117  * pbor_ is quite pissed at backends simply returning NOT_SUPPORTED for many core apis
 118 < pbor_> it defeats the point of using an interface if I have to code the fallback all the time
 119 < mclasen> pbor_: if you have concrete examples that cause you problems, please file bugs
 120 < pbor_> mclasen: yeah, we filed a few already
 121 < mclasen> ok. anything else on 2.14 ? I'll probably do a 2.13.7 next week...
 122 < mclasen> if not, we should probably move to 3.0...
 123 < bolsh> Can I butt in for a second first?
 124 < bolsh> Hi all :)
 125 < mclasen> sure
 126 < mitch> mclasen: tml just raised the issue of gio/gvfs on win32, is that a blocker for 2.14 too?
 127 < bolsh> I've talked to a few of you already about this, but before ye start I wanted to spread this a bit wider
 128 < mitch> tml: sorry to suspend the lurking ;)
 129 < tml> mitch: do you mean "gvfs" the GVfs, or "gvfs" the "gvfs" module? I hate the ambiguity;)
 130 < mitch> what is the difference?
 131 < tml> anyway, I mentioned it to mclasen yesterday, I have a GVfs implementation for http: support on Windows that would be linked into libgio. i.e. no relation to gvfs the module
 132 < bolsh> Since GUADEC & OSCON, I've been talking to a lot of people who are GTK+ users - typically companies - and they're a bit nervous about the GTK+ 3 announcement, wondering what it means, wondering if there's going to be any consultation on a roadmap or publication of a roadmap...
 133 < mitch> bolsh: can that wait until we're done with 2.14?
 134 < mitch> 2.14 as in the agenda point
 135 < bolsh> mitch: Sure - I thought ye'd moved on
 136 < mitch> of we are at that already
 137 < mitch> sorry sorry :)
 138 < ebassi> mitch: we *were* done, apparently :-)
 139 < mitch> i shut up :P
 140 < mclasen> tml: did you resolve the one vfs at a time vs. multiple vfs' confusion ? 
 141 < tml> mclasen: yes, I check what schemes the "wrapped" GVfs (i.e. GLocalVfs) supports, claim to support those too, and forward those URIs to the wrapped GVfs
 142 < bolsh> So I thought it might be a good idea to get the main GTK+ users (ISVs and free software projects depending on GTK+) together with the maintainers to have that consultation
 143 < mclasen> tml: I'm certainly not the most qualified person to review a win32 vfs implementation and how it hooks into gio....
 144 < mitch> bolsh: there will be a "best practices" section on gtk.org about how everybody can get their code ready
 145 < bolsh> And to have that meeting at the start of the 3.0 planning cycle (ie. soon)
 146 < mclasen> tml: sounds ok to me
 147 < tml> mclasen: yeah, apparently alexl is on leave, and he is hte only one who really knows how GVfs, extension points, etc works? at least I was told so in #nautilus...
 148 < mclasen> tml: alex is rumoured to come back in September, possibly
 149 < bolsh> The questions I think people would be interested in are what deprecated interfaces people are using, and why, what they're not using, what they like about GTK+, what they're missing, and of course it's the opportunity for the GTK+ maintainers to reassure application developers that 3.0 is not going to be a painful transition
 150 < bratsche> heh.. rumors.
 151 < mclasen> bolsh: I have doubts in the possibility of a 'meeting of all interested parties'
 152 < bolsh> I think there would be 2 things that would be useful: First, a forum (either an existing mailing list like gtk-devel-list or gtk-users-list) where ISDs can sign up & participate in the roadmap discussion
 153 < mitch> bolsh: i think we can safely scratch the issue about deprecated interfaces, people should just get their code cleaned
 154 < bolsh> And second, a face to face meeting - perhaps at the Summit in October - with people like Eclipse, VMWare, Mozilla, OOo, Adobe, IBM, ...
 155 < mitch> bolsh: summit is a bad idea, since quite some people don't travel to the us
 156 < bolsh> The board are organising an advisory board call focussed on GTK+ in September (a few of you have been invited, I think)
 157 < mclasen> bolsh: really, gtk-devel-list is the best place to discuss. But we certainly need to put out more guiding material in other places, such as www.gtk.org
 158 < mclasen> bosh: gah, I totally forgot to respond to that mail
 159 < mclasen> bolsh: I'll do so soon
 160 < bolsh> mitch: It fits the calendar, I think if you wait until 2009 for a better opportunity, you'll either be presenting a ready-made plan (no consultation) or you'll be delaying planning too long - both bad
 161 < mitch> bolsh: it would be nice to hear what points people would see to be addresses in such guiding material
 162 < mitch> addressed
 163 < bolsh> I will mail to gtk-devel-list about this.
 164 < bolsh> mitch: Right now, people don't know what the right forum is
 165 < mitch> it's gtk-devel-list imho
 166 < bolsh> I don't think this meeting needs to have everyone, but it definitely needs a critical mass
 167 < mclasen> mitch: 'what's the right forum to discuss my gtk3 angst ?' would be the first question in the faq 
 168 < bolsh> I think it'll be much more valuable than a mailing list
 169 < mitch> mclasen: good point
 170 < bolsh> OK - I won't hold up your meeting any longer. The core point I wanted to make is that you guys really need to be talking to the major applications using the toolkit to know what's good & bad (and, as mitch said, what they expect from you) - and it might be an idea to do that before you finalise GTK+ 3.0 plans
 171 < mclasen> bolsh: isn't it getting pretty late to organize such a meeting at the summit, anyway ?
 172 < bolsh> No - 2 months is plenty time
 173 < bolsh> Piggybacking on the summit is the reason why
 174 < bolsh> I was assuming that most of the GTK+ maintainers would be there anyway
 175 < mclasen> anyway, I don't see how such a meeting is going to be very productive
 176 < bolsh> I was not counting on mitch, but I thought that tim & kris would come
 177 < bolsh> Seems they're not keen either
 178 < mitch> bolsh: tim and kris *definitely* wont travel to the us
 179 < bolsh> OK - perhaps it's better to start with the conf call the board are organising, and see what falls out of that
 180 < mclasen> yeah, seems any meeting on us soil is going to be difficult
 181 < bolsh> I definitely see the need for a forum where GTK+ users are in direct contact with maintainers - a face to face meeting seems like a great way to kick something like that off, but perhaps it's not necessary
 182 < mclasen> which makes things interesting, considering I have a hard time finding any time for travel that is farther than Boston...
 183 < mclasen> bolsh: can you try to define in what way that 'forum' you envision would be more direct than bugzilla, mailing lists or irc ?
 184 < bolsh> mailing lists is what I was thinking of
 185 < ebassi> I'd really love to go to boston, but I'm already going twice to the US in less than 2 weeks, I'm afraid homeland security will lock me in the third time :-)
 186 < mclasen> bolsh: is your main concern that corporate users of GTK+ don't like to use these contact points ?
 187 < bolsh> The impression people I had is that gtk-users was high-traffic low signal, and gtk-devel was for maintainers only
 188 < bolsh> So these guys didn't know where to go, or who to talk to
 189 < mclasen> 'maintainers only' is a very wrong impression
 190 < bolsh> Perhaps
 191 < mclasen> something to work on, I guess
 192 < bolsh> It's an impression a lot of people seem to have :)
 193 < rhult> bolsh, filing bugs against the gtk website on what to improve might be a good idea
 194 < bolsh> I guess you need to have a "how to get in contact with us" type page
 195 < mclasen> can we put "GTK+3 on the website" down as an action item ?
 196 < bolsh> It might also be a good idea to "officially" launch a roadmap consultation period for features that might go in for 2.16 or post-3.0
 197 < bolsh> The question I heard several times was "we hear that some features are hard or impossible to do without breaking API/ABI - what features are they?"
 198 < bolsh> Anyway - I don't want to swamp your meeting, I'll be off
 199 < bolsh> Thanks for hearing me out!
 200 < mclasen> its worth pointing out that the gtk3 discussion at least brings out some willingness to experiment in people
 201 < mclasen> like finally pushing for the completion of the introspection work
 202 < ebassi> mclasen: done
 203 < mclasen> or the RI work that david did
 204 < jdahlin> So let me repeat: are we going to break ABI/API in glib for 3.0 too?
 205 < mclasen> do you have some abi/api breaking feature request in mind ?
 206 < jdahlin> No, I'm actually on the conservative side of this, I'm worried about the effects of GStreamer & c/o
 207 < jdahlin> Can't we wait and break glib/gobject at another time?
 208 < mclasen> jdahlin: there is not much to seal in glib, and the amount of deprecated interfaces is much smaller
 209 < jdahlin> mclasen, that makes my argument stronger, isn't it preferable to wait until we need some specific features which can't be developed without a sealed api?
 210 < mclasen> the one thing that comes to mind is the relocation-prone enum abi
 211 < mitch> bolsh: i really don't think the communication skills of these ISVs are really that bad, and if they are, a properly visible web page to check the most important points would certainly help
 212 < mitch> and free/open projects' developers usually hang out on the mailing lists anyway afaics
 213 < mitch> eek i was disconnected
 214 < mitch> bolsh: did you get this
 215 < mitch> bolsh: i really don't think the communication skills of these ISVs are really that bad, and if they are, a properly visible web page to check the most important points would certainly help
 216 < mitch> and free/open projects' developers usually hang out on the mailing lists anyway afaics
 217 < bolsh> mitch: Yup
 218 < bolsh> Twice, even :)
 219 < kalikiana> A pro breaking glib argument could be - users of glib are forced to break, too, and have a motivation to seal/ clean up as well
 220 < kalikiana> But that alone isn't too convincing
 221 < mitch> hm ok :)
 222 < bolsh> Well, do you know the guy working for IBM who does all their SWT stuff?
 223 < bolsh> They use lots of deprecated stuff, because they have a list of distros they support that's quite old
 224 < jdahlin> kalikiana, no, there are many users of glib outside of gtk+
 225 < bolsh> I think they still work with GTK+ 2.6 or 2.8
 226 < mitch> getting rid of the deprecated stuff is worth it already, and if we have a break in the entire stack we should do it right
 227 < jdahlin> kalikiana, they are not forced to break because gtk+ is broken
 228 < jdahlin> mitch, that argumenet applies to gtk+, but not so much to glib
 229 < ebassi> jdahlin: if gobject-introspection would require api changes then it would be a reason to break API/ABI for 3.0 - but a clean up alone isn't really worth it
 230 < mclasen> in glib, we also have the curious situation that we carry around some stuff that nobody ever uses
 231 < mclasen> like GRelation
 232 < kalikiana> jdahlin: Which is exactly what I meant: *glib* users would be forced to cleanup, too
 233 < mitch> jdahlin: i checked my entire /usr/lib and /*/bin, and it is not *that* much
 234 < jdahlin> ebassi, I'm not sure how gobject-introspection fits in glib yet, I think it's up to mclasen & timj to decide
 235 < mitch> jdahlin: and my system is carried around since 2000 or so, so a lot of cruft that's even irrelevent
 236 < ebassi> mclasen: GRelation would need fixing, actually. it would be a good API if only it worked for anything that's not an int :-)
 237 < jdahlin> mitch, my point is mainly that the reasons for doing the api/abi break in glib are much weaker than the ones in gtk+
 238 < jdahlin> we shouldn't just do the break in api because we do it in gtk+ per se, there should be good reasons for doing it
 239 < mitch> jdahlin: i agree, but still they exist, and imho we should take the opportinuty
 240 < rhult> there is a cost in breaking and if the gains don't justify the cost, then we shouldn't break...
 241 < mitch> rhult: absolutely, i guess timj can best come up with good reasons for gobject changes for instance
 242 < mclasen> so, action item for everybody until next time: figure out reasons to break or not break glib at the same time as gtk
 243 < jdahlin> mitch, agreed, I'm just saying it's a separate discussion which we haven't talked about yet
 244 < rhult> mitch, I have asked him and he can't give any good reasons (at least not anything concrete)
 245 < mitch> for me, getting rid of deprecated would be reason enough ;)
 246 < kalikiana> beware the cleaner :P
 247 < mitch> yes! :)
 248 < mclasen> so, to get this discussion back to more concrete things
 249 < mclasen> following what bolsh said, I think we need to put out a plan with the next steps toward 3.0 before the 2.14 release...
 250 < mclasen> so that people feel informed, warm and fuzzy
 251 < jdahlin> there should also be a list of things which we cannot do without gsealing
 252 < jdahlin> as in features, I haven't seen such as list before
 253 < jdahlin> for example the RI work david has been doing is not really possible with sealing public fields AFAICT
 254 < mitch> jdahlin: refactoring, do we need anything else?
 255 < herzi> jdahlin: I really think "features" is really narrow-minded; being able to replace GList for GHashTable in a struct, is not a feature, but worth sealing
 256 < herzi> mitch: agreed
 257 < kalikiana> herzi: Still features in that narrow-minded way is what we need to convince different sorts of people :)
 258 < jdahlin> mitch, yes, refactoring is not a very good selling arguments to the companies bolsh mentioned
 259 < jdahlin> everybody in here obviously understands the need of refactoring, but I think you'll have a hard(er) time convincing Adobe & c/o
 260 < mitch> jdahlin: but it's a good argument that they want to build on something future proof, and a project that blocks on refactoring is doomed to die and take lots of money with it
 261 < mitch> even federico should be able to understand that
 262 < mitch> errrrrr
 263 < mitch> not federico ;)
 264 < jdahlin> mitch, we're sending them a bad message by doing the refactoring without giving a concrete feature list
 265 < timj> rhult: the reasons for breaking glib ABI are the same as for breaking gtk ABI
 266 < herzi> jdahlin: what's bad about "we still care to get this beast maintained and avoid bit-rotting"?
 267 < ebassi> even refactoring is a plan - as long as we sell it to the ISV as needed
 268 < timj> rhult: and gtk clearly has the larger user base, so breaking glib ABI simply isn't as much of an issue
 269 < ebassi> so we need to come up with a list of stuff that makes it clear that it's needed
 270 < timj> it certainly makes sense to seal glib fields as well
 271 < mitch> jdahlin: i don't see what's bad about this message. we want to make sure their invested money is safe long term
 272 < ebassi> take opengl 3.0 for instance, as bratsche mentioned earlier
 273 < timj> but we can look into that after we actually have 3.0 branches created
 274 < jdahlin> herzi, the miguel kind of person won't buy it
 275 < ebassi> 3.0 was "a clean up, with deprecations and api removal"
 276 < ebassi> and when it wasn't delivered, people got really angry
 277 < jdahlin> mitch, it's a technical argument, not a marketing/business argument 
 278 < mclasen> did we agree to dub it 2.90, btw ?
 279 < kalikiana> I think so?
 280 < rhult> yea we did last meeting, I think?
 281 < timj> rhult: as for concrete things, i'd probably start with sealing gparamspec to implement some long standing feature requests from mclasen about late translations
 282 < ebassi> mclasen: I thought we did agree on that
 283 < timj> and the gscanner, so we can have a 64bit safe variant.
 284 < mclasen> ok, good, just making sure
 285 < mitch> and gmarkupparser badly needs more
 286 < jdahlin> mclasen, what are we going to call the development branch leading up to 2.90.x? 2.89.x?
 287 < timj> next would be breaking XML parser ABI to cover XML entities generically, etc, etc
 288 < kalikiana> timj: late translations == lazy translations?
 289 < timj> kalikiana: yes
 290 < kalikiana> Ah, cool
 291 < ebassi> jdahlin: I'd call 2.90.x a development branch, actually
 292 < mclasen> jdahlin: depends on whether we expect to do snapshots off the branch before doing 2.90
 293 < jdahlin> ebassi, are we not going to a stable release based upon which is lower than 3.0?
 294 < ebassi> maybe with soft API/ABI guarantees?
 295 < mclasen> which I guess we should
 296 < mitch> soft?
 297 < ebassi> "API-not-really-set-in-stone" soft
 298 < mitch> ah
 299 < ebassi> so that we have leeway for a 3.0 with stable API
 300  * mclasen has to run out in 10 minutes
 301 < ebassi> jdahlin: I'd expect a 2.90 == 2.16 + G_SEAL_ENABLE
 302 < mitch> ebassi: i'd expect all struct member to be gone for good
 303 < ebassi> jdahlin: then 2.91 is the first development cycle for what will be 3.0
 304 < mclasen> and all deprecated api gone
 305 < mitch> ebassi: as in really sealed
 306 < ebassi> mitch, mclasen: sure
 307 < ebassi> point being, though, that 2.90 is really 2.16 in terms of API - so no need to cycle up to that
 308 < ebassi> s/API/features/
 309 < jdahlin> ebassi, I think it would be easier to do 2.89.x development snapshots and 2.90.x when we're done
 310 < mitch> yes, 2.90 will be simply be 2.16 minus cruft
 311 < mclasen> ok, I think I'll try to draft some notes on these plans and send a draft around
 312 < mclasen> gotta run now, sorry
 313 < ebassi> jdahlin: I don't think we need to do snapshots of that - as in: the first snapshot should be 2.90 already
 314 < mclasen> later
 315 < ebassi> ACTION: have a plan for 3.0 out with the 2.14 release (mclasen)
 316 < ebassi> well, he's gone, so I can put the action down with mclasen name :-)
 317 < ebassi> other points under the "3.0 plans" one, or any miscellaneous point?
 318 < tbf> jdahlin: is that leecher kind of person, which miguel represents, really important?
 319 < tbf> (expect that far too many take miguel serious)
 320 < ebassi> if no other point is being raised, we can adjourn the meeting
 321 < ebassi> minutes and log will be up as soon as possible, as usual
 322 < ebassi> see you in two weeks