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