Got your mail 4 times, weird. On Thu, 2012-04-12 at 13:03 +0200, Guillaume Ayoub wrote: > > * 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. > > Using ~/.local instead of ~/.config is a much better choice, and I > really should use that in the default configuration file. Using the > real XDG_DATA_HOME environment variable is an even better solution, > isn't it?
There is also the package python-xdg for that. > > * 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. > > The default folders will probably change again in the near future (as > said in the last paragraph). Before 1.0, I've decided not to advertise > about this in the code, but adding a warning saying something like "your > storage folder is empty" could be a good idea. That would catch this case, but I'm not sure that this really conveys the particular issue to the user: it's empty, yes, but why is that so? Well, the configuration option name changed, that's why. Radicale could be aware of "folder" still being set, but "filesystem_folder" not being set and warn accordingly and possibly fall back. (I'm talking here about the specific case of a pre-0.7 user doing an upgrade and not seeing the NEWS file that we will provide, since it's actually not so common for users to check that file regularly.) > > * 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. > > This issue is fixed in this commit: > https://github.com/Kozea/Radicale/commit/c3ce8fde389075aa3c83b3db58b28f127c27ccf1 Cool, thanks! Tested it on Iceowl/Sunbird (1.3) and it works. Will cherry-pick that patch for the upcoming Debian package until you release a new version. Regards, Martin -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
