2.1.n Feature Request Discussion

[bdbcat]

Hi folks...

OK, its official. I am officially swamped out. I've run out of hours in the day.

With my intermittent net connection, and allowing for some time to do coding, I cannot keep up with the traffic. I know I am missing good suggestions here, and I'm afraid they will be lost in the bit-bucket

I would like to enlist interested Forum participant(s) to help prioritize/organize our growing lists of bugs and feature requests.

Here is what I envision:

0. Add volunteers as write-enabled sourceforge project members.

1. Use the sourceforge bug/Feature Request/patches trackers exclusively as the "TODO" list.

2. Designated volunteer(s) will extract items from the Forum, reformat as necessary, assign meaningful priorities, and add to the trackers. I reserve the right to modify priorities Volunteers will scrub the trackers occasionally, to bump priorities as necessary, and remove obsolete/redundant/outdated items.

3. Forum can continue to be like it is, i.e free form town-meeting style. Forum posters who feel strongly enough about an issue should be sure that the issue is elevated to the trackers, and may negotiate priorities.

4. I, and other developers, will work on items from the trackers. Ad-hoc suggestions on the Forum will (usually)NOT be worked on until added to a tracker.

5. Private emails to me with patches should (must?) have a corresponding tracker item with notes attached. I get about 20 emails/day regarding opencpn.....

One example of the problem we are trying to solve:
In 2.1.0 Build 624, a simple bug was missed. It was a regression problem, popped up 2 days before release. Cagney found it, posted it, and I missed it. Build 624 needed a quick fix to make 624a. This kind of thing is aggravating when we get hundreds of downloads on the day of the release. Now we have potentially hundreds of users with a problem which we will hear about later.

In my new model, a regression problem found very near a Release date gets a very high priority in the tracker, and we don't release with any such items open.

The sourceforge tracker system is admittedly slow to interact with. IMHO, sourceforge has made their development site support too "pretty", with lots of static image downloads that bog it down. But that's what we have today.

Anyone know of a way to add tracker functions to our .org site? I'm interested.
I guess it could be done as a wiki, somehow???

Comments? Volunteers? Feedback? Other ideas?

Dave

[seandepagnier]

We could run a trac wiki with the git trac plugin on our own website and it would give us the tracking that sourceforge could supply, but without their slow servers. I could try to set this up if I had access.


Also, it would be cool to give developers write access to their own branches, then you could just merge the branches whenever you like, but not risk ever breaking the master branch. If I could do this, I would probably continue hacking opencpn, right now I am waiting until my patch is accepted because I don't want to do any more if it is not.

Both just ideas, I would like to work on opencpn no matter what!

[Netsurfer]

Dave,

Originally Posted by bdbcat

Anyone know of a way to add tracker functions to our .org site? I'm interested.
I guess it could be done as a wiki, somehow???

See: Storm (project management application) | drupal.org
But I personally think that using a script that was just written for that purpose will much better.

Comments? Volunteers? Feedback? Other ideas?

Also I vote against geckosenators suggestion to use Trac and combine it with X and Y and ...!
The more things are concatenated with each other the more difficulties you have in case of switching to another script, server, etc.

And is there really any advantage?

As mentioned before - I would use a light-wight script like start - Flyspray - The Bug Killer!

... and perhaps make it accessable through something like "bugtracker.opencpn.org/".

Gunther

[bdbcat]

Netsurfer....

Tell us more about Flycatcher... demo on their site is 404....

Thanks
Dave

[Netsurfer]

Dave,

Originally Posted by bdbcat

Tell us more about Flycatcher...

I have set up a test installation for you to play around with it ... .
I mailed the needed information to you.

Gunther

[nohal]

Dave,
you have a point, the forum really got hard to follow even after just a couple of days off. No problem helping with the tracker issues in the areas I understand.
As own bugtrackers go, I have a lot of experience with the following:
Mantis Bug Tracker - On the "market" for a long time, written in PHP, fast, did the job well for for me with thousands of bugs and dozens of active users, pretty reasonably extensible, focused primarily on bugtracking, last versions extensible with wiki etc. though.
Then used The Trac Project - as a more complete "project management" solution - written in Python, personally think a bit slower, did the job pretty well and included wiki and source repository interface out of the box. The development seemed a little slow though. At last I replaced it with
Redmine - Overview - Redmine which is very similar, subjectively a bit faster than Trac, but still slower than Mantis, written in Ruby, because it supports more projects at the same time and much better user administration than Trac, same as Mantis. Still use it but it lacks API so integration with anything is a bit more complicated (believe me, I have written a desktop client to interact with it and now regret...)
If we need just the trackers, I would definitely choose Mantis or something similar (Flyspray). The other question is the technology used and the will of server admin to maintain it.

Pavel

[Netsurfer]

Hi,

Originally Posted by nohal

If we need just the trackers, I would definitely choose Mantis or something similar (Flyspray).

I do very much believe that this is the first question to be answered. So what is the goal to achieve with the new script/ system?

And imho another important point is: Users should be easily able to add/ post their reported bugs (and/ or feature requests).

There is already one wiki at opencpn.org. So if the used syntax/ system by another (new) wiki is different this wouldn't be very good for the usability (for most users it is already hard to get used to one wiki syntax/ system).

The other question is the technology used and the will of server admin to maintain it.

I guess this shouldn't be that difficult ..., but
Dave wrote about his plans to modularize OCPN. This seems to me to be a very important point and a possible solution should be able to deal with it. I do not have sufficient personal experiences with any bugtracking script to judge the different scripts.

