* mclasen takes the initiative...
< mclasen> 1. Status of Gtk+-2.14 release, API freeze
< bratsche_> But I'll just mention it today in case anyone else wants to also look before it goes in.
< mclasen> I don't know the details of what has been discussed at guadec (no notes...)
< mclasen> but I do have a small list of things I consider release blockers
< mclasen> so, what was discussed at guadec wrt to 2.14 ?
< ebassi> mclasen: 2.14 by august/september like last year, as far as I remember
< ebassi> mclasen: I guess a little bit earlier to avoid release-team panick :-)
< mclasen> ok
< mitch_> it was too hot to remember ;)
< mclasen> I'm on the release team now, so I can counteract any panic before it boils up...
< rhult> mitch had some small api addition he wanted to get in
< kris> mitch wanted adjustment API in
< mitch_> rhult: yes i wish there were minutes, i don't recall what it was :(
< mitch_> right
< kris> no further new features
< mitch_> to seal them
< kris> API freeze next realease
< mitch_> kris: thanks
< kris> the notes are close to  being done
< mclasen> are there any leftover accessors that we need from the seal merge ?
< kris> didnt manage to get them written last week because i was totally destroyed
< kris> and i am still destroyed
< kris> and it was destroyed before guadec even started
< mclasen> talking about gseal, someone should look into teaching gtk-doc something about it...
< rhult> mclasen, there are accessors missing still but they don't have to go in 
< mclasen> as things stand right now, it bitches pretty heavily 
< mclasen> the one outstanding api addition I am still considering is support for icons with emblems in gio
< mclasen> one sec
< tml> I guess adding an implementation of a GVfs for ftp:/http:/https:/ URIs on Windows to gio doesn't could as an API addition (as no new public API is added)
< mitch_> i'd like to deprecate some tiny bits of gtktypeutils but that can also be done after the release
< tml> (as that is something I have started hacking on... will probably not be good enough to commit before the feature freeze)
< ebassi> I only have the single bulk addition function for GtkRecentManager - but I can live without it if it looks too late in the game
 * behdad reads...
