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
Attached FilesTo refer to attachments on a page, use attachment:filename, as shown below in the list of files. Do NOT use the URL of the [get] link, since this is subject to change and can break easily.
You are not allowed to attach a file to this page.