[poll] who uses KDevelop's upload-to-ReviewBoard feature?

[Kevin Funk]

On Tuesday 16 December 2014 15:39:11 Nicolai Hähnle-Montoro wrote:
> As an additional thought: Such a poll is probably quite unreliable,
> but there's probably no better option today.
> 
> Would it be possible to get statistics about how much KDevelop
> features are used "in the wild" automatically? Nowadays, many programs
> have (opt-in) reporting features that submit various metrics about
> in-the-wild-usage of a program. Interesting metrics would be: Which
> revisions are used in the wild? Which plugins are loaded? How often is
> each QAction triggered? What does memory and CPU usage look like? Also
> crash reports, of course.
> 
> I feel this would be desirable to have, though it'd probably be best
> to have a framework for this at the KDE level (both in terms of
> implementation of the measurements and in terms of server
> infrastructure for collecting those metrics). It also feels like this
> is a topic that has probably been discussed before, but I can't find
> anything with the search terms I've come up with...

Yes, I'd like to see this as well.

There have been discussions about this topic at several Akademies, but no-one 
stepped up implementing a proof-of-concept so far, I fear.
 
> Cheers,
> Nicolai
> 
> On Tue, Dec 16, 2014 at 3:27 PM, Nicolai Hähnle-Montoro
> 
> <nhaehnle at gmail.com> wrote:
> > On Tue, Dec 16, 2014 at 3:20 PM, René J.V. <rjvbertin at gmail.com> wrote:
> >> I'd like to do a quick & informal survey of how many of us are using the
> >> upload-to-ReviewBoard feature of KDevelop's patchreview plugin (e.g.
> >> Git/Show Differences/Export/ReviewBoard...).> 
> > I have only just discovered that there's an "rbt" command-line tool,
> > so that's a No from me ;)
> > 
> > By the way: I am in general not too happy with kdevelop's patch
> > review, and specifically the Git interaction:
> > 
> > 1. It's unnecessarily difficult/confusing to look at a diff between
> > specific revisions, and even impossible if the revisions are not in
> > the same branch.
> > 2. Editing a file while inside the patch review is cumbersome (I
> > reflexively Ctrl+S every couple of seconds, and that causes the patch
> > review to reload completely and all views to close).
> > 3. There doesn't seem to be a proper understanding of the Git staging
> > area (I realize that that's not specific to patch reviews).
> > 
> > Those are tough problems to solve, both in terms of implementation and
> > in terms of UI design.
> > 
> > Cheers,
> > Nicolai
> > --
> > Lerne, wie die Welt wirklich ist,
> > aber vergiss niemals, wie sie sein sollte.

-- 
Kevin Funk | kfunk at kde.org | http://kfunk.org