Minutes from the KDevelop BOF at aKademy 2007
From KDevelop
[edit] KDevelop BOF
[edit] Attendees
- Alexander Dymo (the boss)
- Jens Herden
- Harald Fernengel (the scribe)
- Kevin Krammer (partly)
- Andras Mantia
- Johnny Stovall
- Jakob Petsovits
- Aleix Pol Gonzalez
Topic: Separate packaging in the platform for all plugins?
Jens: Problem - one plugin requires boost Andras: Don't want boost dependency on Quanta - only core packages interesting. Alex: Plugin that depends on boost (lib) is TeamWork - we probably want to have it in the platform since it's a killer feature. Andras: It's cool, but is it important? Lot of developers don't need it by default Jens: Anything that doesn't depend on C++ or web development should be in the platform. Remote cooperation doesn't depend on the platform - so it should be there. Andras: TeamWork also contains a fork of libdiff - it's huge, little bit bloating, should be its own module, packaged separately (recommended package?) Conclusion: TeamWork is not required to create a platform - it's a module. Jens: Make sure to communicate first, don't just move it.
Action Point: Alex - Move TeamWork out.
Topic: Interfaces
Alex: We have a bunch of new interfaces, it would be good to sit down and review them Andras: Good idea, documentation is outdated, sometimes doesn't even exist. Conclusion: Yes, let's do it during this week.
Topic: Code Quality
Alex: How can we make sure to keep quality? Shall we establish a policy? Harald: Review work as long as their are immediate. Andras: Platform commits can go to the mailing-list? Harald: That's a lot of noise. Harald: Unit testing can ensure to keep stability - but we can still be open to commits. Jens: Policies have to be enforced - tricky with a community. With the current lack of developers, it doesn't make sense to write down a policy. Harald: Tests can improve getting new developers in - they'll be less scared if there are tests to verify behavior. Aleix Pol: Maybe the problem is calling it policy - it should be a recommendation so we won't scare volunteers away. Jens: Once we have 90% test coverage, we can get a policy in - otherwise new developers have to work in a different way than all the others. Alex: Find a good way to sell the idea of testing to community. Alex: In KDevelop, we have a lot of regressions, tests are badly needed. Johnny: Why not stricly enforce it? Harald: We're a community, we shouldn't enforce. Andras: New interfaces should be documented by default. Alex: Agreed - this should be a stricter policy.
Action Point: Harald: Write a document why/how to test for KDevelop.
Sub-Topic: Reviews
Harald: Reviews - we need a system to review. Jens: WebKit has some review people, they can review - the submitter states the name in the commit log. Aleix Pol: Reviews can be a lot of workload, slows down people - we don't have enough resources. Johnny: Reviews are good - you'll get better quality. Harald: Reviews do slow down at first sight, but in the long run it's better - otherwise, you'll have to debug that code later. Jens: Let's do a trial period - you post to the mailing list, get a review, and then you commit. Andras, Alex: Prefer post-commit reviews. Harald: Suggestion - switch to pre-commits only before releases (in the hot phase). Jens: Can we have a filter that sends all commits to core parts to kdevelop-devel? Alex: Sure.
Conclusion: Send every commit to core platform parts to kdevelop-devel for post-commit reviews.
Action Point: Alex to implement such a system
Sub-Topic: EBN
Harald: We can use the EBN to upload scripts to check our code quality (e.g. enforce documentation on all interfaces)
Conclusion: Agree - we should make better use of it.
Topic: UIs
Alex: Gave a history of KDevelop UI Jakob: Doesn't like navigate by history - no visual indication where you'll move Harald: Navigating Tabs and navigating history are two different concepts - should not be mixed Jakob: HIG specifies shortcuts for history-based (Alt-Left/Right) and order-based (Ctrl-Comma/Dot) navigation Harald: Why not involve the HIG group? Jens: If I go from one split view to the other, I want to go back where I was - no matter in which split view. Jens: Have to think of new developers vs. old developers - they have a different amount of files opened at a time. The file list was not optional. Suggestion: Go back to tabs - although you don't see all opened files at a time, but it's a good indicator. Tabs - you see more from the file name. Jens: QuickOpen was coolest feature - but well hidden.
heated discussion too fast to protocol
Open Discussion Questions / Suggestions:
How can we group files?
How can we make a visual representation of many open files and ease navigation?
Ask HIG group for advice (they've been through these discussions)
How to make QuickOpen more visible / easily usable.
Status Bar vs. Tab - where to display the current file info?
Topic: Icons
Alex: Who cares for icons? Jakob: I do.
Conclusion: Jakob is the new icon manager for KDevelop
Topic: CMake
Aleix Pol gave an overview of the CMake status in KDevelop Trouble: How to write back changes to a CMake/qmake/whatever project file that was hand edited?
Alex: Wants to read/write project files without destroying local modifications Conclusion: We want to have full read/write support that preserves local modifications (full parser). Simple editing should be provided by the GUI while preserving statements that KDevelop doesn't understand.
Question: How about cross-platform code?
Conclusion: Keep the way of working - the Mac and Windows guys fix their platforms. Try to use Qt whenever possible instead of system calls.
Question: How about scripting?
Alex: We have D-Bus, Kross, QtScript Jens: What is Kate doing? Harald: Once we have the objects, binding to D-Bus and QtScript is not mutually exclusive. Alex: We should do what Kate does, since they are so interlinked Andras: Often, you want to interface with your editor, KDevelop should integrate well
Conclusion: See what Kate does.
Question: Where to get lunch?
Protocol stops here
![[Main Page]](/graphics/theme3/KDevelopBigIcon.png)