navit-project.org

Currently we recommend people to use the latest SVN builds. But the past showed, that this releases can be broken. This can be for only some platforms or to introduce global bugs or cause problems with data from various maptool versions.

IMHO we need to remember, that Navit is a navigation system. So users ger really frustrated, if it's not working out of the box and doesn't fit the min. requirements. I think for that reason, we need to establish some better testing. Very close to that is that our plugins/API require some semi static compatibility checks, to work with the uptodate interfaces.
This testing processes will take time if it should be done right and for all of our platforms, so we need a lower release frequency. If we see our logs, the most changes were minimal (from a enduser POV) and so, I don't see problems if we only publish a stable release every few months.

Another point is that a roadmap planing requires fixpoints for scheduling and to determine the expecte release date.(Here maybe better tool support is requiered but TRAC offers at least very limited possibilities).

Last but not least, the most ditros/repositories use release based distribution and seem to have currently problems to pick good SVN versions for building packages. This means for us, that people require a lot support, because the versions differ very much and sometimes they need to build their own (more uptodate) versions from scratch.

As planing a release needs good tools, I recommend to abandone from TRAC:

• not sexy to endusers (complexity, design, ...)
• very limited planing ability
• messed up with a lot of bugs/issues that haven't been reviewed

So here comes up what we IMHO need from a new issue tracker:

• consumers: easy to use (simple and sexy)
• dev team: manage issue history, attach to multiple components, tracking the os port(s), work together with VCS

Personaly I don't like this ones, as they aren't friendly enough to endusers: Launchpad, bugzilla
Github, Gitlab have pretty good usability but are very limited for planning releases
MantisBT look ok, but user:pini pointed out, that it has a bad workflow.

Currently I test redmine and you can do it, too:
https://oneofx.draco.uberspace.de/redmi ... navit-test
The only thing I miss is the assignment to multiple components and that it introduces time scheduling/reporting. But it has a very attractive UI and is very customizable.
My last alternative is Flyspray.

Actually, I rather like trac. It is reasonably simple, and I think much less intimidating even for endusers than e.g. Mantis (which I have used, and which is good), or even Bugzilla. I don't think that is a good reason to change BT.

Hm, there are some planning functions (assigning tickets to milestones). I'm not quite sure what else might help in the BT? Isn't release planning better done in the wiki?


I don't hope you seriously propose this as a reason for switching? That's not a problem with trac. Anyway, I'm slowly working on closing old bugs...

Anyway, thanks for thinking about the development process. I don't really see the need for switching BT, because I like the simplicity of trac. But we'll see...

Well, if most the team are ok with TRAC, I don't want to introduce a change (that causes work in short and long run) against odds But please also take care of the usual enduser perspectice. There I heared a lot of times that most people had problems with submitting stuff via trac :/



Maybe it's not that easy. Yes you are right, making a general plan ("the next release should care about usability and include features ABC") works fine. Personaly I see some problems, if we want to create a roadmap (getting release xyz means fixing tasks 1..2.3...n) as it might confuse users, when 20+ items come up. And we can't share any status about the progress and dependencies :/



No thats true, that has nothing to do with TRAC in general (but our trac in focus). If we get spammed by tons of issues with a undefined state, it's hard to do any planing.
But yes, they need to be checked and even assigned to a release. Maybe you can show us how we might start a cleanup drive?

Hi, after thinking some more time about our possibilities, I guess using TRAC will do the job. But this requires, that we cleanup the tracker, to reenable us to plan releases etc. Another task would be to update to newest TRAC version and to add some plugins/themes to match our requirements. Mayber user:tryagain or user:KaZeR have experience in such migration?

Yesterday I had a chat with user:cp15 and he suggested that I should care about further release planning. Personally, I'm not sure if I am the right person, because I lack of good coding skills and FLOSS project management experience. For now, I would do it (because I don't expect that somebody else will do it) but only with the team and as some kind of moderator (than manager). Would that be ok for you?

My idea would be to form a next hotfix-release as 0.5.1 that tries to introduce stability to endusers, without putting energy in new features. That would help us to reduce the amount of support. This means skipping currently instable/unmaintained features, too.
The next step would be 0.6.0 release that should become a specific topic. I would like to put a focus on usability, as Navit allready has cool features and mostly robust functionality, but the UI is not that good that people see that right now. This would also include features like a map download manager, exchanging styles and maybe a better UI for preferences.

I'm very happy to hear, that you and cp15 are coordinating the releases now.

Your plan with 0.5.1 and 0.6.0 sounds good.
But I think that some kind of download manager is one step to far away. Before you/we use a DM it should be easy to include a different UI and OSD just by adding a specific file to a specific directory.
So to say improve the usability for 0.6.0 and in 0.6.1 add a DM for these tasks.
And then 0.6.2 add a menu to change a UI in navit - so you can just run navit with pre-defined "skins" and change it's appearance some kind of "live". F.e. add/remove buttons for zoom in/out, voice enable/disable and so on...

Iirc in winamp and vlc you still have to put skins in predefined directories - and nearly everybody can do this.

So making the code able to accept such files would be the first step (and a adding a settings-menu for selecting a specific OSD/GUI as the preferred - like the routing options or selected car option)

I prefer smaller steps in stable/usable releases than big ones.
So 0.6.x would be the usability release, each smal step with new features that work.

Thanks for sharing your ideas ZeroOne

Good to hear, that my ideas are somewhat ok for you. Maybe I need to add, that this are currently only very raw ideas, that just illustrate the way that I wish that navit development will go trough. There is nothing final and yes the DLM is a heavy feature, maybe it's better to add a configure/first start UI before. And yes, the mechanisms to modularize/exchange ressources and configs are on the way and a basic step to realize all of the more advanced features to share ressources or let users config anything.

Just a few words about the version numbering. I know that minor numbers are dedicated to bug fixing releases and majors are reserved for bigger changes (that might break compatibility etc.). Oh and 0.6.0 is not half of the way, as there might/will be a 0.11 etc. as we don't have a formal definition of what should 1.0 looks like, I think it's quiet ok to us such small numbers.

What do you mean?
Use 0.6.x for new features or do you want to use 0.7 for any new features and 0.6.x for bug-fixes?
I think both versions are ok - changing the second number while adding a new feature will show a more active project than just bugfixes.

Yes, 0.6.x would be just for bugfixing and 0.7.0 would introduce new features. Thats what I noticed at other projects, but maybe user:pini as a packager has there better ideas. I even have no problems, if we just define 0.0.x as very small steps and 0.x.0 as bigger steps.

I started a wiki page to collect ideas for the small but stable release:
http://wiki.navit-project.org/index.php/Release000501
Would be cool if the devs who are currently active could contribute. Please keep in mind, that this is just a raw "masterplan" and no schedule. So we can form tickets out of this ideas and assign them via trac to the new release to get a overview on what tasks need to be done and how long they will take. Later on we can trace the progress and trigger on the single stages thanks to a updated trac (implementing, bug fixing, testing, releasing, ...).

As a Debian user I'd like to help making .deb packages for debian and debian-like OS like Ubuntu or Mint (iirc).
But I never did this before so I need to get familiar with the process.

BTW: a friend of mine showed me his double-Din Car-Android-Radio and said to me he's looking for a good routing application. All of you know what I've told him to use but I also added, that he should use the .apk from thenait server rather than the app offered in the Play Store.
Actually I don't know if there's a good OSD for his quite big screen. - This minimalistc OSD is great when using a smartphone, but on a tablet or this "radio" it's some kind of useless.