1

Re: Hot fixes and service packs

With major Recorder releases being fairly few and far between, and as more organisations and individuals rely heavily on the product, it seems that more frequent bug hot-fixes and service packs are required. Some of the bugs that get found, although not dangerous, can really throw a spanner in short and long term strategies. I was reminded of this with Janet Simkin's recent message re. exports and yet further import wizard problems with samples not grouping and other issues relating to Mapmate data not importing correctly.

What are the barriers to more frequent bug-fix releases and can they be overcome?

2 (edited by stevemcbill 16-01-2008 09:31:45)

Re: Hot fixes and service packs

I would agree with Charles that a more rapid ability to update with smaller bug-fixes (rather than the slower update procedure for new facilities) would indeed be a very good idea. However, my vote/request would be for an ability for Recorder-6 to search for updates from within the program itself and thence to download updates and install them automatically. Similar in a way to FireFox updates, Windows updates, Acrobat updates etc. What do people think ??

Cheers 

Steve J. McWilliam  :)

Steve J. McWilliam
www.rECOrd-LRC.co.uk
www.stevemcwilliam.co.uk/guitar/

3

Re: Hot fixes and service packs

I agree with both, they sound like good ideas.

Another idea is whether it is possible that part of any dictionary updates it then automatically rebuilds the indexes rather than the user having to do this manually each time, or at least to just have one button to rebuild all indexes in one go.

Brian

Brian Miller
(Conservation Officer (Buckinghamshire), BBOWT)

4

Re: Hot fixes and service packs

stevemcbill wrote:

. However, my vote/request would be for an ability for Recorder-6 to search for updates from within the program itself and thence to download updates and install them automatically. Similar in a way to FireFox updates, Windows updates, Acrobat updates etc. What do people think

That would be truly useful. I can't speak on behalf of Dorset of course, but this sort of functionality needs to be designed into the architecture of the application from the start, else the addition of such facilities might require quite a fair bit of work (Translation - Money). As such, given the constant and uncertain bug fix/feature iterations maybe this would not be high up on the JNCC todo list.

I assume Recorder.exe is a wrapper around RecorderApp.exe which is it itself just over 7Mb. There do not seem to be many DLL files (shared libraries) relating just to Recorder, at least not in the application directory. The MS5*.dll files relate to the Mapserver library. What this suggests is that the Recorder front end is a monolithic app and that any incremental updates would involve the download of the whole 7Mb(+) file in one go (Unless the architecture was changed to support more shared libraries).

Maybe we just need an external app that recorder calls to check a central update server and download the new front end and run against SQL Server any new alterations to the DB.

At the end of the day though, we need faster, less expensive bug fixes - the mechanism for distributing those bug fixes with a self update would be ideal.

Dave Cope,
Biodiversity Technology Officer,
Biodiversity Information Service for Powys and Brecon Beacons National Park.

5

Re: Hot fixes and service packs

Now that broadband is pretty much everywhere, I don't see a 7MB download as too egregious. I believe Firefox downloads a large .exe every time it updates (although this might have changed).

As a stop-gap for a more integrated solution, something simple like an RSS feed (that could also be subscribed to via email) announcing updates would be handy. But I do agree, "automatic" updates for both the application and the dictionaries would be very nice, particularly for individuals and less experienced users.

6 (edited by davec 16-01-2008 12:36:59)

Re: Hot fixes and service packs

