* mclasen looks at the time
< ebassi> oh, right
< ebassi> wow, already 30 minutes?
 * ebassi pokes
< bratsche> ouch
< jdahlin> go go go
 * jdahlin summons rhult
 * mclasen looks for the agenda
< ebassi> http://live.gnome.org/GTK+/Meetings - agenda for tonight
< ebassi> 1. 2.14 release (mclasen)
< ebassi> 2. 3.0 plannin
< ebassi> g
< ebassi> 3. miscellanea
< mclasen> ok, do we have enough people ?
< bratsche> I forget, was something decided about the version number?  Was there going to be a 2.90 or something before 3.0?
< bratsche> All the insanity of the angry people about OpenGL 3.0 made me think of that yesterday. :)
< mclasen> lets talk about 2.14 first
< mitch> i noticed the gtkhsv i just made fully public has not a single property
< mitch> dunno how relevant that is
< mclasen> didn't I mention that earlier
< mitch> it's easy enough to add if wanted
< mclasen> I meant to say that it could do with some love...
< mitch> mclasen: i didn't see it
< mitch> it could also need an auto-size mode where it follows its allocation
< mitch> like size = -1 or so, without any new api
< mclasen> thats a nice segway into my question: is there any api that we absolutely have to get into 2.14 still ?
< mclasen> I kinda declared 2.13.6 to be api frozen when I released it...
< mitch> somebody should check all new files and see if they have proper class padding etc.
< mclasen> but we already bent that declaration with gtkhsv and the gtk_status_icon_get_gicon change...
< 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.
< mclasen> the one commit-ready api-adding patch that I remember seeing is the invisible char change
< 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
< kalikiana> mclasen: I'd like 408244 to go in, it's only a style property, accepted but not yet committed
< mclasen> pbor_: can I convince you to work on a patch for that ?
< pbor_> mclasen: yes, but I need suggestion on the api to use
< mitch> mclasen: that IM request sounds like "if i stick a needle in here, it magically starts to work"
< mitch> err pbor_ 
< mclasen> mitch: yeah, its not really nice to have to use needles
< mitch> we need somebody who can claim he understands how the Im stuff *really* works :)
 * mclasen claims some understanding, minus xim
< kalikiana> is that person also riding a pink pony?
< mitch> yes
< 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
< mclasen> pbor_: do you have a list of use cases where you currently have to set that flag ?
< mitch> i'm sure there will be quite a few places where sealing itches, and they all need a proper solution
< mitch> perhaps wait with these solutions?
< mclasen> it begs the question how we are going to advertise the sealing in 2.14
< pbor_> mclasen: for sure the original bug that triggered that workaround: http://bugzilla.gnome.org/show_bug.cgi?id=154039
< mclasen> is that just an opt-in feature at this point ?
< kalikiana> I understood sealing 2.14 is not meant to be complete
< mitch> mclasen: yes it's opt in, and we should advise in big fat letters that everybody tries it and reports problems
< kalikiana> More like the big part part, for trying out, something like that
< 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...
< mitch> mclasen: i agree
< mclasen> mitch: do we have some language for that in the README already ?
< pbor_> mclasen: ok
< mitch> mclasen: nope, and i don't think README is enough, we should also have a visible section on "best practices" on gtk.org
< mclasen> pbor_: I'll have a look at possible apis in that area, anyway. there was some more things that other people wanted
< mitch> mclasen: e.g. "how to get your code clean and ready for 3.0"
< mclasen> mitch: right, can you work on both ? 
< mclasen> :-)
< mitch> i will give the website task to martyn ;)
< pbor_> mclasen: thanks... maybe we should have a tracker bug for this issues that need fixing with seal
< mitch> i can do the README
< mclasen> pbor_: there is a wiki page, I believe
< jdahlin> A wiki page would probably be the best, so people without commit access can contribute
< mclasen> moving beyond 2.14 api
< mclasen> are there any blocker-worthy regressions or other severe bugs to keep an eye on ?
< mitch> to infinity and beyond!
< mclasen> I know at least the file chooser resizing regression
< mclasen> federico was looking at that earlier today
< timj> ebassi: can we make ' visible section on "best practices" on gtk.org' an ACTION item?
< mitch> and there is an evil filechooser bug i reported to carlos
< mitch> as in really evil
< mitch> remote files stopped to work
< mitch> damn my memory :/
< mitch> will sort that tomorrow
< ebassi> timj: sure
< mclasen> mitch: carlos had a set of patches for remote file handling
< ebassi> timj: already added
< mclasen> mitch: thats in bugzilla
< mclasen> almost ready to go
< mclasen> I don't know if that adresses your issue, though
< mitch> mclasen: great :) i was offline a few weeks, didn't notice
< mclasen> let me find the bug
< mitch> mclasen: i pointed him, so i guess it does
< mclasen> I don't know what our schedule called for in terms of release date of 2.14
< mclasen> did we say end of august ?
< mitch> ebassi: can you make "mitch to check if carlos patches fix gimp" an action item too?
< mclasen> http://bugzilla.gnome.org/show_bug.cgi?id=545980 is the bug
< ebassi> mitch: heh, sure
< jdahlin> I haven't gotten a clear answer to this: are we going to break ABI/API in glib for 3.0 too?
< mitch> jdahlin: i would say yes, but can't we finish the 2.14 stuff first ;)
< jdahlin> oh sorry
 * jdahlin waits
