1  * mclasen takes the initiative...
   2 < mclasen> 1. Status of Gtk+-2.14 release, API freeze
   3 < bratsche_> But I'll just mention it today in case anyone else wants to also look before it goes in.
   4 < mclasen> I don't know the details of what has been discussed at guadec (no notes...)
   5 < mclasen> but I do have a small list of things I consider release blockers
   6 < mclasen> so, what was discussed at guadec wrt to 2.14 ?
   7 < ebassi> mclasen: 2.14 by august/september like last year, as far as I remember
   8 < ebassi> mclasen: I guess a little bit earlier to avoid release-team panick :-)
   9 < mclasen> ok
  10 < mitch_> it was too hot to remember ;)
  11 < mclasen> I'm on the release team now, so I can counteract any panic before it boils up...
  12 < rhult> mitch had some small api addition he wanted to get in
  13 < kris> mitch wanted adjustment API in
  14 < mitch_> rhult: yes i wish there were minutes, i don't recall what it was :(
  15 < mitch_> right
  16 < kris> no further new features
  17 < mitch_> to seal them
  18 < kris> API freeze next realease
  19 < mitch_> kris: thanks
  20 < kris> the notes are close to  being done
  21 < mclasen> are there any leftover accessors that we need from the seal merge ?
  22 < kris> didnt manage to get them written last week because i was totally destroyed
  23 < kris> and i am still destroyed
  24 < kris> and it was destroyed before guadec even started
  25 < mclasen> talking about gseal, someone should look into teaching gtk-doc something about it...
  26 < rhult> mclasen, there are accessors missing still but they don't have to go in 
  27 < mclasen> as things stand right now, it bitches pretty heavily 
  28 < mclasen> the one outstanding api addition I am still considering is support for icons with emblems in gio
  29 < mclasen> one sec
  30 < 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)
  31 < mitch_> i'd like to deprecate some tiny bits of gtktypeutils but that can also be done after the release
  32 < tml> (as that is something I have started hacking on... will probably not be good enough to commit before the feature freeze)
  33 < 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
  34  * behdad reads...
  35 < behdad> there's a mild dependency from the new gtk+ to new pango, which has one to new cairo
  36 < behdad> so, we need to get cairo out, pango out, then gtk+ out
  37 < behdad> which I'm happy to make sure happens by end of august, or early september
  38 < behdad> (we have cairo summit at last week of august, so an early september release makes more sense)
  39 < mclasen> behdad: what dependency is that ?
  40 < 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. :)
  41 < behdad> mclasen: for show_text_glyphs stuff to be useful, gdkpango should be modified
  42 < behdad> mclasen: we can skip that, then gtk+ will not benefit from the changes for a full year or so
  43 < mitch_> bratsche_: we don't need that lib before 3.0, do we?
  44 < mclasen> no, if you get releases out, depending on them should be fine
  45 < behdad> well, gdkpango is not interesting re show_text_glyphs though.  got to check if gtkprinting needs any change
  46 < bratsche_> mitch_: Oh yeah, that's true.
  47 < behdad> mclasen: sure.  just about the timing
  48 < behdad> mclasen: oh, or do you mean in point releases?
  49 < mclasen> you might want to warn the release team ahead that we'll have to bump the cairo dep
  50 < behdad> right
  51 < mitch_> (which will introduce a pixman dep if i'm not mistaken?)
  52  * behdad does that
  53 < behdad> mitch_: right
  54 < kalikiana> bratsche, So you're planning to finish iconentry in time for 2.14?
  55  * mclasen thinks new widgets should probably wait for 2.15 at this point
  56 < mitch_> bratsche: will it just be Gtkentry api?
  57 < mitch_> i don't know why we need new api for that
  58 < bratsche_> kalikiana: Depends on when the release date is still I guess, and how busy I am at work.
  59 < mitch_> the icon might also be nice to have for spinbuttons
  60 < bratsche_> mitch_: Yeah, I need to move all the stuff over to GtkEntry (right now it's a separate widget)
  61 < mitch_> err s/new api/new widgets/
  62 < mitch_> bratsche_: nice :)
  63 < bratsche_> But yeah, I was intending to move all this into GtkEntry once the features are "done".
  64 < kalikiana> I think the main parts left are DND and possibly animation
  65 < kalikiana> Apart from that it's coming up nicely
  66 < bratsche_> Yeah, the DND stuff looked potentially trickier than I thought.. but let me look at it again.
  67 < mclasen> I think the recent comment about theming was right, though
  68 < bratsche_> We can chat about it more after the meeting, I don't mean to hold things up here right now.
  69 < mclasen> ok, in terms of non-api release blockers,
  70 < mclasen> I am waiting for tbzatek to deliver fixes and tests for the inotify code in gio
  71 < mclasen> which is pretty broken, currently
  72 < mclasen> and I want to see the filechooser resizing regression fixed
  73 < mclasen> anything else that belongs on a blocker list ?
  74 < 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.
  75 < 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.
  76 < mclasen> that adds a tiny bit of new api too, btw
  77 < bratsche_> (I mean, any problems with it that outweigh the problems it solves)
  78 < mitch_> mclasen: the filechooser is also completely broken for anything but local files, we discovered that today
  79 < mclasen> mitch_: that sounds blocker-worthy...
  80 < mitch_> yes :(
  81 < mclasen> any specifics in bugzilla somewhere ?
  82  * tml remembers one outstanding bug with patch that I would like reviewed, a moment...
  83 < mitch_> mclasen: no i'll bug carlos about it, dunno if he has fixed it already or is at it
  84 < mclasen> thanks
  85 < tml> #536714 . not sure if the patch applies cleanly any more, though
  86 < timj> can we move on in the agenda?
  87 < 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
  88 < mclasen> does that sound reasonable ?
  89 < timj> mclasen: yes, totally
  90 < mitch_> yea
  91 < mclasen> ok
  92 < mclasen> 2. Feedback on the Guadec meeting, 2.16 schedule.
  93  * mclasen sits back
  94 < timj> yeah, i was hoping to have the minutes on the list at this point but kris unfortunately didn't make it
  95 < timj> so we'll have to do this in email i guess
  96 < mclasen> ok, so should we postpone until we have minutes
  97 < mclasen> 3. Sense feedback on "calling" the ABI-breaking 3.0 version 2.99.0
  98 < timj> about 2.16, we pretty much agreed to do 2.16 around next guadec again (ideally before that, as usual)
  99 < mclasen> probably makes more sense once we have a clearer picture of what we're trying to land in 2.16
 100 < 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
 101 < mclasen> rhult: where was that list ? in the guadec meeting notes ?
 102 < rhult> yea, in the meeting
 103 < mclasen> ok, so we should revisit the 2.16 schedule once the minutes are out, maybe
 104 < rhult> things like finishing the offscreen rendering, extended layout, ...
 105 < rhult> yes, makes sense
 106 < 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
 107 < timj> ble still), add features in 2.99.x and release 3.0 with features instead.
 108 < mclasen> I'm pretty much in the 2.90 camp, too
 109 < 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.
 110 < mitch_> my opinion is that it *so* doesn't matter, it's just names
 111 < timj> technically, the numbers don't really mean anything, so either scheme should be technically fine. so i wanted to sense feedback on this.
 112 < mclasen> its all about messaging
 113 < mitch_> and if people need new features to eat the 3.0 they should just have them and be silent
 114 < timj> mclasen: very true
 115 < tbf> 2.90 keeps space for 2.91, 2.92... if they should be needed
 116 < tbf> 2.100 looks strange
 117 < ebassi> I agree with mitch and timj, but since numbers are a marketing thing, I'm in the 2.9x camp as well
 118 < rhult> same here, 2.9x camp for me
 119 < bratsche_> tbf: Yeah, that's kind of what I thought.
 120 < timj> ok good. 
 121 < mclasen> tbf: this is all about strange number things, like 2.30 = 3.0 ...
 122 < ebassi> heh
 123 < mitch_> to us it's just a name, so we shouldn't care
 124 < tbf> mclasen: yup
 125 < tbf> mclasen: at least he 2.30 = 3.0 thing is kind of funny
 126 < tbf> whereas the need for calling 3.0 "2.9x" is just sad
 127 < 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?
 128 < gmorten> don't even think of using "consensus" for that
 129 < ebassi> gmorten: consensus among the team, I mean
 130 < tbf> gmorten?
 131 < mclasen> gmorten: that depends on whose votes you count...
 132 < mitch_> he meant term
 133 < 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. 
 134 < mitch_> errn no i misread :)
 135 < gmorten> mclasen: the beauty of "concensus" is that you don't count.
 136 < ebassi> gmorten: you get to maintain 2.x anyway ;-)
 137 < gmorten> just one pissed off guy -- me -- and it won't be "concensus"
 138 < ebassi> timj: I agree - we should branch for 3.x as soon as possible
 139 < mpt> consensus != unanimity
 140 < 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
 141 < bratsche_> Yeah, consensus means "general agreement"
 142 < mclasen> timj: the downside is that it would mean fixing bugs in three branches
 143 < mitch_> ebassi: as soon as possible?
 144 < mclasen> but I guess thats ok
 145 < mclasen> was there any talk about doing 3.x work in git at guadec ?
 146 < ebassi> mitch_: well, as soon as the work on features
 147 < ebassi> mitch_: *starts
 148 < mitch_> ebassi: ah yea i thought you meant work in a branch while we still do 2.16
 149 < 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
 150 < mitch_> eek
 151 < timj> mclasen: no, we didn't talk git/bzr at all in the gtk-devel meeting
 152 < mitch_> well, i guess i'm the only one who hates branches then ;)
 153 < bratsche_> Why?
 154 < mitch_> because they utterly confuse me and the rebasing is evil
 155 < mitch_> ignore me :)
 156 < 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)
 157 < 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_ ;)
 158 < timj> sorry, one can of course *also* use bzr-svn ;)
 159 < mitch_> bratsche_: yea go ahead i already hate git ;)
 160  * bratsche_ started using git-svn for GTK hacking, but we use bzr at work.
 161 < mclasen> mitch_: branches are fine as long as you never merge or rebase
 162 < mitch_> as said, please ignore me :)
 163 < mitch_> mclasen: haha :) well said
 164 < timj> anyway this is side tracking, we can have (d)VCS wars at other times.
 165 < timj> feedback on branching for 3 soon in SVN?
 166 < mclasen> fwiw, I think 'branch early' is a good strategy
 167 < bratsche_> +1
 168 < timj> great
 169 < mclasen> just to keep stuff moving
 170 < mclasen> and avoid the 'scattered in a thousand git trees' syndrome that X suffers frmo
 171 < timj> # 4 What is the prospect of creating a spin-off libgtk3deprecated that's not maintained by the Gtk+ core team.
 172 < mclasen> just to make sure I fully understand this idea
 173 < 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.
 174 < mclasen> the plan is that gtk 2.x and 3 will be parallel installable ?
 175 < timj> mclasen: yes
 176 < mclasen> and 3 will drop all deprecated api from 2.x
 177 < timj> libgtk3deprecated (or graveyard ;) would depend on gtk3
 178 < mitch_> that would mean first "undeprecating" the deprecated widget completely, e.g. not using GtkType or GtkArg
 179 < timj> mclasen: well, 2.90 will at least
 180 < mitch_> which could be done for 2.16 and be good for building gtk with DISABLE_DEPRECATED and get rid of GTK_COMPILATION
 181 < timj> mitch_: i think there are other reasons for GTK_COMPILATION as well
 182 < mitch_> timj: very few, but yes
 183 < timj> mitch_: and, i guess one could investigate if GtkArg could reasonably be moved into libgtk3deprecated
 184 < mitch_> timj: why should it be, that would be unreasonable
 185 < mclasen> how will libgtk3deprecated work for individual deprecated functions, as opposed to wholly deprecated widgets ?
 186 < mitch_> mclasen: i think they would not be part of it
 187 < mclasen> and what will happen to deprecated stuff in e.g. glib ?
 188 < 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
 189 < mclasen> so there will be no guarantee that you can move your 2.x app to 3 + graveyard  without porting ?
 190 < mitch_> exactly
 191 < 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...
 192 < mitch_> and optionmenu
 193 < ebassi> and the file selector
 194  * ebassi runs
 195 < mitch_> eek
 196 < 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 
 197 < mclasen> timj: I need to look at the 3.x task list again 
 198 < mclasen> I may have some additions...
 199 < timj> mclasen: that'd be much appreciated: http://live.gnome.org/GTK%2B/3.0/Tasks
 200 < mitch_> i have some too actually
 201 < mclasen> so, the findings seem to be going the 2.9x route and branch early
 202 < mclasen> should we switch to the last agenda item ?
 203 < mclasen> Feature roadmap for 3.x
 204 < timj> yeah
 205 < timj> #5 Feature roadmap for 3.x.
 206 < 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"
 207 < 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.
 208 < 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
 209 < timj> further suggestions welcome
 210 < bratsche_> There's already some discussion of new style/theme stuff, maybe we can link over to that from this new page.
 211 < mclasen> one question I have: do we cut off development of 2.x-compatible features in 2.16 ?
 212 < mclasen> or do we continue to pour things into 2.16 and only do the 'radical' features in the 3.0 branch ?
 213 < behdad> any way to call 3.x developmental and release 4.0 with new features?
 214 < tbf> behdad: why waste 3.x?
 215 < 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.
 216 < timj> tbf: agree
 217 < ebassi> mclasen: it depends on how do you rate 'radical' features
 218 < behdad> tbf: to actually devel on top of it and break again and again as needed..
 219 < timj> behdad: that can be 2.9y.x instead
 220 < behdad> yeah, different naming only
 221 < mclasen> ebassi: the stuff that people _want_ to break abi for... I mean, there better be something in that category, right ?
 222 < mclasen> ebassi: like, say, 'scenegraph', to throw out a buzzword
 223 < tbf> or "window-less" widgets
 224 < ebassi> mclasen: that would probably belong in the 3.x-radical camp
 225 < mclasen> whereas I would be very comfortable adding session-mgmt client api in 2.x...
 226 < ebassi> mclasen: more than the 2.x-radical one
 227 < ebassi> I'd rate session-managment as 2.15 feature, if it can land in that timeframe
 228  * mclasen doesn't  have any more input on 3.x features right now
 229 < mitch_> going window-less was very good imho
 230 < mitch_> subwindow, even
 231 < timj> ok, anyone volounteering to steer a 3.0 roadmap at this point? ;)
 232  * timj thinks "at least try asking..."
 233  * mclasen volunteers for 2.x
 234 < 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