Yes, 7Mb over broadband is not too bad. It's still a bit inefficient IMHO. Also, we don't have full broadband coverage here in Wales (but then we don't have many people using Recorder either).  But all of this is academic unless, as you say, the frequency of updates is increased. Given the development model of Recorder, this seems to always come down to funding issues. But, if the money is there, then yes lets get a faster release cycle going.

Dave Cope,
Biodiversity Technology Officer,
Biodiversity Information Service for Powys and Brecon Beacons National Park.

7 (edited by davec 16-01-2008 12:44:07)

Re: Hot fixes and service packs

OFF TOPIC: Charles, I notice your post count has dropped to 8. Just wondering.

Dave Cope,
Biodiversity Technology Officer,
Biodiversity Information Service for Powys and Brecon Beacons National Park.

8

Re: Hot fixes and service packs

Logged in under a different user. I probably set this one up for testing purposes when I setup this forum.

9

Re: Hot fixes and service packs

Back on topic - a while ago we discussed with JNCC the possibility of changing the way that Recorder is built to use a bunch of external dlls (the Delphi package library for those interested), rather than to be built with all required code integrated in one exe. Unfortunately it didn't come out at top priority at the time. This change would open the doors to converting some other parts of the code into dlls which would reduce the size of the core executable file considerably.

Dave, you are correct in that Recorder.exe is just a splash screen which loads the RecorderApp.exe, done this way to make the splash screen appear quickly. It would indeed be possible to make this application check an online repository for updates and if one is available, give the option to download and apply the updates. However this facility would not be advisable for people without local machine admin rights so we would disable it for others.

Question for Sarah - as to the dictionary updates, is there any possibility you could embed the changes to the INDEX_TAXON... tables in the updates so that there is no need to do a manual update?

John van Breda
Biodiverse IT

10

Re: Hot fixes and service packs

johnvanbreda wrote:

Back on topic - a while ago we discussed with JNCC the possibility of changing the way that Recorder is built to use a bunch of external dlls (the Delphi package library for those interested), rather than to be built with all required code integrated in one exe. Unfortunately it didn't come out at top priority at the time. This change would open the doors to converting some other parts of the code into dlls which would reduce the size of the core executable file considerably.

That is interesting to know John. An additional benefit is that the smaller DLL's might make Recorder easier to maintain especially if (and I think this is a big if) those DLLs were to become open source and allow more developers to work on bug fixes,  or use them in custom software perhaps.  Even closed source but with good API docs might help the Recorder software ecosystem.

One DLL I could really use is one that holds all of the SQL that the front end uses - just to help me from re-inventing the wheel when integrating Recorder into other systems.

One vote from me for external libs and online taxon dictionary updates.

Dave Cope,
Biodiversity Technology Officer,
Biodiversity Information Service for Powys and Brecon Beacons National Park.

11

Re: Hot fixes and service packs

Hi

Dynamic updates would be great but not sure it is really cost effective to develop this- an RSS feed (as suggested by Charles) seems like sensible middle ground.

We would also be worried about the updates becoming too dynamic and particularly the idea of breaking into separate dlls. This may create more problems than it solves, particularly when you consider that some updates involve changes to the database too. The thought of unpicking problems where the dlls and database have diverged is a little frightening.

Ultimately cost is a major barrier to more frequent updates for two reasons:

- We have a limited budget every year, certainly not enough to have a full support contract with Dorset Software (where they would rapidly fix any bugs that appear). As a result we have to schedule the time when we fix them. The main risk with scheduling a number of releases within the year is that if we use money early in the year fixing non-critical bugs, by the end of the year there may not be enough to fix more critical problems.

- In addition, we currently carry out approximately 6 weeks of testing before rolling out a version. One option would be cutting this down but that again might cause more problems than it solves.

However, we're open to ideas on how to improve this situation bearing in mind the above.

Our strategy from here is to let this next version bed in a little and focus on fixing any bugs (rather than enhancements to functionality), which should mean that you see quicker resolutions for the critical bugs reported over the next year.

In terms of the dictionary, we’ll look into the possibility of including updates to the index_taxon tables within the scripts we provide.

Best wishes,

Sarah Shaw
Biodiversity Information Assistant
JNCC

12

Re: Hot fixes and service packs

In response to this:

Sarah Shaw wrote:

Ultimately cost is a major barrier to more frequent updates for two reasons:

- We have a limited budget every year, certainly not enough to have a full support contract with Dorset Software (where they would rapidly fix any bugs that appear). As a result we have to schedule the time when we fix them. The main risk with scheduling a number of releases within the year is that if we use money early in the year fixing non-critical bugs, by the end of the year there may not be enough to fix more critical problems.

I posted a possible solution a little while back:

http://forums.nbn.org.uk/viewtopic.php?id=462

Cheers

Brian

Brian Miller
(Conservation Officer (Buckinghamshire), BBOWT)