< behdad> there's a mild dependency from the new gtk+ to new pango, which has one to new cairo
< behdad> so, we need to get cairo out, pango out, then gtk+ out
< behdad> which I'm happy to make sure happens by end of august, or early september
< behdad> (we have cairo summit at last week of august, so an early september release makes more sense)
< mclasen> behdad: what dependency is that ?
< bratsche_> Depending on when the release date is, I might have icon entry ready.  But probably I won't, I may have volunteered to work on the deprecated library. :)
< behdad> mclasen: for show_text_glyphs stuff to be useful, gdkpango should be modified
< behdad> mclasen: we can skip that, then gtk+ will not benefit from the changes for a full year or so
< mitch_> bratsche_: we don't need that lib before 3.0, do we?
< mclasen> no, if you get releases out, depending on them should be fine
< behdad> well, gdkpango is not interesting re show_text_glyphs though.  got to check if gtkprinting needs any change
< bratsche_> mitch_: Oh yeah, that's true.
< behdad> mclasen: sure.  just about the timing
< behdad> mclasen: oh, or do you mean in point releases?
< mclasen> you might want to warn the release team ahead that we'll have to bump the cairo dep
< behdad> right
< mitch_> (which will introduce a pixman dep if i'm not mistaken?)
 * behdad does that
< behdad> mitch_: right
< kalikiana> bratsche, So you're planning to finish iconentry in time for 2.14?
 * mclasen thinks new widgets should probably wait for 2.15 at this point
< mitch_> bratsche: will it just be Gtkentry api?
< mitch_> i don't know why we need new api for that
< bratsche_> kalikiana: Depends on when the release date is still I guess, and how busy I am at work.
< mitch_> the icon might also be nice to have for spinbuttons
< bratsche_> mitch_: Yeah, I need to move all the stuff over to GtkEntry (right now it's a separate widget)
< mitch_> err s/new api/new widgets/
< mitch_> bratsche_: nice :)
< bratsche_> But yeah, I was intending to move all this into GtkEntry once the features are "done".
< kalikiana> I think the main parts left are DND and possibly animation
< kalikiana> Apart from that it's coming up nicely
< bratsche_> Yeah, the DND stuff looked potentially trickier than I thought.. but let me look at it again.
< mclasen> I think the recent comment about theming was right, though
< bratsche_> We can chat about it more after the meeting, I don't mean to hold things up here right now.
< mclasen> ok, in terms of non-api release blockers,
< mclasen> I am waiting for tbzatek to deliver fixes and tests for the inotify code in gio
< mclasen> which is pretty broken, currently
< mclasen> and I want to see the filechooser resizing regression fixed
< mclasen> anything else that belongs on a blocker list ?
< bratsche_> If anyone else wants to check out the current patch for #56070 (mclasen already said he will), I'd really like to get this committed before the release.
< bratsche_> I think I've gotten this patch as far as I can get it, and it seems nobody else is going to work on it so I'd like to get it committed unless there are any problems with it.
< mclasen> that adds a tiny bit of new api too, btw
< bratsche_> (I mean, any problems with it that outweigh the problems it solves)
< mitch_> mclasen: the filechooser is also completely broken for anything but local files, we discovered that today
< mclasen> mitch_: that sounds blocker-worthy...
< mitch_> yes :(
< mclasen> any specifics in bugzilla somewhere ?
 * tml remembers one outstanding bug with patch that I would like reviewed, a moment...
< mitch_> mclasen: no i'll bug carlos about it, dunno if he has fixed it already or is at it
< mclasen> thanks
< tml> #536714 . not sure if the patch applies cleanly any more, though
< timj> can we move on in the agenda?
< mclasen> it looks to me like we should shoot for an api-frozen release in ~2 weeks and then maybe one more release before 2.14, as needed
< mclasen> does that sound reasonable ?
< timj> mclasen: yes, totally
< mitch_> yea
< mclasen> ok
< mclasen> 2. Feedback on the Guadec meeting, 2.16 schedule.
 * mclasen sits back
< timj> yeah, i was hoping to have the minutes on the list at this point but kris unfortunately didn't make it
< timj> so we'll have to do this in email i guess
< mclasen> ok, so should we postpone until we have minutes
< mclasen> 3. Sense feedback on "calling" the ABI-breaking 3.0 version 2.99.0
< timj> about 2.16, we pretty much agreed to do 2.16 around next guadec again (ideally before that, as usual)
< mclasen> probably makes more sense once we have a clearer picture of what we're trying to land in 2.16
< rhult> there was also a list of features that could be targetted for 2.16 but as usual, that depends on what people will actually work on anyway
< mclasen> rhult: where was that list ? in the guadec meeting notes ?
< rhult> yea, in the meeting
< mclasen> ok, so we should revisit the 2.16 schedule once the minutes are out, maybe
< rhult> things like finishing the offscreen rendering, extended layout, ...
< rhult> yes, makes sense
< timj> on, 3.0 vs. 2.99.0. the berlin hackfest proposal suggests we do an ABI incompatible rerelease of 2.16 with all deprecated code removed and structures made private. after that we add features. the original idea was to call this 3.0 and then land features in 3.1/3.2 immediately after that (with 3.0 being only 1-2 months after 2.16). it hasbeen suggested during guadec and on the planet, that we call the cleanup version 2.99.0 instead (ABI incompati
< timj> ble still), add features in 2.99.x and release 3.0 with features instead.
< mclasen> I'm pretty much in the 2.90 camp, too
< bratsche_> If you're going to go with a <3.0 number, I kind of like the idea of doing 2.90 instead of 2.99.
< mitch_> my opinion is that it *so* doesn't matter, it's just names
< timj> technically, the numbers don't really mean anything, so either scheme should be technically fine. so i wanted to sense feedback on this.
< mclasen> its all about messaging
< mitch_> and if people need new features to eat the 3.0 they should just have them and be silent
< timj> mclasen: very true
< tbf> 2.90 keeps space for 2.91, 2.92... if they should be needed
< tbf> 2.100 looks strange
< ebassi> I agree with mitch and timj, but since numbers are a marketing thing, I'm in the 2.9x camp as well
< rhult> same here, 2.9x camp for me
< bratsche_> tbf: Yeah, that's kind of what I thought.
< timj> ok good. 
< mclasen> tbf: this is all about strange number things, like 2.30 = 3.0 ...
< ebassi> heh
< mitch_> to us it's just a name, so we shouldn't care
< tbf> mclasen: yup
< tbf> mclasen: at least he 2.30 = 3.0 thing is kind of funny
< tbf> whereas the need for calling 3.0 "2.9x" is just sad
< ebassi> so, the consensus is pretty much: 2.9x is ABI incompatible in preparation for the API breakage of 3.0, which also introduces new features?
< gmorten> don't even think of using "consensus" for that
< ebassi> gmorten: consensus among the team, I mean
< tbf> gmorten?
< mclasen> gmorten: that depends on whose votes you count...
< mitch_> he meant term
< timj> another aspect about this (touches a bit on 5. feature roadmap for 3.0), it has become pretty clear that the majority wants to see features in 3.0 one way or the other. so we might just take the opportunity and branch for 3.0 ASAP and use 2.90 as version number in the branch for a start, e.g. in 2 weeks when 2.14 is API frozen and we focus on stabelizing anyway. 
< mitch_> errn no i misread :)
< gmorten> mclasen: the beauty of "concensus" is that you don't count.
< ebassi> gmorten: you get to maintain 2.x anyway ;-)
< gmorten> just one pissed off guy -- me -- and it won't be "concensus"
< ebassi> timj: I agree - we should branch for 3.x as soon as possible
< mpt> consensus != unanimity
< timj> that way, we could be hacking on ABI incompatible features in parallel, which might give us a much better idea in a year if an ABI is really required, how soon, and what the benefits would be
< bratsche_> Yeah, consensus means "general agreement"
< mclasen> timj: the downside is that it would mean fixing bugs in three branches
< mitch_> ebassi: as soon as possible?
< mclasen> but I guess thats ok
< mclasen> was there any talk about doing 3.x work in git at guadec ?
< ebassi> mitch_: well, as soon as the work on features
< ebassi> mitch_: *starts
< mitch_> ebassi: ah yea i thought you meant work in a branch while we still do 2.16
< timj> mclasen: yes, true. the interest in 3.0 suggests it could be worth it though, and for a start, i think we could look into appointing a team/person responsible for keeping track of merging trunk fixes into the 3.0 branches, so the people usually working on stabelization aren't negatively impacted by this
< mitch_> eek
< timj> mclasen: no, we didn't talk git/bzr at all in the gtk-devel meeting
< mitch_> well, i guess i'm the only one who hates branches then ;)
< bratsche_> Why?
< mitch_> because they utterly confuse me and the rebasing is evil
< mitch_> ignore me :)
< timj> mitch_: you're not the only one hating SVN branches for sure. but keeping the branch in SVN means all people otherwise working on glib/gtk could also work on 3.0 stuff, and SVN has community visibility. so i think it'd be a better sign if 3.0 work was kept in SVN than individual git branches. (one can use git-svn)
< bratsche_> I'm working on writing a blog post about how we use bzr at Medsphere, and how it's hooked into our bug tracker and automated testing.  With all that stuff hooked together it's totally awesome, even you'll love it mitch_ ;)
< timj> sorry, one can of course *also* use bzr-svn ;)
< mitch_> bratsche_: yea go ahead i already hate git ;)
 * bratsche_ started using git-svn for GTK hacking, but we use bzr at work.
