Mailing List Archive

What about my long-time open merge requests?

Viele Grüße

-frank

> Am 01.12.2016 um 23:58 schrieb Florian Schlichting <fsfs@debian.org>:
>
> Hi,
>
> today at our DAViCal project meeting on IRC, we discussed the upcoming
> Debian freeze and our plan to release DAViCal 1.1.5 and AWL 0.57 in
> time. To give everybody an opportunity to look over and push pending
> work, fix a few more bugs etc. and make good use of the holidays, we
> decided to set the following release date for DAViCal and AWL:
>
> Friday, 6 January 2017
>
> This is still flexible if there are major issues, but in general I feel
> we get a lot more testing after a release than before...
>
> Also, if anybody has a bug that hasn't been reported yet, or feel there
> is a regression or other very important issue that we haven't responded
> to properly, please let us know over on gitlab.com/davical-project !
>
>
> @Cyril: Can you start another round of translations fairly soon? I've
> recently committed some of the work we talked about in January, so that
> 'make translations' will now run xgettext and msgmerge to extract new
> strings and put them into *.po files, but creation of binary *.mo files
> is separated out and done at (package) build time. You may still want to
> determine a consistently used set of xgettext options, though, like
> whether or not to use --no-location, -w/--no-wrap, -s for example...
>
> Enjoy the season,
> Florian
>
> ------------------------------------------------------------------------------
> Check out the vibrant tech community on one of the world's most
> engaging tech sites, SlashDot.org! http://sdm.link/slashdot
> _______________________________________________
> Davical-general mailing list
> Davical-general@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/davical-general


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general

Hi Frank,

On Fri, Dec 02, 2016 at 08:37:21AM +0100, Frank Steinberg wrote:
> What about my long-time open merge requests?

thanks for bringing this up - we should definitely communicate more
about those patches! I'm sorry your mail to the -devel list back in
January went without a reply entirely. Please work with us and help us
understand which parts are a "complete" fix for an issue and which are
more of a "works for me" kind of stab at what may be a larger issue. For
this, it may be useful to separate the patches into several merge
requests (each on their own branch), that each address one issue only.

I looked at them in September and already cherry-picked one of them (the
least intersting one probably, "Fixed some logging labels").

> (1) If an event organizer modifies attributes of an event, the attendees??? event instances should be handled with care, e.g., if the event time gets modified, the attendees??? PARTSTAT no longer makes sense and should be reset to NEEDS-ACTION. Furthermore an attendee might have applied an alarm or category according to his personal preferences. If the organizer modifies an event, the attendees??? instances should not be modified as a whole but just some attributes that must be equal for all attendees.

This sounds sensible. I haven't looked at it in detail and I don't
understand Clemens' comment. Clemens, can you pick this up?

> (2) I implemented a rather simple way to send iMIP invitations if attendees are not local (not based on the existing commented code). I am quite sure, that I did miss many details in how iMIP should work, but for our use this was sufficient.

I see inc/iMIP.php, but I don't see it being used anywhere? iMIP is one
of the major features that DAViCal is lacking, so this is definitely
interesting. There's also the handle-remote-attendees branch, which I
spent some time sorting through and cleaning up, see
https://gitlab.com/fsfs/davical/commits/WORK
This needs someone to pick up the pieces and properly integrate into our
repo, and fix a lot of bugs and write documentation in the process. I
don't know when I might get to it, so anybody else is very welcome to
take a look...

> (3) Group addresses can be used as attendees. The server expands them to user principals.

The comments for $c->enable_attendee_group_resolution say "Note that
CalDAV clients might get confused by this server behavior until they get
synced again." This sounds a little scary?

What do the RFCs say how groups are supposed to be handled? In DAViCal
currently, I think a "group" is really a principal just like any other
user, and can have collections of its own, no? This proposed behaviour
seems to run counter to that concept, even though it sounds like it
could be useful in practice?

> (4) I hardly remember the details, but I have observed strange behavior with different clients according to recurring events with attendees. After thinking a little about this special case, I found that this is really quite complicated and implemented a configuration option to completely disallow combinations of RRULE/RDATE and ATTENDEE in events.

That sounds like a quick hack to work around a hard problem, whereas I
think we should aim to understand the problem and develop a proper fix.
Having a weekly meeting with other people is something that DAViCal
should (and usually does) support IMHO.


