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
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.