https://bugs.documentfoundation.org/show_bug.cgi?id=135683

--- Comment #17 from Telesto <tele...@surfxs.nl> ---
(In reply to Aron Budea from comment #16)
> > tdf#135683 speed up large writer table load
> For the record, this has been reverted due to bug 144840.

A bit of a philosophical question (or me lacking information)

I'm ask myself, is the optimization fundamentally wrong or is it simply
uncovering some weird logic? I surely understand that the person who is working
on optimizations is working on a 'high' level. Not interest/aware of all the
implementation aspect of everything involved.

And lacking the interest to solve what he/she has broken somewhere else in the
code. And the first reflex being; lets revert. I'm not going the solve the
specific problem (and maybe there are more?)

However it feels like throwing away the child with the bathwater. If someone
bails on the first encounter of problem (headwind). It's bad for progress, IMHO 

So I'm asking myself is there an assessment made why the the problem occurs?
(or plainly opted for revert; the easy course of action). There are already so
many unit test etc. So I assume the optimization being pretty on first sight
(and the bug being the exception)

The assessment shouldn't necessary be made by the one pushing the commit.
Obviously it's better to be handled by someone with some more code knowledge in
the area involved [something called collaboration]. I know availability of
developers is scarce commodity.. and this might be seen as throwing stuff over
the fence (in bad faith)

I do notice that  mostly developer are left on their own; getting the fall-out
on their plate, if though the can't really help it (broken code somewhere else,
but unfamiliar with it; so no intention to solve). And nobody interested in
more/different (or yet unknown) bugs. 

Another issue is that with pulling the commit to soon, is the lack of data..
You don't get enough feedback if there are more problems or only one. I surely
understand pulling a commit with 3-5 bugs reported against it which show
problem in different parts of the code. But bailing out to soon makes progress
really hard. 

But sometimes ask myself is the current practice efficient/effective? Is there
no better way to handle this?

-- 
You are receiving this mail because:
You are the assignee for the bug.

Reply via email to