I closed the bug as INVALID and put a comment on there. I also will move the list to the wiki, not sure where it's preferred to go or if I'm making a new wiki page. Thanks for the feedback
Joel On Fri, Jul 13, 2012 at 8:56 AM, Eike Rathke <er...@redhat.com> wrote: > Hi Joel, > > On Wednesday, 2012-07-11 15:53:07 -0700, Joel Madero wrote: > > > I'd like to make a meta bug for functions that Excel has but that aren't > > currently supported or are problematic in Calc. This stems from FDO > 47164: > > https://bugs.freedesktop.org/show_bug.cgi?id=47164 > > Taking Regina's answer this actually was about > https://bugs.freedesktop.org/show_bug.cgi?id=46918 > > For my takes on this topic see the mail I just sent to you and the QA > list. And now we have the situation that cross-posting to multiple lists > isn't always a good idea because each list doesn't know how things > evolve on the other list, as answers on the QA list apparently did not > include the dev list and vice versa. > > So, I'm including my answer here again: > > | On Friday, 2012-07-13 07:46:36 -0700, Joel Madero wrote: > | > | > Thanks for responding Eike. Summary is that I was bug triaging and came > | > across a bug that had a list of functions in excel that are currently > not > | > supported in LO. > | > | Cross-reading the dev list I found > | https://bugs.freedesktop.org/show_bug.cgi?id=46918 > | with a nice attachment listing functions. > | > | > 1. Leave excel bugs as is, keep that bug open with the list of > functions, > | > in the comments I'll confirm individual functions as problematic in LO > | > (harder to track progress, harder for devs to pick up individual > functions > | > out of the list) > | > | Better close the bug that otherwise would live for months and years and > | end up with 300 comments or so that no one would read anyway.. better > | add the there attached list (that would be outdated already after the > | first function was implemented) to the wiki from which individual bugs > | or implementation notes could be linked then. Such "implement dozens of > | features" bugs weren't helpful at any time. > | > | > 2. Leave excel bugs as is, close bug that has so many functions in one, > | > tell user that we need them as individual bug reports (easier to track > | > progress this way) > | > | We really don't need dozens of bugs open one for each function not > | implemented. I'd rather prefer to open a bug for a specific function > | only once a developer starts to implement it so we can (discuss if > | necessary and) refer it in the commit summary when done. Also, if users > | open bugs for functions they actually miss in their daily work it helps > | us more than doing that ourself in advance for all functions we know. > | > | > 3. Make a meta excel bug just for the functions, then I'll create > | > individual bugs for each bug listed by the user and make the meta bug > | > dependent on them (similar to most annoying) > | > | See above about my take on creating individual bugs, plus I don't see an > | advantage in having a meta bug for this unless it would be there to have > | a quick listing of its dependents. > | > | > 4. Make a meta excel bug, separate the function bug into individual > bug and > | > make meta bug dependent on ALL excel bugs (not just the functions one > from > | > the original FDO) > | > | We might also use something like an interoperability whiteboard keyword > | or some such to query for instead. > | > | Well, you may have deduced from my answers that I'm not a friend of meta > | bugs, unless they are there to mail a pointer to the dev list like the > | most annoying meta bugs. In short, it's ok for me if QA wants to create > | a meta bug to track existing things, but opening a bunch of bugs to be > | tracked just for the sake of having everything in that we _might_ want > | to implement over time of years doesn't make sense to me. > | > | > Michael CC'ed you on it because he said you're currently the go to for > | > excel compatibility. My argument is that anything to make it easier to > be > | > fully compatible with Excel is a plus if the goal is to convince MS > Office > | > users that we can provide a better product than MS can. > | > | Specifically when having dozens of bugs open for functions that only > | a very minority of users would use anyway it would be counterproductive > | pointing potential users to deficiencies they otherwise would even never > | have noticed or heard of ;-) > > > Eike > > -- > LibreOffice Calc developer. Number formatter stricken i18n > transpositionizer. > GnuPG key 0x293C05FD : 997A 4C60 CE41 0149 0DB3 9E96 2F1A D073 293C 05FD >
_______________________________________________ LibreOffice mailing list LibreOffice@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/libreoffice
