navit-project.org

Hi, during the FOSSGIS conference at Berlin, 3 of us had a nice meeting and discussed a lot about Navit, TMC and OSM. One of the topics was the future of navit as the absence of our maintainer.

The problem:
I tried a lot of times to contact Martin (cp15), without success. Once we had a call and he promised to give feedback, but sadly he didn't. So we just know, that due to heavy workload on his job, he seems to be unable to contribute or maintain the services.

I will try to summarize what we identified as problems of the absence for the community:

• no root access to services (QA service , map buildservervices, configs/workflow itself, ...)
• noone who can introduce new devs to the source and architecture
• noone that takes (design-, ...) decisions
• no progress on heavy/complex bugs
• noone who can spend for 0.5.2 progress

Currently this doesn't seem to be a problem on minor tasks as we can submit code, maintain wiki/trac, ... on our own.

Our discussion had no final result/plan on what we should do. We had just a few ideas of what we can do:

• hackweekend/online screencast to introduce more people on navit architecture/compiling/... so they get able to contribute code.
• move over to new servers
• restart/fork codebase and establish new project

It's very hard to say what is a good solution to get Navit on the road again. During my time here I learned that massive changes cost a lot of time and have a good chance to fail. So I guess a getting together and learning from each other about the basics is the best way to continue in the next months. But what doe you think?

Hi,

it's good that you are planning for the future of the project. I have also noticed that cp15 is less and less active.
My last contact was in January (where I received a nice and helpful response), but I have not heard from him since.

Still, I think the problems this may cause can be solved:



While having cp15's contribution would be a big help in these cases, I think we can do this even when he does not have time. We have others who know the code well, and can introduce others or tackle bugs. So I'm optimistic about this .



Yes, that could become a problem.

As far as I can see, we have the following services:

• web site http://www.navit-project.org/
• Navit wiki
• code repository
• trac
• auto-builder (result page)
• map extractor

AFAIK trac is co-maintained by KaZeR, and the SVN repo is on sourceforge.net, where we have multiple admins. So the problematic services are the web site, the wiki and auto-builder and map extractor. We will have to discuss this with cp15.

Of course we could just fork Navit, but I don't think this is necessary right now. For all we know, cp15 may be back in a few months . If not, we can still ask him how to proceed - maybe he agrees to give admin access to others, or provides us with a data dump so we can set up the services elsewhere, if he wants to. And even if we should never hear from him again (which I do not hope), we will manage.

For now, we should concentrate on fixing bugs and introducing new features. If the lack of access to infrastructure causes a problem, we wil have to think about it. Maybe we can formulate a mail together to send to cp15.

Since I just came home from Berlin, where we had this nice meeting with usul, I will keep my answer a bit short for now. The situation is well summarized above.

I basically agree with sleske. For now we can proceed to fix bugs and there are some people who can take other tasks as well. If it really turns out that there is a problem which we cannot solve without help from cp15 or by taking these "drastic" measures listed above, we should do our best to contact him and ask him for a suggestion how we can proceed.

@sleske Yes it's like you say. We can run into problems on a short and on the long scope. For the next months I guess the challenges are to fix heavy bugs that are caused by the internal architecture (Cmake switch, alpha bugfix, generalisation strategy, ...) so we need devs that dare to take the nessesary steps.
On the long run it's about the essential services and that we are able to alter configs or the software that is in use.

Just to make clear, it's not about 'kicking cp15' it's about how we can make sure that Navit will be able to exists for a certain time without his help.

P.S. I pinged Martin about this post, maybe he can add his opinion/tips.

Hi!

I think our most important problem is crew having lack of time to contribute to the project. And I'm sure we'll find a way to grant svn access to new devs, if they happen to come to the project.

cp15 is not gone. He's around and taking part in fixing problems which the rest of crew can't fix. A few days ago he responded within hours to bring our database server up. He's not just silently fixed the problem. As for today, the same problem, if it will reintroduce, could be solved without cp15' help.

We have root access to our servers. We can reconfigure services if a need rises.

We seem to have no hardware resources to bring up new services (like jenkins) though. BTW, if somebody could contribute resources and effort to configure one, it could be quite helpful to improve our QA.

We're doing all what we can to introduce new people to architecture/help compiling/using navit.

I don't see any reasons to fork the code, to move to different servers, etc. Let us focus on things that improve navit, not on those that will split our small development team or just take our time into endless political discussions.

tryagain.

I'm not sure, but if I'm right KaZeR said he has some ressources available. Not sure if he has time to setup an CI for Navit, but this would be great and give me a ability to contribute tests.

I understand your POV and yes, I want that Navit goes further and not to blame the maintainer etc. But, if nobody has an idea about what is happening and we don't see a vision/roadmap/plan/... of how the team can proceed, I guess it's worth to talk about it.

I guess the main problem here is not about contacting our maintainer, but rather a lack of active people in general. Development and support take time and need active contributors. I think we have a quite good roadmap (mainly thanks to your organization of a new 0.5.1 version), we mainly need to work towards it.

I've been working a lot on testing and CI lately. We now have a process where we can have builds automatically triggered to run tests and / or build packages ( this works for Android too ).

Any help on this would be appreciated, as the lack of automation in testing is probably one of the things that slows us down a lot ( and makes it difficult to push changes or new features ).

That sounds great . Thanks for the good work!

This is also very helpful because during development it is very difficult/impossible to test changes on all supported platforms (of which we have many). Having automatic builds for all platforms helps find at least the worst mistakes quickly (happened to me already ).

I will gladly help in setting up / maintaining these automatic builds. I have some sysadmin experience and know CMake reasonably well, so I could for example assist with getting all builds running smoothly, cleanup scripts for logs etc. How can I help?

I agree, it's tedious and almost impossible to test the impacts of a change against all the possible configurations now. That's where CI is useful.

I'm testing the following framework :
- code and do some tests locally
- push to a "staging" branch
- this triggers the CI that runs the predefined tests and can build screenshots ( for docs, or review ) and packages ( including android ! )
- if the tests pass, the CI merges the changes into a master branch

This has a few advantages :
- if we add more tests we can code with more confidence
- we can know in less than 10 minutes after a commit if we broke something
- we can have binaries for each and every builds that succeed
- we can setup alpha and beta release in the Play store, instead of having a 3 years old version
- we can have a master branch with a code that is known to work since we merge only if the tests passed
- all the computing ressources for this are offloaded to a free 3rd party service, it avoids putting more stress on our own servers
- this is mostly based upon documented industry standards instead of using obscure, undocumented home made scripts

This has a few drawbacks :
- the current test process is based upon git, i can't get to something close using svn for now
- we need to spend some time implementing tests

Sleske, I'd be happy to get some help on this as this is a huge task. We can sync up on IRC or i can start a post / wiki page with more details if you want to contribute.