< mitch> mclasen: i think we did (end of aug)
< pbor_> what about gio? are there show stoppers for 2.16?
< mclasen> ok, that gives us 2 more weeks of bugfixing, and I should probably do another devel snapshot before then...
 * pbor_ is undecided about committing or not the patch that switched gedit from gnome-vfs to gio...
< mitch> maybe have an ACTION itam to look over all new classes again (padding, etc)
< mclasen> pbor_: for gio, I really want tbzateks file monitoring fixes in
< garnacho> oh, btw, could bug #83935 get in 2.14? or is it too rushed in?
< garnacho> sorry if I'm late
< pbor_> garnacho: mclasen already mentioned that one
< ebassi> mitch: okay, ACTION: review newly added classes
< mclasen> garnacho: the patch looks certainly ready, but we kinda closed the door on api additions at this point...
< garnacho> pbor_: oh, didn't notice :)
< mclasen> garnacho: of course, if everyone absolutely wants see it in, I could be convinced...
< garnacho> aha, ok :)
< mclasen> pbor_: do you have any specific gio bugs in mind that would keep you from switching /
< mclasen> ?
< pbor_> mclasen: not really, I am just worried about stability (but more in gvfs)
< pbor_> we alreday found different bugs
< pbor_> there are also missing api, but no show stoppers in that regard
< jdahlin> pbor_, I'd say do the same as nautilus did, release with known bugs
< mclasen> if there is anything sufficiently serious, let me know. I can ask tomas to look at potential blockers like that...
 * pbor_ is quite pissed at backends simply returning NOT_SUPPORTED for many core apis