But every future module is like a small version of OCPN with all the discussions, feature requests and bug reports. So maybe it is time for OCPNs own discussion forum where there are subforums for each module, version of OCPN, etc.?

Gunther

[nohal]

Originally Posted by Netsurfer

And imho another important point is: Users should be easily able to add/ post their reported bugs (and/ or feature requests).

Exactly. The easier the reporting interface will be, the better. Here we have the first criteria for choosing the right one...

There is already one wiki at opencpn.org. So if the used syntax/ system by another (new) wiki is different this wouldn't be very good for the usability (for most users it is already hard to get used to one wiki syntax/ system).

The second one. No need for wiki and so on, as there already is one with which at least some users are familiar.

I guess this shouldn't be that difficult ..., but
Dave wrote about his plans to modularize OCPN. This seems to me to be a very important point and a possible solution should be able to deal with it. I do not have sufficient personal experiences with any bugtracking script to judge the different scripts.

But every future module is like a small version of OCPN with all the discussions, feature requests and bug reports. So maybe it is time for OCPNs own discussion forum where there are subforums for each module, version of OCPN, etc.?

I think cruisersforum does a very good job here at least for now. Making the tracker itself usable and not discouraging the normal users is quite a big job by itself. I've participated in it in a company environment, where there were "powers" to make people use it, several times and it can be done very wrong... The resources available are limited so we should try not to waste them for stuff we will throw away later. Anyway we have a third criteria: The tracker has to support modules and/or subprojects.

Pavel

[cagney]

Dave

You're paying for the success of OpenCPN
Whatever way the bug/request tracking will be handled, I'm prepared to help out.

Thomas

[bdbcat]

Friends...

I took a look at a FlySpray demo (thanks gunther).

This looks like it will meet our basic needs.
Roughly equivalent to sourcforge trackers.
Tracks bugs and feature requests.
Supports categorization, which we can use for plugin tracking.
Seems fairly snappy, at least for this small hosted demo.

Anyone else had any experience with Flyspray?


So, what would it take to get Flyspray up and running on opencpn.org? Any other hosting options? Any volunteers to work this plan?

One problem we have right now is that Manimaul, our webmaster, is otherwise occupied this summer off site, and not available every day. So we will have to muddle through without him.

Anyway, lets try to move this plan forward.

Dave

[Netsurfer]

Dave,

Originally Posted by bdbcat

So, what would it take to get Flyspray up and running on opencpn.org? Any other hosting options? Any volunteers to work this plan?

Hosting shouldn't be the problem. Depends on under which (sub)domain the tracker should be reachable.

One problem we have right now is that Manimaul, our webmaster, is otherwise occupied this summer off site, and not available every day. So we will have to muddle through without him.

What kind of webspace is it where opencpn.org is actually hosted?
Is it just preconfigured webspace or a V-Server? As Drupal is running on the webspace there is at least one MySQL DB available.
Flyspray needs PHP (4 better 5) and a MySQL or PostgreSQL DB. The setup will take only 5 Minutes plus the basic configuration.

On the other hand a possible solution might also be to (upgrade or change the webspace for opencpn.org if necessary and to) add another Webmaster.

Of course I'll offer to host the Flyspray script on my webspace (the actual demo).

So let me just know, if I can help or support the project in any way.

Gunther

PS: The reason why I am writing less here in the forum is that I am working on an interactive help for OCPN. There are many drawbacks and it seems that I have to make some compromises and of course it is only working in modern browsers ... .
But maybe it is of a certain use for some users. I hope to be able to set a demo online by the end of next week.

If someone here has some knowledge of Jquery (1.4) and/ or is interested in the developement of the interactive help, please contact me (via email or PM) for further information - thanks!

[bvimatelot]

Probably the wrong Opencpn thread, for which I'm sorry.

However - I've been using version 1.3.6 and I've got used to it and like it! I'm a little bit frightened of going for version 2.1.0 - is it stable? Does "quilting" slow your computer down and is it really all that necessary given that you can choose the best chart from the bottom bar?

One last point. When my computer goes to sleep, on resurrecting it, I almost always lose the gps and have to restart. Is this common and is there a fix (other than not letting the computer sleep)? Many thanks, Tony (Apologies if this is the wrong one of so many OC threads - please feel free to move it)

[jimbo3123]

It would be really nice to have an "Apply" button on the settings screen so that I can play with all of the different configuration options without having to re-open the settings every time I want to test something.

[HamishB]

Originally Posted by bdbcat

1. Garmin private protocol support.
Background: In my circles, a common configuration for sailboats is a PC at the nav station, and a waterproof garmin chart plotter at the cockpit helm. The idea is to do your planning, route layout, etc. in the warm cabin, then upload routes to the Garmin unit for guidance underway. The Garmin may be the NMEA source for the autopilot. We don't do this very well now. Modern Garmins will not upload routes using the generic NMEA format. We need to implement the proprietary, but well documented, Garmin protocol.

to avoid reinventing the wheel,
* for real-time just use gpsd which knows garmin's USB-proprietary
* for wpt/rte/trk up/download to unit use "Viking" or gpsbabel
https://sourceforge.net/projects/viking/


regards

[fireball]

First off - thanks guys for an excellent program - I'm just getting to grips with it - and nicely had it showing on my iPhone in the cockpit - whilst the netbook was down below ...

AIS request please:
CPA and TCPA alarms seem to be for all AIS targets - it would be nice to have a toggle switch to turn of alarms for Class B targets (as where I am these are mostly other yachts which we keep an eye out for anyway! - its the class A bods we're interested in avoiding!)