< mclasen> mitch_: branches are fine as long as you never merge or rebase
< mitch_> as said, please ignore me :)
< mitch_> mclasen: haha :) well said
< timj> anyway this is side tracking, we can have (d)VCS wars at other times.
< timj> feedback on branching for 3 soon in SVN?
< mclasen> fwiw, I think 'branch early' is a good strategy
< bratsche_> +1
< timj> great
< mclasen> just to keep stuff moving
< mclasen> and avoid the 'scattered in a thousand git trees' syndrome that X suffers frmo
< timj> # 4 What is the prospect of creating a spin-off libgtk3deprecated that's not maintained by the Gtk+ core team.
< mclasen> just to make sure I fully understand this idea
< timj> part of the feedback we got on 3.0 was the suggestion to move deprecated widgets into an extra lib in the future. i think this is a great idea, and i heared bratsche allmost vlounteer for setting up the initial version.
< mclasen> the plan is that gtk 2.x and 3 will be parallel installable ?
< timj> mclasen: yes
< mclasen> and 3 will drop all deprecated api from 2.x
< timj> libgtk3deprecated (or graveyard ;) would depend on gtk3
< mitch_> that would mean first "undeprecating" the deprecated widget completely, e.g. not using GtkType or GtkArg
< timj> mclasen: well, 2.90 will at least
< mitch_> which could be done for 2.16 and be good for building gtk with DISABLE_DEPRECATED and get rid of GTK_COMPILATION
< timj> mitch_: i think there are other reasons for GTK_COMPILATION as well
< mitch_> timj: very few, but yes
< timj> mitch_: and, i guess one could investigate if GtkArg could reasonably be moved into libgtk3deprecated
< mitch_> timj: why should it be, that would be unreasonable
< mclasen> how will libgtk3deprecated work for individual deprecated functions, as opposed to wholly deprecated widgets ?
< mitch_> mclasen: i think they would not be part of it
< mclasen> and what will happen to deprecated stuff in e.g. glib ?
< timj> mclasen: i think we could only make this a best-effort undertaking. i.e. move whole widgets there, that should generally be doable, and move functions there that can easily be reimplemented on top of stable non-deprecated API
< mclasen> so there will be no guarantee that you can move your 2.x app to 3 + graveyard  without porting ?
< mitch_> exactly
< rhult> I think we cover most cases of people not having time to port to newer alternatives by just moving gtkclist/tree and gtkitemfactory there...
< mitch_> and optionmenu
< ebassi> and the file selector
 * ebassi runs
