Planning and Organisation

A generic talk on the OpenMW project.
Locked
User avatar
lgromanowski
Site Admin
Posts: 1193
Joined: 05 Aug 2011, 22:21
Location: Wroclaw, Poland
Contact:

Planning and Organisation

Post by lgromanowski » 21 Aug 2011, 19:23

Zini wrote: While the coding is somewhat accelerating again (no commit today yet, though ;) ), we didn't make much progress with planning and organisation. If someone new wanted to contribute code right now, it would be hard to find a place to start.

We still haven't made any progress with the roadmap/open task list. There have been quite a few proposals in various forum threads, some of them rather contradictory. It would be nice if we make some progress here. But ultimately only Nicolay can decide how it should look.

Also, there is no documentation about the coding standards (naming conventions, tab/indent usage, ...) to be used when writing code for OpenMW. If I were to do more than simple maintenance (i.e. write new components by myself), I would have a hard time getting my code in line with the remaining code. Some of it could obviously glarked from context and from the existing code, but there are already some inconsistencies in the codebase. Again it is ultimately only Nicolay, who can decide about these standards.
Zini wrote: And while we are at it, what are your thoughts on using Doxygen to document the code? I have seen a few Doxygen-style comments here and there, but in most of the code they are not used.
pogzy wrote: Hi,

I agree with you, there are already several posts about these points and now Nicolay should enlighten us of his vision. He also should call for contributors to take in charge some precise tasks to go forward.

- a task list with precise tasks and a tracking tool can be used to see which tasks are done, waiting, etc. (MantisBT, or sourceforge tool etc.) Only Nicolay could initiate this list?

- a roadmap, with at least the main steps required to achieve the C++ complete ports, and the v1.0, that could be detailed and linked with tasks in the tracking tool. For now Nicolay is the one that can tell which sort of roadmap must be set, and is the one that give some key point to set it or even set it himself to initiate it.

Tasks are not specifically related only to code, there should be also tasks related to the wiki, the forum, etc.

With no tasks and no roadmap, the project will rely mainly on Nicolay, and will move forward slowly or even stay glued when Nicolay won't be available.

Nicolay should arbitrate between different points of view revealed in previous posts.

Nicolay should give us his point of view in a very clear way so we can move forward and help the project as most as we can without his help if needed.
nicolay wrote:
Zini wrote:We still haven't made any progress with the roadmap/open task list. There have been quite a few proposals in various forum threads, some of them rather contradictory. It would be nice if we make some progress here.
I agree completely. As you already know there's now a Wiki page for it. It's not perfect but OK for now. I will take a look through the forum posts and my own todo lists and expand the roadmap later.
Also, there is no documentation about the coding standards (naming conventions, tab/indent usage, ...) to be used when writing code for OpenMW. If I were to do more than simple maintenance (i.e. write new components by myself), I would have a hard time getting my code in line with the remaining code.
I personally don't really care all that much about the minor details about indenting and such, as long as it gets the job done (and preferably is well commented if it's not obvious what it does.) As you note I'm not even consistent with it myself. I know others might care more though, so if you have any specific ideas I'm open to suggestions.

I do care more about how things fit into the overall architecture - although I admit it's probably hard to adhere to that right now as it's still fluid and exists mostly inside my head. I think the most important rule of thumb is to create a set of modules that are as independent of each other as possible, as this makes testing and maintenance exponentially easier. The previous incarnation of OpenMW was turning into a big bowl of spaghetti mess; I'd like to avoid the pasta factor this time around ;)
nicolay wrote:
Zini wrote:And while we are at it, what are your thoughts on using Doxygen to document the code? I have seen a few Doxygen-style comments here and there, but in most of the code they are not used.
All for it, not super-high on my personal todo list atm. If you (or anyone) want to move things in that direction that would be very welcome.
Zini wrote: Okay, will do.
pogzy wrote: Hi,

Just for coding standard, it could be useful to choose one. Because with time we will have to do many diff from version to version. And it is now very easy to set the coding standard in modern editors and to forget about it. Moreover, coding style is a little more than indentation convention, some basic rules can help to avoid row mistakes.

It is very anoying to diff two files that have very different coding style. I propose to choose one of the most known for C++ code (I don't care, C++ is not my native language, any coding style can do).

I propose, but anybody can propose another set of rules http://google-styleguide.googlecode.com ... pguide.xml which is Google code rules. It is one web page only and are very short rules. Is it OK?
Zini wrote: Well, it is up to Nico. The standard you linked isn't compatible with the current code base and we don't necessarily need something that extensive. More importantly it has some points I very strongly disagree with and a smaller number of points that are plainly bad.
Zini wrote: Added basic support for Doxygen. Very basic though and not under CMake control yet. I have a bit of trouble making CMake and Doxygen play together nicely.

To generate the Doxygen documentation enter the following lines:

Code: Select all

cd Docs
doxygen
(Doxygen must be installed obviously)

The documentation root file can be found at Doxygen/html/index.html
best regards,
Lukasz

Locked