Excel Function Meta Bug?

[Joel Madero]

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 <erack at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20120713/9d5f1cf9/attachment-0001.html>