< pbor_> it defeats the point of using an interface if I have to code the fallback all the time
< mclasen> pbor_: if you have concrete examples that cause you problems, please file bugs
< pbor_> mclasen: yeah, we filed a few already
< mclasen> ok. anything else on 2.14 ? I'll probably do a 2.13.7 next week...
< mclasen> if not, we should probably move to 3.0...
< bolsh> Can I butt in for a second first?
< bolsh> Hi all :)
< mclasen> sure
< mitch> mclasen: tml just raised the issue of gio/gvfs on win32, is that a blocker for 2.14 too?
< bolsh> I've talked to a few of you already about this, but before ye start I wanted to spread this a bit wider
< mitch> tml: sorry to suspend the lurking ;)
< tml> mitch: do you mean "gvfs" the GVfs, or "gvfs" the "gvfs" module? I hate the ambiguity;)
< mitch> what is the difference?
< 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
< 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...
< mitch> bolsh: can that wait until we're done with 2.14?
< mitch> 2.14 as in the agenda point
< bolsh> mitch: Sure - I thought ye'd moved on
< mitch> of we are at that already
< mitch> sorry sorry :)
< ebassi> mitch: we *were* done, apparently :-)
< mitch> i shut up :P
< mclasen> tml: did you resolve the one vfs at a time vs. multiple vfs' confusion ? 
< 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
< 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
< mclasen> tml: I'm certainly not the most qualified person to review a win32 vfs implementation and how it hooks into gio....
< mitch> bolsh: there will be a "best practices" section on gtk.org about how everybody can get their code ready
< bolsh> And to have that meeting at the start of the 3.0 planning cycle (ie. soon)
< mclasen> tml: sounds ok to me
< 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...
< mclasen> tml: alex is rumoured to come back in September, possibly
< 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
< bratsche> heh.. rumors.
< mclasen> bolsh: I have doubts in the possibility of a 'meeting of all interested parties'
< 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
< mitch> bolsh: i think we can safely scratch the issue about deprecated interfaces, people should just get their code cleaned
< bolsh> And second, a face to face meeting - perhaps at the Summit in October - with people like Eclipse, VMWare, Mozilla, OOo, Adobe, IBM, ...
< mitch> bolsh: summit is a bad idea, since quite some people don't travel to the us
< bolsh> The board are organising an advisory board call focussed on GTK+ in September (a few of you have been invited, I think)
< 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
< mclasen> bosh: gah, I totally forgot to respond to that mail
< mclasen> bolsh: I'll do so soon
< 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
< mitch> bolsh: it would be nice to hear what points people would see to be addresses in such guiding material
< mitch> addressed
< bolsh> I will mail to gtk-devel-list about this.
< bolsh> mitch: Right now, people don't know what the right forum is
< mitch> it's gtk-devel-list imho
< bolsh> I don't think this meeting needs to have everyone, but it definitely needs a critical mass
< mclasen> mitch: 'what's the right forum to discuss my gtk3 angst ?' would be the first question in the faq 
< bolsh> I think it'll be much more valuable than a mailing list
< mitch> mclasen: good point
< 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
< mclasen> bolsh: isn't it getting pretty late to organize such a meeting at the summit, anyway ?
< bolsh> No - 2 months is plenty time
< bolsh> Piggybacking on the summit is the reason why
< bolsh> I was assuming that most of the GTK+ maintainers would be there anyway
< mclasen> anyway, I don't see how such a meeting is going to be very productive
< bolsh> I was not counting on mitch, but I thought that tim & kris would come
< bolsh> Seems they're not keen either
< mitch> bolsh: tim and kris *definitely* wont travel to the us
< bolsh> OK - perhaps it's better to start with the conf call the board are organising, and see what falls out of that
< mclasen> yeah, seems any meeting on us soil is going to be difficult
< 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
< mclasen> which makes things interesting, considering I have a hard time finding any time for travel that is farther than Boston...
< mclasen> bolsh: can you try to define in what way that 'forum' you envision would be more direct than bugzilla, mailing lists or irc ?
< bolsh> mailing lists is what I was thinking of
< 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 :-)
< mclasen> bolsh: is your main concern that corporate users of GTK+ don't like to use these contact points ?
< bolsh> The impression people I had is that gtk-users was high-traffic low signal, and gtk-devel was for maintainers only
< bolsh> So these guys didn't know where to go, or who to talk to
< mclasen> 'maintainers only' is a very wrong impression
< bolsh> Perhaps
< mclasen> something to work on, I guess
< bolsh> It's an impression a lot of people seem to have :)
< rhult> bolsh, filing bugs against the gtk website on what to improve might be a good idea
< bolsh> I guess you need to have a "how to get in contact with us" type page
< mclasen> can we put "GTK+3 on the website" down as an action item ?
< 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
< 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?"
< bolsh> Anyway - I don't want to swamp your meeting, I'll be off
< bolsh> Thanks for hearing me out!
< mclasen> its worth pointing out that the gtk3 discussion at least brings out some willingness to experiment in people
< mclasen> like finally pushing for the completion of the introspection work
< ebassi> mclasen: done
< mclasen> or the RI work that david did
< jdahlin> So let me repeat: are we going to break ABI/API in glib for 3.0 too?
< mclasen> do you have some abi/api breaking feature request in mind ?
< jdahlin> No, I'm actually on the conservative side of this, I'm worried about the effects of GStreamer & c/o
< jdahlin> Can't we wait and break glib/gobject at another time?
< mclasen> jdahlin: there is not much to seal in glib, and the amount of deprecated interfaces is much smaller
< 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?
< mclasen> the one thing that comes to mind is the relocation-prone enum abi
< 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
< mitch> and free/open projects' developers usually hang out on the mailing lists anyway afaics
< mitch> eek i was disconnected
< mitch> bolsh: did you get this
< 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
< mitch> and free/open projects' developers usually hang out on the mailing lists anyway afaics
< bolsh> mitch: Yup
< bolsh> Twice, even :)
< 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
< kalikiana> But that alone isn't too convincing
< mitch> hm ok :)
< bolsh> Well, do you know the guy working for IBM who does all their SWT stuff?
< bolsh> They use lots of deprecated stuff, because they have a list of distros they support that's quite old
< jdahlin> kalikiana, no, there are many users of glib outside of gtk+
< bolsh> I think they still work with GTK+ 2.6 or 2.8
< 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
< jdahlin> kalikiana, they are not forced to break because gtk+ is broken
< jdahlin> mitch, that argumenet applies to gtk+, but not so much to glib
< 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
< mclasen> in glib, we also have the curious situation that we carry around some stuff that nobody ever uses
< mclasen> like GRelation
< kalikiana> jdahlin: Which is exactly what I meant: *glib* users would be forced to cleanup, too
< mitch> jdahlin: i checked my entire /usr/lib and /*/bin, and it is not *that* much
< jdahlin> ebassi, I'm not sure how gobject-introspection fits in glib yet, I think it's up to mclasen & timj to decide
< mitch> jdahlin: and my system is carried around since 2000 or so, so a lot of cruft that's even irrelevent
< ebassi> mclasen: GRelation would need fixing, actually. it would be a good API if only it worked for anything that's not an int :-)
< 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+
< 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
< mitch> jdahlin: i agree, but still they exist, and imho we should take the opportinuty
< rhult> there is a cost in breaking and if the gains don't justify the cost, then we shouldn't break...
< mitch> rhult: absolutely, i guess timj can best come up with good reasons for gobject changes for instance
< mclasen> so, action item for everybody until next time: figure out reasons to break or not break glib at the same time as gtk
< jdahlin> mitch, agreed, I'm just saying it's a separate discussion which we haven't talked about yet
< rhult> mitch, I have asked him and he can't give any good reasons (at least not anything concrete)
< mitch> for me, getting rid of deprecated would be reason enough ;)
< kalikiana> beware the cleaner :P
< mitch> yes! :)
< mclasen> so, to get this discussion back to more concrete things
< 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...
< mclasen> so that people feel informed, warm and fuzzy
< jdahlin> there should also be a list of things which we cannot do without gsealing
< jdahlin> as in features, I haven't seen such as list before
< jdahlin> for example the RI work david has been doing is not really possible with sealing public fields AFAICT
< mitch> jdahlin: refactoring, do we need anything else?
< 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
< herzi> mitch: agreed
< kalikiana> herzi: Still features in that narrow-minded way is what we need to convince different sorts of people :)
< jdahlin> mitch, yes, refactoring is not a very good selling arguments to the companies bolsh mentioned
< jdahlin> everybody in here obviously understands the need of refactoring, but I think you'll have a hard(er) time convincing Adobe & c/o
< 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
< mitch> even federico should be able to understand that
< mitch> errrrrr
< mitch> not federico ;)
< jdahlin> mitch, we're sending them a bad message by doing the refactoring without giving a concrete feature list
< timj> rhult: the reasons for breaking glib ABI are the same as for breaking gtk ABI
< herzi> jdahlin: what's bad about "we still care to get this beast maintained and avoid bit-rotting"?
< ebassi> even refactoring is a plan - as long as we sell it to the ISV as needed
< timj> rhult: and gtk clearly has the larger user base, so breaking glib ABI simply isn't as much of an issue
< ebassi> so we need to come up with a list of stuff that makes it clear that it's needed
< timj> it certainly makes sense to seal glib fields as well
< mitch> jdahlin: i don't see what's bad about this message. we want to make sure their invested money is safe long term
< ebassi> take opengl 3.0 for instance, as bratsche mentioned earlier
< timj> but we can look into that after we actually have 3.0 branches created
< jdahlin> herzi, the miguel kind of person won't buy it
< ebassi> 3.0 was "a clean up, with deprecations and api removal"
< ebassi> and when it wasn't delivered, people got really angry
< jdahlin> mitch, it's a technical argument, not a marketing/business argument 
< mclasen> did we agree to dub it 2.90, btw ?
< kalikiana> I think so?
< rhult> yea we did last meeting, I think?
< 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
< ebassi> mclasen: I thought we did agree on that
< timj> and the gscanner, so we can have a 64bit safe variant.
< mclasen> ok, good, just making sure
< mitch> and gmarkupparser badly needs more
< jdahlin> mclasen, what are we going to call the development branch leading up to 2.90.x? 2.89.x?
< timj> next would be breaking XML parser ABI to cover XML entities generically, etc, etc
< kalikiana> timj: late translations == lazy translations?
< timj> kalikiana: yes
< kalikiana> Ah, cool
< ebassi> jdahlin: I'd call 2.90.x a development branch, actually
< mclasen> jdahlin: depends on whether we expect to do snapshots off the branch before doing 2.90
< jdahlin> ebassi, are we not going to a stable release based upon which is lower than 3.0?
< ebassi> maybe with soft API/ABI guarantees?
< mclasen> which I guess we should
< mitch> soft?
< ebassi> "API-not-really-set-in-stone" soft
< mitch> ah
< ebassi> so that we have leeway for a 3.0 with stable API
 * mclasen has to run out in 10 minutes
< ebassi> jdahlin: I'd expect a 2.90 == 2.16 + G_SEAL_ENABLE
< mitch> ebassi: i'd expect all struct member to be gone for good
< ebassi> jdahlin: then 2.91 is the first development cycle for what will be 3.0
< mclasen> and all deprecated api gone
< mitch> ebassi: as in really sealed
< ebassi> mitch, mclasen: sure
< ebassi> point being, though, that 2.90 is really 2.16 in terms of API - so no need to cycle up to that
< ebassi> s/API/features/
< jdahlin> ebassi, I think it would be easier to do 2.89.x development snapshots and 2.90.x when we're done
< mitch> yes, 2.90 will be simply be 2.16 minus cruft
< mclasen> ok, I think I'll try to draft some notes on these plans and send a draft around
< mclasen> gotta run now, sorry
< ebassi> jdahlin: I don't think we need to do snapshots of that - as in: the first snapshot should be 2.90 already
< mclasen> later
< ebassi> ACTION: have a plan for 3.0 out with the 2.14 release (mclasen)
< ebassi> well, he's gone, so I can put the action down with mclasen name :-)
< ebassi> other points under the "3.0 plans" one, or any miscellaneous point?
< tbf> jdahlin: is that leecher kind of person, which miguel represents, really important?
< tbf> (expect that far too many take miguel serious)
< ebassi> if no other point is being raised, we can adjourn the meeting
< ebassi> minutes and log will be up as soon as possible, as usual
< ebassi> see you in two weeks