How to conclude KEP2 for good
swalker at bynari.net
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 :
> 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  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 . 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.
>  http://kolab.org/pipermail/kolab-format/2011-April/001317.html
> 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))
>  http://kolab.org/pipermail/kolab-format/2011-April/001309.html
> 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 kolab.org
Senior Software Developer
swalker at bynari.net
222 W Las Colinas Blvd, Suite 1320N
Irving, TX 75039
(214) 350-5772 X29
(214) 352-3530 fax
More information about the format