1 < mclasen> meeting is now ? 2 < mitch> t+17min 3 < mclasen> ok, sorry I'm late... 4 < mitch> me too ;) 5 < mclasen> and I'm unprepared 6 < mclasen> do we have an agenda ? 7 < ebassi> not much on the agenda; I kinda hoped behdad would be around for a status on the hackfest 8 * mclasen is trying to get a gtk release out today 9 < mclasen> so, one thing we should probably discuss briefly 10 < mclasen> is the move to git 11 < mclasen> I kinda assume everybody will cheer if we move to git with the rest of gnome, after 2.26 ? 12 < jdahlin> that seems to be expected 13 < tml> not maybe cheer (hey, svn worked fine for me, I apparently should be ashamed to admit), but not 14 run out stamping feet and slamming the door either 15 < ebassi> mclasen: I cheered when I read your email :-) 16 < mclasen> tml: it works ok for me too 17 < mclasen> but I know many people who work on gtk already do it in git repositories 18 < tml> yep, I am perfectly fine with the move, and fully expect to start appreciating the finer 19 flavours of git over time 20 < mclasen> Slightly related to the git migration: I think we probably want to get alex' csw work into 21 the main repository and maybe keep it in a branch until it is ready on all platforms 22 < mclasen> and doing so will be easier in git than svn, I assume 23 < ebassi> mclasen: yeah, especially if alexl wants to preserve the history 24 * mclasen starts another distcheck 25 < ebassi> mclasen: so the plan for 2.26 is glib 2.20 and gtk+ 2.16, right? 26 < mclasen> yes, thats what I'm aiming for 27 < ebassi> mmh, no behdad on #cairo either, so no way to get him here :-/ 28 < ebassi> well, I hope to see an email for the hackfest at some point :-) 29 < xan> last I heard of him he had severe pain in his hands or wrists or around that area 30 < xan> so maybe he's resting of computers... 31 < ebassi> oh, ouch :-( 32 < ebassi> I've seen the plans for GLib on the mailing list 33 < ebassi> are there some plans/discussions for gtk+ as well? 34 < mclasen> yes, behdad went to california for a week 35 < mclasen> I guess I should send out a similar mail talking about alex csw stuff 36 < ebassi> I'll need to finish the GIO integration for recent-files, now that the gnome-shell team is 37 discovering holes in the API :-) 38 < mclasen> yes, thats a good topic to bring up 39 < tml> what about file locks, would anybody oppose adding such to GIO in principle? 40 < mclasen> what kind of locks ? 41 < tml> advisory ones, I think 42 < tml> or maybe both advisory and mandatory. all depending on which ones, if either, exist for the 43 scheme/backend/whatever in question 44 < tml> mclasen: I think all platforms have some concept of locking. and what danw says sounds sensible, 45 i.e. no guarantee that the lock will be mandatory, but it might, and it is for whole file 46 < mclasen> ok, sounds like all we need is an api proposal, then 47 < danw> mclasen: (i think the suse gnome-vfs version used gnome_vfs_file_control(), so it wasn't 48 actually adding API entry points, just adding semantics to an API that would otherwise return 49 ENOTIMPL) 50 < tml> too bad there isn't any generic "flags" argument to g_file_read(), g_file_create() &friends 51 < ebassi|afk> g_file_acquire_lock() ... g_file_release_lock() ? 52 < tml> danw: it did add a GNOME_VFS_OPEN_LOCKED to GnomeVFSOpenMode 53 < danw> tml: ah, i lose then :) 54 < tml> ebassi|afk: I think we want something that happens atomically at open time, if possible 55 < tml> at least, to be able to handle the use case that the GNOME_VFS_OPEN_LOCKED was used for... 56 < danw> well, that was what openoffice wanted, but there are other use cases 57 < danw> (i missed the beginning of the meeting. was there an agenda?) 58 < mclasen> no 59 < mclasen> just throw your points in 60 < tml> yeah, good point, turning a lock (for the whole file) on and off on an already open file is also 61 something commonly needed 62 * mclasen wanders off 63 < ebassi> as usual, minutes to the list and log on the wiki page
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.