Bug#610468: status: patch merged; needs a bit more work
On Tue, Apr 10, 2012 at 04:22:29PM +0200, Martin Stigge wrote: A few comments in order to proceed: Hi Jonas, As I understand you are still on your NYC trip, so sorry for the nagging, but I anyway would like to ask if there is anything in particular I could help with in order to speed up the package upload process. Regards, Martin signature.asc Description: Digital signature
Bug#610468: status: patch merged; needs a bit more work
On 12-04-21 at 07:33pm, Martin Stigge wrote: Hi Jonas, As I understand you are still on your NYC trip, so sorry for the nagging, but I anyway would like to ask if there is anything in particular I could help with in order to speed up the package upload process. Not a vacation - fine that you nag. :-) I've done a few updates now, and expanded the FIXME in changelog. Please tell me if something is unclear, or if you disagree with some of it. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Bug#610468: status: patch merged; needs a bit more work
Hi Martin, hi Jonas, First of all, thanks Jonas for your work, I really appreciate it. [...] 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. 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? * 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. * 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 That's a bit more difficult now to create collections, as we must: - Understand that the client wants a collection (as usual) - Choose between a calendar and an address book Most of the clients can't create collections, they send requests and hope that the collection is already created for them. The collections are now created on GET requests, and the PROPFIND sometimes requests advertise their calendar or address book powers (that's what the commit does). I hope that it doesn't break the Apple clients support. Tests with different clients are welcome :). Regards, -- Guillaume signature.asc Description: This is a digitally signed message part
Bug#610468: status: patch merged; needs a bit more work
Hi Martin, hi Jonas! First of all, thanks Jonas for your work, I really appreciate it. [...] 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. 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? * 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. * 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 That's a bit more difficult now to create collections, as we must: - Understand that the client wants a collection (as usual) - Choose between a calendar and an address book Most of the clients can't create collections, they send requests and hope that the collection is already created for them. The collections are now created on GET requests, and the PROPFIND sometimes requests advertise their calendar/address book powers (that's what the commit does). I hope that it doesn't break the Apple clients support. Tests on various clients are welcome :). Regards, -- Guillaume signature.asc Description: This is a digitally signed message part
Bug#610468: status: patch merged; needs a bit more work
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
Bug#610468: status: patch merged; needs a bit more work
I've sent the mail twice to the list *and* to you, sorry. Le jeudi 12 avril 2012 à 14:50 +0200, Martin Stigge a écrit : 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 signature.asc Description: This is a digitally signed message part
Bug#610468: status: patch merged; needs a bit more work
On 12-04-12 at 02:50pm, Martin Stigge wrote: 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. This is the note I put in our Debian packaging currently: FIXME: Create $HOME initially, ensure it exists at daemon start, patch default file-store path to be ~/.local/shared/Radicale/collections (to mimic XDG_DATA_HOME), and suggest to upstream to use python-xdg. So I agree that respecting XDG_DATA_HOME is better than hardcoding either ~/.config or ~/.local, and I agree that python-xdg is one sensible approach. But I also recognize that you try avoid library dependencies as much possible, which is my reason for _suggesing_ rather than recommending python-xdg :-) What might work is to have Radicale default to using XDG_DATA_HOME and if that is empty then fallback to e.g. ~/.local . But I don't know XDG standard in depth (I am the kind of person who _loves_ libraries so that I need not know all details myself). - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
Bug#610468: status: patch merged; needs a bit more work
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
Bug#610468: status: patch merged; needs a bit more work
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. - Jonas -- * Jonas Smedegaard - idealist Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: Digital signature