Frank, does that help? If you have the time, I'd very much like to see
you join the DAViCal development team. We're always low on PHP
developers and people who work with us on issues in our IRC meetings.

Florian

------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, SlashDot.org! http://sdm.link/slashdot
_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general

> Am 02.12.2016 um 12:53 schrieb Florian Schlichting <fsfs@debian.org>:
>
> Hi Frank,
>
> On Fri, Dec 02, 2016 at 08:37:21AM +0100, Frank Steinberg wrote:
>> What about my long-time open merge requests?
>
> thanks for bringing this up - we should definitely communicate more
> about those patches! I'm sorry your mail to the -devel list back in
> January went without a reply entirely. Please work with us and help us
> understand which parts are a "complete" fix for an issue and which are
> more of a "works for me" kind of stab at what may be a larger issue. For
> this, it may be useful to separate the patches into several merge
> requests (each on their own branch), that each address one issue only.

To me, all my modifications are of the "works for me" kind, since I
am not that familiar with the large stack of calendaring specs.

Please understand, that I am not willing to reorganize my patches after
a couple of months. :-/

> I looked at them in September and already cherry-picked one of them (the
> least intersting one probably, "Fixed some logging labels").
>
>> (1) If an event organizer modifies attributes of an event, the attendees??? event instances should be handled with care, e.g., if the event time gets modified, the attendees??? PARTSTAT no longer makes sense and should be reset to NEEDS-ACTION. Furthermore an attendee might have applied an alarm or category according to his personal preferences. If the organizer modifies an event, the attendees??? instances should not be modified as a whole but just some attributes that must be equal for all attendees.
>
> This sounds sensible. I haven't looked at it in detail and I don't
> understand Clemens' comment. Clemens, can you pick this up?
>
>> (2) I implemented a rather simple way to send iMIP invitations if attendees are not local (not based on the existing commented code). I am quite sure, that I did miss many details in how iMIP should work, but for our use this was sufficient.
>
> I see inc/iMIP.php, but I don't see it being used anywhere? iMIP is one
> of the major features that DAViCal is lacking, so this is definitely
> interesting. There's also the handle-remote-attendees branch, which I
> spent some time sorting through and cleaning up, see
> https://gitlab.com/fsfs/davical/commits/WORK
> This needs someone to pick up the pieces and properly integrate into our
> repo, and fix a lot of bugs and write documentation in the process. I
> don't know when I might get to it, so anybody else is very welcome to
> take a look...
>
>> (3) Group addresses can be used as attendees. The server expands them to user principals.
>
> The comments for $c->enable_attendee_group_resolution say "Note that
> CalDAV clients might get confused by this server behavior until they get
> synced again." This sounds a little scary?
>
> What do the RFCs say how groups are supposed to be handled? In DAViCal
> currently, I think a "group" is really a principal just like any other
> user, and can have collections of its own, no? This proposed behaviour
> seems to run counter to that concept, even though it sounds like it
> could be useful in practice?

Agreed. That's why I thought it would be a good idea to turn the magic
on or off through a configuration option. Maybe, you could put a clearer
comment into the config example file.

>> (4) I hardly remember the details, but I have observed strange behavior with different clients according to recurring events with attendees. After thinking a little about this special case, I found that this is really quite complicated and implemented a configuration option to completely disallow combinations of RRULE/RDATE and ATTENDEE in events.
>
> That sounds like a quick hack to work around a hard problem, whereas I
> think we should aim to understand the problem and develop a proper fix.
> Having a weekly meeting with other people is something that DAViCal
> should (and usually does) support IMHO.
>
> Frank, does that help? If you have the time, I'd very much like to see
> you join the DAViCal development team. We're always low on PHP
> developers and people who work with us on issues in our IRC meetings.

Sorry, my time is much to limited, and I am not a PHP expert at all. My
hacks are a few months old, they work for us and I have no spare time
to get involved again.



------------------------------------------------------------------------------
Developer Access Program for Intel Xeon Phi Processors
Access to Intel Xeon Phi processor-based developer platforms.
With one year of Intel Parallel Studio XE.
Training and support from Colfax.
Order your platform today.http://sdm.link/xeonphi
_______________________________________________
Davical-general mailing list
Davical-general@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/davical-general