Uwe Stöhr wrote: > >> Sorry but this is the rule: When you add a new feature build it so that it > >> doesn't introduce a regression except this was a discussed decision. > > > > it is not fair to be taught about the rules in the thread which start with > > defective commit that was not discussed at all, in fact even announced. > > Why is this not fair?
because the usual culture is converse - when messing with code you dont understand you should ask on list before commiting it. > I explained why I committed the patch and why this is conform to the rules you were clearly not aware of the regression which was introduced and it was just by chance i looked on the commit. this is not problem per-se, everybody makes mistakes, but i find it funny to be instructed about conforming Uwe's rules of fixing bugs in such a situation. > > I don't agree with you here: Now only completion doesn't work when pressing > > TAB very fast, so this is not a big problem. > > > > yes and those two very fast tabs were exactly the way how completion > saved my time before two hours :D > > And now I have to write a report containing lots of tables, and navigating > with the TAB saves me a lot of time. What is better? ;-) hehe :) i will answer in your way - to commit what i like, then endlessly defend it and let others fix my commit. > > as i said, its not either or; we will make both working. its just stupid > > to introduce 'fixes' which break another things. > > No, the completion feature introduces 2 regressions, not my commit > introduced a bug, it just uncovered the completion bug. it did not uncover anything. it solved one bug and introduced new bug, which was not there before. pavel