< mitch_> eek
< timj> mclasen: glib is a bit up in limbo still. we have investigation of glib sealing on the 3.0 tasks list, and should evaluate how/if a libglib3deprecation will really make sense. i guess that'll also depend on the state of the 3.0 glib branch once we get to make more solid decisions on doing ABI incompat 3.0 releases in about a year 
< mclasen> timj: I need to look at the 3.x task list again 
< mclasen> I may have some additions...
< timj> mclasen: that'd be much appreciated: http://live.gnome.org/GTK%2B/3.0/Tasks
< mitch_> i have some too actually
< mclasen> so, the findings seem to be going the 2.9x route and branch early
< mclasen> should we switch to the last agenda item ?
< mclasen> Feature roadmap for 3.x
< timj> yeah
< timj> #5 Feature roadmap for 3.x.
< timj> there was lots of feedback along the lines "what's after 3.0, what features will we get and what's the time frame for those"
< timj> so far, focus has been on how to enable 3.0 development at all, we have the basic ideas hashed out so far (2.90, early branching), so we can/should start on collecting wishlist items next, figure possible contributors and maybe even tentative time frames for the implementation.
< timj> one way this could be done is e.g. to start a wiki page on a tentative 3.0 roadmap (table listing features, people signing up, much like the existing tasks pages) and discuss this on the mailing list. ideally someone will sign up for making sure discussion findings do also make their way onto the wiki page
< timj> further suggestions welcome
< bratsche_> There's already some discussion of new style/theme stuff, maybe we can link over to that from this new page.
< mclasen> one question I have: do we cut off development of 2.x-compatible features in 2.16 ?
< mclasen> or do we continue to pour things into 2.16 and only do the 'radical' features in the 3.0 branch ?
< behdad> any way to call 3.x developmental and release 4.0 with new features?
< tbf> behdad: why waste 3.x?
< timj> mclasen: i think it doesn't make too much sense to do real feature development post-2.16. before that, i.e. 2.15 is something we need to figure out as a team i think.
< timj> tbf: agree
< ebassi> mclasen: it depends on how do you rate 'radical' features
< behdad> tbf: to actually devel on top of it and break again and again as needed..
< timj> behdad: that can be 2.9y.x instead
< behdad> yeah, different naming only
< mclasen> ebassi: the stuff that people _want_ to break abi for... I mean, there better be something in that category, right ?
< mclasen> ebassi: like, say, 'scenegraph', to throw out a buzzword
< tbf> or "window-less" widgets
< ebassi> mclasen: that would probably belong in the 3.x-radical camp
< mclasen> whereas I would be very comfortable adding session-mgmt client api in 2.x...
< ebassi> mclasen: more than the 2.x-radical one
< ebassi> I'd rate session-managment as 2.15 feature, if it can land in that timeframe
 * mclasen doesn't  have any more input on 3.x features right now
< mitch_> going window-less was very good imho
< mitch_> subwindow, even
< timj> ok, anyone volounteering to steer a 3.0 roadmap at this point? ;)
 * timj thinks "at least try asking..."
 * mclasen volunteers for 2.x
< timj> well, i guess i can setup a 3.x-features page and then ask for a moderator again when announcing this page on the mailing list