Activating Documents with a range is broken since d77c94c1402916f8f00b02104f71187330548ecd
mail at milianw.de
Thu Dec 13 11:10:42 UTC 2012
On Wednesday 12 December 2012 23:28:35 Andreas Pakulat wrote:
> On Wed, Dec 12, 2012 at 8:37 PM, Milian Wolff <mail at milianw.de> wrote:
> > On Wednesday 12 December 2012 20:25:01 Andreas Pakulat wrote:
> >> just bisected why double-clicking entries in the grepview does not
> >> work anymore as it should. Turns out that
> >> DocumentController::activateDocument( doc, range ) does not jump to
> >> the range anymore, unless the document is not open yet. Anybody
> >> understands the logic thats involved and can fix that? Otherwise I'll
> >> revert this over the weekend.
> >> That also makes me wonder wether we maybe should reconsider all of the
> >> refactorings that Aleix did in this area, this is not the first
> >> regression it caused and the main benefit of lazily initializing views
> >> is not usable at the moment either (see my contextmenu related mail)?
> > I'd also consider that this second breakage means the changes hit master
> > too soon. Please revert them, put them into a branch, and lets
> > investigate it there.
> I'm not sure this would help the intended changes. If it lives in a
> branch somewhere almost nobody will test the changes since most
> master-users wouldn't want to try experimental stuff. Without people
> using the branch on a daily basis for their daily work you're not
> going to hit the issues we've seen so far. If you're afraid of having
> regressions because you want to push out a 4.5 asap, then you
> should've put in a freeze a month ago or so IMO.
> I think the best way at the moment to test such changes in the core is
> putting them into master to get as many testers as possible. The only
> viable alternatives i see are to get all active developers and a
> couple of users to use a staging branch locally where they merge all
> currently-active feature branches and report back any issues they find
> (and which branches they merged locally). Or alternatively to have
> unit-tests and ui tests for these things and make it dead-easy to add
> new ones. Neither of the two seem to be possible in the short-term.
True. We should think about maybe offering a GSOC slot next year to get some
Squish testing setup for KDevelop, such that we are better able to test our UI
parts. What do you think - would you maybe have time to mentor such a project?
> I'm also not much of a fan of reverting changes, especially when so
> many have been done with others in between and potential later changes
> that affected the changed code as well. Reverting this requires quite
> some effort as well to avoid introducing yet more regressions.
> So I'd say, lets try to hammer out any further possible regressions,
> maybe re-evaluate the commits by putting them into reviewboard or just
> reviewing them locally to see what could possibly be affected by them
> and then test that out more. At least its still rather easy to bisect
> these and find the culprit for a bug if its related to the
> document/view changes and thus get a clue where the bug could hide.
OK, lets do it this way then. I hope to have some more time on the weekend
again and will try to look into this then.
mail at milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: This is a digitally signed message part.
More information about the KDevelop-devel