[vtk-developers] VTK code review / testing / integration workflow

Tue Aug 26 14:46:25 EDT 2014

This is in the "would be nice to have" category.

Based on recent personal experience and the experience of others
updating VTK versions, I would like to see performance regression
tests in VTK (e.g., changes to memory consumption, execution time,
rendering frame rate, etc.) with the results of the tests reported in
the review workflow. That way developers and reviewers could easily
reject changes that cause unacceptable performance regressions.

I realize this might not be the easiest thing to implement, and would
require changes beyond the review system, but it would be very nice.
CDash reports a history of the execution time of tests, but this isn't
always helpful in its current form.

- Cory

On Tue, Aug 26, 2014 at 12:52 PM, Burlen Loring <burlen.loring at gmail.com> wrote:
> I wanted to comment that your gerrit work flow is great. I like the
> organization by topic branches and that dashboard runs are automatically
> triggered on new pushes. Also the reviews by folks on your side have been
> very helpful in improving the submitted code. It would be nice to see a diff
> between successive review/recommit iterations.
>
> I don't know how much the work flow is turning off new developers, a knee
> jerk reaction is that it feels like overkill, but all of the things that you
> ask folks to do make a lot of sense and help keep VTK solid. It sure is
> rewarding to see how solid VTK is and see it's continual improvement and to
> be a part of that! As a developer the high quality of the resulting product
> outs weigh my desire to work with fun tools.
>
> I recently made some commits to a KDE component project. Their workflow uses
> svn+reviewboard. The lack of topic branches made iteration cumbersome. Once
> the patches were approved merging was not as easy as it is in your gerrit
> workflow where it's done with a simple button click on a web page.
>
> I would think that modernization is more of an issue in attracting
> developers. Ancient OpenGL infrastructure is a really big one. Things like
> having to use SafeDownCast instead of dynamic_cast and the other baggage of
> supporting ancient compilers are also a big turnoff. A full c++11 port would
> be very exciting. All these are things you are working on but are harder and
> take longer to change...
>
>
> On 08/25/2014 04:47 PM, Berk Geveci wrote:
>
> Hi Bill,
>
> The goal is not to have more process. It is to implement a workflow with
> fun-to-use tools such that we can continue to attract developers to VTK. VTK
> development is lively. We have done a lot of great stuff last year, both new
> development and maintenance, and we have great things coming next year.
>
> In my humble opinion, what we are doing poorly is attracting new developers.
> I think toolchain and workflow play a role in this. Not communicating well
> is another part. I'd like to attract more people to contribute code and more
> people to do reviews. Also, our bug tracker is collecting dust. Lots of bug
> reports are going in but it gets very little attention. I can't even
> remember when I looked at it last.
>
> Here are some statistics from openhub.net (website formerly known as ohloh):
>
> VTK:
>
> 30 Day Summary
> Jul 21 2014 — Aug 20 2014
> 152 Commits
> 19 Contributors
>
> 12 Month Summary
> Aug 20 2013 — Aug 20 2014
> 2393 Commits
> Down -965 (28%) from previous 12 months
> 64 Contributors
> Down -6 (8%) from previous 12 months
>
> Still a lot of commits but going down.
>
> So I'd like to see us slowly migrating towards tools that are more
> attractive and facilitate collaboration with the larger community.
>
> Frankly, I believe that our current set of tools get in the way. First of
> all, they all require creating accounts to do anything. An account for bug
> tracker, another for Gerrit, another for Wiki, another 2 for the mailing
> lists. We should have presence where people already hang out and don't have
> to create new accounts. Github, stackoverflow, Google+ etc. Second of all,
> they are all clunky at best. Usability does matter to people. Finally, there
> are a lot new resources available out there and we are not tapping into it
> as best as we can. We should be using Travis and Jenkins in addition to
> CDash and CDash @ Home for example.
>
> So I don't think that this conversation is overkill. These discussions have
> a natural tendency to go on forever, I agree. So let's try to keep to the
> point and make some decisions soon.
>
> Best,
> -berk
>
>
>
>
>
>
> On Mon, Aug 25, 2014 at 4:54 PM, Bill Lorensen <bill.lorensen at gmail.com>
> wrote:
>>
>> BTW the new gerrit UI is a bit prettier:
>> https://android-review.googlesource.com/#/q/status:open
>>
>> I'm a little concerned that we spend too much time on process and not
>> enough time on improving VTK. But, I'll go with the consensus of the
>> people who still work for a living. If the new process is too
>> difficult for an old guy like me, I'll just spend my extra time with
>> ITK.
>>
>> Bill
>>
>>
>> On Mon, Aug 25, 2014 at 4:45 PM, Sean McBride <sean at rogue-research.com>
>> wrote:
>> > On Mon, 25 Aug 2014 15:50:59 -0400, David Cole via vtk-developers said:
>> >
>> >>A fantasy feature for me would be that the system injects a step
>> >>1.5/2.5 in the developer workflow, and automatically chooses 3-5
>> >>reviewers for you based on reviewers "signing up" for reviewing certain
>> >>modules, or perhaps based on recent-ish commits in the same files...
>> >
>> > That would be a great addition.  I often don't know who to add as a
>> > reviewer, and I've been tinkering with VTK for years.  Imagine a newbie!  A
>> > person can use 'git log' and 'git blame' to get some guesses, and that could
>> > be automated.  Of course, sometimes that results in suggesting someone no
>> > longer involved with VTK or the infamous 'VTK developers', but still it
>> > would help to automate it.
>> >
>> > Cheers,
>> >
>> > --
>> > ____________________________________________________________
>> > Sean McBride, B. Eng                 sean at rogue-research.com
>> > Rogue Research                        www.rogue-research.com
>> > Mac Software Developer              Montréal, Québec, Canada
>> >
>> >
>> > _______________________________________________
>> > Powered by www.kitware.com
>> >
>> > Visit other Kitware open-source projects at
>> > http://www.kitware.com/opensource/opensource.html
>> >
>> > Follow this link to subscribe/unsubscribe:
>> > http://public.kitware.com/mailman/listinfo/vtk-developers
>> >
>>
>>
>>
>> --
>> Unpaid intern in BillsBasement at noware dot com
>
>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>
>
> _______________________________________________
> Powered by www.kitware.com
>
> Visit other Kitware open-source projects at
> http://www.kitware.com/opensource/opensource.html
>
> Follow this link to subscribe/unsubscribe:
> http://public.kitware.com/mailman/listinfo/vtk-developers
>
>