On Thu, 2016-03-10 at 13:55 -0800, Cosimo Cecchi wrote: > Hey Bastien, > > On Wed, Mar 9, 2016 at 2:06 AM, Bastien Nocera <had...@hadess.net> > wrote: > > I commented on the xdg-user-dirs patches. It's mostly fine, but > > still > > has the same problem as the first set of patches, which is going to > > be > > about organising conflicts between applications. > Thanks for the comments; I am a bit unclear how you would like to see > the current patchset change to address that. > Could you give me an example? I thought I implemented the suggestion > from your initial mail. > > > A couple of things that I'd like before merging all this: > > - verify that transifex or another system is in place to update and > > be > > reactive to new translations > I see translation commits in master, so I was assuming this worked > already.
I have no idea how Alex dealt with it. > Is there anything in my patchset you think would result in a change > in that regard? No, the patchset is fine. I'm just concerned about translations not getting updated in a timely manner, or the same problem for patches for adding new sub-user-dirs. > > - a test suite, verifying that files get moved properly, get > > renamed, > > etc. as expected. > Definitely; this is something I wanted too and I will work on it > next. Right, it's a bit difficult to see whether there are bugs in your patchset without a test suite, as the changes are quite invasive. > > Other than that, I'm happy with the changes, even if the man pages > > are > > still on the short side to me. > OK, I will try to expand that too. > > Either way, since the patchset is pretty large as it is, I'd love to > be able to merge the refactors/GLib port without the new user > directories feature in the meantime. Right. As mentioned, I'd really like to see at least a basic test suite before doing that, as the GLib port is the part of the patchset that's most likely to have bugs in it. > Another thing that would greatly benefit the code is porting it to > GIO. I initially didn't do that to reduce the churn and introduce a > dependency on GObject, but in retrospect I don't see why not - > practically speaking everyone shipping GLib already also ships > GObject/GIO. > > What do you think? I personally wouldn't mind, but bear in mind that you'll likely want to disable the gvfs extension point to avoid possible races/hangs waiting for the gvfs service on session startup. Again, easier to review and ack with a test suite. Cheers _______________________________________________ xdg mailing list xdg@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/xdg