On Sat, 2012-04-07 at 21:33 +0200, Jonas Smedegaard wrote: > Hi (especially Martin), > > Just a short status update: I've merged the branched code and done some > adjustments. Have a loog at the git sources, ask if something is not > logic, and complain if you disagree with something. > > As noted as FIXMEs in changelog I still intend to do a bit more tidying > before releasing. > > Thanks a lot for your work, Martin - and sorry it took me so long to > take time to look at it properly.
Hi Jonas, Thanks for your work and the merge! I checked your updates and they look good. I pushed some typo fixes and added a NEWS file with migration instructions. A few comments in order to proceed: * Regarding your FIXME: I don't really see an issue with $HOME, possibly a lack of understanding. The initscript already (re-)creates the default directories before daemon start. For anything non-default, the user needs to take responsibility of adjusting things. * For the file-store path patch, I see what you are getting at, however, my focus is on radicale as a system daemon. If you go forward with mimicking XDG_DATA_HOME, I'd suggest ~/.local/share/radicale/collections instead of the ~/.local/shared/Radicale/collections you wrote. The user would need a migration path though, similar to what I wrote into the NEWS file. * Continuing with that path, there is the issue of config variable renaming. If the user used a custom config file before and did not change the variable name, he will end up with an empty calendar since radicale silently uses the internal default of the new variable. It could be good to notice that the old "folder" is set but "filesystem_folder" is not set and gracefully fall back to that one (possibly with some warning output that this is deprecated). I'm not sure though how common this case will be, so not hacking a patch yet. * I found that my client (Iceowl) has an issue with the new 0.7 version if the calendar is newly created and clean, namely it considers radicale's answer invalid. (Adding events is working fine though and from then on everything is ok.) Even though Iceowl/Sunbird is not an officially supported client, I'm thinking of hacking a patch to fix that. However, this could wait until a later package version. Regarding my last comment, I would vote for releasing the package as soon as possible, i.e., only fixing the essential issues, to get as much testing of the daemon mode as possible, before we enter freeze. Regards, Martin
signature.asc
Description: This is a digitally signed message part
