How to conclude KEP2 for good

Shawn Walker swalker at
Mon Apr 4 19:35:20 CEST 2011

I've been following this, but following this is complicated because everybody is having their own
opinion of how this KEP2 should go about.

I think having a list of options in the wiki page of the list of solutions with a clear description
of what each solution is about along with a con and pro about that solution.

But, it will come down to that nobody is going to be 100% satisfied with whatever solution is
selected for KEP2.


On 4/4/2011 7:45 AM, Bernhard Reiter wrote:
> Friends of the Kolab Format,
> the last two weeks have shown that the pure mailing list approach is not 
> bringing us close to getting a KEP 2 that is fully understood by everyone 
> and allows those who came later to the discussion to understand the rationale 
> behind all the design decisions.
> Replying to one important paragraph of Florian's email [1]:
> Am Montag, 4. April 2011 10:50:22 schrieb Florian v. Samson:
>> I have the impression many of the other subscribers of this mailing-list
>> are tired of the whole ongoing KEP2 discussion, even though at least you,
>> Bernhard, Jeroen and I seem to agree, that properties and implications of
>> each proposed solution must be very well understood,
> This is my observation as well, and even we four are 
> somewhat too entrenched in too long emails. As for the others:
> We have probably lost you, over this!
> This should not have happened. :(
> Georg and I have been talking how we can improve the process and achieve a 
> conclusion in a timely manner so we can implement it as soon as possible. In 
> principle we believe the idea of a consensus based process for KEPs is okay, 
> but in this case the complexity seems to lead us in circles.
> So how can we do what Florian also suggests?:
>>  I believe a transparent compilation of
>> technical and behavioural pros and cons in KEP2 for each proposed
>> solution is crucial, so people not following the discussion closely
>> (anymore) are still able to form a substantiated opinion without
>> retracing the whole discussion
> Our proposal is to start a new wiki page with to try and summarize the missing
> argumentation lines and suggest a solution with the rest as a design decision 
> on which there will be a short feedback period which will then hopefully allow 
> us to shorten the KEP to only the relevant points.
> I volunteer to start,  taking Florian's nice email summary parts from [1] and 
> bulding on the results of Georg's KEP2 draft to briefly document the main 
> lines of arguments. Starting with the three discussion topics I've suggested 
> here in [2]. Give me time until tomorrow. Then maybe the few people deeply 
> into the topic can add arguments in the wiki and have a new joined suggestion 
> until the end of the week.
> Ideally we find the overview again, 
> re-connect with the people that have less time to look into the details 
> and get a KEP2 done timely.
> Best,
> Bernhard
> [1]
>   Datum: Montag, 4. April 2011"
>   "Betreff: Re: A summary of sorts (was: Re: Why and when storing local
>   time? (Re: Basic rationale of the KEP #2 design))
> [2]
>   Datum: Freitag, 1. April 2011
>   Betreff: Re: Rationale of the KEP2 design: central in-format TZ-data vs.      
>   individual local TZ-databases and more (Part 2)
> _______________________________________________
> Kolab-format mailing list
> Kolab-format at

Shawn Walker
Senior Software Developer
swalker at
Bynari, Inc.
222 W Las Colinas Blvd, Suite 1320N
Irving, TX  75039
(800) 241-1086
(214) 350-5772 X29
(214) 352-3530 fax

More information about the format mailing list