On 15/05/12 16:59, Kohei Yoshida wrote: > On Tue, May 15, 2012 at 10:28 AM, Eike Rathke <er...@redhat.com> wrote: > >> So, what we could do is prepare two proposals, the clean incompatible >> one and the ugly more compatible one ;-) It's then up to the TC to >> decide. > > I think this is a sensible approach. However, given how slow the TC > can be, I'm not sure if we can rely on them reaching a conclusion in > time for 3.6 (my guess would be "no"). I would rather we pick one > now, document it and use it. Then later when the TC decides what to do > in the standard, we'll adopt to that.
seems unrealistic for 3.6, yes. > I just don't want to set a dangerous precedent where an implementer > has to wait for the (quite time-consuming and slow-going) > standardization process in order to get a feature implemented. I can > see similar situations popping up in the future, and I don't want the > standardization process to be the bottleneck. Note that this is not > to bash the standard committee being slow. That process is slow for a > reason, and it's probably better that way. I'm just trying to avoid > setting undesirable precedents for similar situations that we will > undoubtedly encounter again. the problem with doing that of course is that there is a high risk that the ODF import will forever have to carry around ugly code to import stuff that never made it into ODF. _______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
