After reading this thread on AW.net, it is clear that something needs to be done to improve the quality of software releases. IMHO, "but it's free" is not a valid excuse for sloppy releases.
The biggest problems (and pet peeves) are:
- No installer, or a poor installer
- The dependencies aren't installed with the application, and the user must track them down one by one
- Poorly working software
As I said in the AW.net thread, we need to encourage developers to make the effort to produce quality releases. We should also be looking for ways to make it easier for developers to do so. I know that there can be little motivation to write an installer when it took so long to write the app in the first place, but it really is important. The hardest part is creating version 1 of an app's installer.
For the first problem, I think that it would help if we had some more tutorials on how to write an installer. Are there any Installer gurus here? Perhaps tutorials on writing AmiUpdate auto-install scripts would help too. Actually, a tutorial giving the whole release process would be good.
Regarding dependencies, there are three simple ways in which developers can reduce the chance of dependency problems occurring:
- Use Snoopy to check which libs/classes/whatever-else the application loads, and make sure that the installer installs them
- Get other people to beta-test their installer and software (also helps for the "poorly working software" issue)
- Have a test partition containing a clean OS install so that you can test a complete install yourself
A small bit of effort can go a long way to making the user experience better.
If anyone is looking for an idea, a program such as "Advanced Installer" that automates the installer package creation process would be good. Something that eliminates the need to write the installer (and update) script completely manually.
Any other ideas on how to make it easier for developers to create quality releases?
Hans
No new ideas, but I fully agree. Theres not that much work involved in the dependencies thing, but often developers avoid this work. Thats a pity.
Coder Insane-Software
www.insane-software.de
Regarding Item 1>
I don't claim to be good at it, but I agree that a working installer script, with full version checking for each installed component, is crucial to the proper distribution of an app.
I find Item 2 to be far more difficult.
When a music app wants to distribute CAMD.library or usbmidi.fd, I encourage them to include a link to OS4Depot INSTEAD of actually including the files. I've already had at least one app developer that included OLD copies of these, along with an install script that would copy the old versions right over newer ones.
As a result, installing this app could break your MIDI setup instead of fixing it.
In my own opinion this is the worst possible outcome.
I have not looked into AmiUpdate yet. It may be the best solution to the problem. I only wish I could write install scripts that will run on a native install without additional software.
I wonder if any of the "new" languages can download a file directly from OS4Depot as the install script runs.. This would provide the "magic" of always getting the latest version, even if that version posted after the script was written. Of course, then we are dependent on a network connection and on OS4Depot to be working, but that would be a fair liability, if everything else was based on a bare, vanilla OS4 install.
Just thinking out loud, and I look forward to seeing what other ideas are posted.
LyleHaze
LyleHaze
@whose
It shouldn't be surprising that there are no new ideas here, as these problems have been around for a long time. I see it more as a problem of developer "laziness" than anything else. Of course, better tools could make it more likely that developers write the installers.
@LyleHaze
I personally dislike so-called "net-installers" that don't include all of the files. I want an installer that could also work if I had no internet connection. I don't mind installers that check for newer versions, so long as they still have everything that's needed if the connection failed.
There is no valid excuse for installer scripts overwriting a newer version of a library with an older one. The good old Amiga Installer has a function that copies a lib only if it is newer than the one already installed.
You really should look into it, as it would virtually eliminate the problem with bad installers. If a bad installer did overwrite the library, AmiUpdate would notice it on its next scan and update it. The auto-install scripts are really easy to write too. For example, if it only needs to update the lib, then it could be a one liner, e.g.:
copystore CAMD.library libs:Copystore stores an old version so that the user can roll-back if there is a problem.
Hans
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work
Hi Hans -
This thread piqued my interest as I am on the verge of purchasing the "Advanced Installer" product and have used other installers in the past (Installshield, brrrrrr....) and done some fairly hairy installs.
Here are my thoughts on bringing together the current "install/update" ecosystem:
1. Any prerequisite components must be available via AmiUpdate
2. Provide the prerequisites as AmiUpdate packages integrated into install package
3. Have the install script call AmiUpdate for each prerequisite, with the
following info:
- here is the package I have (with version info)
- either install this (if offline) or install this or latest version (if online)
- AmiUpdate will then decide which (if any) need installing, and from where
4. Predisplay to the user that the following prerequisites need to be installed first
5. Also integrate calls into ChrisH's new AmiSystemRestore utility. If the install fails part way through it can be rolled back. Also some way to tag all updates into one "event" for AmiSystemRestore.
I have some suggestions for AmiSystemRestore as well:
- instead of showing a file-by-file list, summarize by date
- also need some way of grouping updates so a single installer-driven update can be rolled back easily with a human-readable description
- I need to pass this on to ChrisH, although these are pretty obvious enhancements
In other words, a fair bit of ecosystem tweaking. Nothing that can't be done.
IMO at some point AmiUpdate and the new AmiSystemRestore should be part of OS4. These can then be better integrated with the new installer.
AmiUpdate provides everything you need as application developers to enable any dependent libraries etc to be downloaded at the same time.
This does require that all the required pieces are listed in the database so that AmiUpdate knows about them, but the process would be something like this:
Joe Code has written a library which may be used by a variety of programs, so he makes it available to the public on some website, and adds it to the AmiUpdate database.
John App decides to write a program around this library, and he uploads it somewhere for download. He too, adds it to the AmiUpdate database, and marks the aforementioned library as a dependent of his program. He can do this because the library is known to AmiUpdate.
Now a user decides to check for updates to the program, and when it appears in the update list, the library (which also has been updated) will be selected too. If the user deselects the library, the program is subsequently deselected, as it requires the library and you cannot update one without the other.
While this all sounds great, this is a system for UPDATES only, and doesn't solve the initial download of the program and not the library. That's a job for the application programmer and the library author to figure out.
Simon
I fully agree with Hans something definitely needs drawing up. A Developer code of conduct plus Python Installer documentation.
I would love to convert Jack's dos script installer into something more professional such as used in Timberwolf, but without any documentation its not something I cannot seriously persue.
AmigaOS.net - Discover Amiga, Discover AmigaOS.net
Jack for AmigaOS
Samba Idiot's Guide
I would prefer to call it "guidelines" or "recommendations." Apart from it sounding friendlier, this is closer to what it would be. It would be a set of guidelines and recommendations that people could use to make their releases better. A lot of it could be summarised in a simple release checklist. Actually, it would be more than that, as extra documentation and possibly tools would make it easier to follow the guidelines.
You could use the old Amiga Installer. The documentation for that is on the Amiga Dev CD. It doesn't look as nice and has no graphical abilities, but you can make a decent installer with it, and it does handle versioned copies (i.e., only copy if newer) and other stuff that installers need.
Hans
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work
Hi guys,
I've said it in other places recently, but I may revive my idea for an OS3 installer script creation utility, which should work under OS4 without any issues. Obviously an OS4-specific version supporting the new Python installer would be a better tool, but I don't see any harm in having both...
Engineers do it with precision.
I agree that this is an important issue.
However, do we have a good way of having an application install ALL of its dependencies? What about license issues such as a dependency that cannot for license reasons be included in the application .lha file? My XE has been in storage long enough that I do not have any experience with the AmiUpdate tool, I don't know if it can be used like many Linux package tools that know how to find downloads for everything and automatically retrieve and install each of them as needed. If AmiUpdate can do this for us, great! If not, we'll need something like that.
Also, how does one deal with commercial items? That may not be available as an online retrieval.
Does such a tool need to know how to search and parse on os4depot or aminet for dependencies located there? Is there a standard syntax to parse for in those places, or are things haphazard and will make parsing complicated? (I've seen some items replace previous versions while others have a bunch of releases piled up next to each other, is there a convenient way to pick the newest one or to know that a newer one is incompatible with the current app being installed and avoid it?)
I do agree this is a problem as evidenced by my many posts on this subject and also in that thread. :-)
The worst examples I can see are Linux ports that not only run in an unfriendly CLI but do not include a readme or instructions of any kind. This is unacceptable!
Now that's a lazy piece of work! :-D
IMHO a simple AmigaDOS installer script is good enough for simple things. But better include CopyStore inside the package if a library is needed. ;-)
Dependencies weren't a problems it seems years ago. Or at least once a system was built up most were at least satisfied already. Perhaps why it wssn't a problem back then and most stuff worked.
But now programs are getting complicated, even the simple ones, some requiring five dependants before it will even fire up! Now this creates a mess of its own as some programs will only be installed to support a superior one and so the question is where to install the files? If only a few files are needed where are these (or the rest) to be installed to? We need some sort of organisation here. We can begin with Work but then what? There is no standard. Following the directory structure of Aminet or OS4Depot may be a good starting point.
AmiUpdate is good but as pointed out it needs to have support for it to work. Not only that but if it can only be downloaded by AmiUpdate and no installer is provided then that system fails.
I see no problem with a "Dependency Downloader" that can download files and knows how to install them. OS4 features a TCP: device and one can easily write an ARexx script that can download and save files. I wrote such a one on OS3. It was similar to this situation as you gave it a list of files needed (in this case they were being checked on for updates) and it downloaded files if a newer version than on disk was found. It then even did a virus check and attempted to install them if it found a file with "install" in its name in the archive. A main server was given in this file and then a list of filepaths to check. Perhaps if further worked on and uploaded this system we wouldn't have a problem now. :-)
Perhaps what would be best is a package manager with supported packages and dependants that does all the work for you. I know I'd like that! But we do like to browse for programs to try out. On that note I also thought of a site that can include stuff to browse for installing and then one click on a button will use JavaScript to download and install for you.
Now for this type of system a location will need to be named for saving archives. I also think that possibly an external installer script could be written for software where few files are needed and a location for those files that are in "passive" use. I also think a separate location should be set for commands so as not to clutter up the system.
I also see two ways we can go about this situation. Programmers can put in extra work to make sure software does work. Or us the users can instigate such a system ourselves and write the installers for the programmers. Which means there is a slight crossover. A third alternate is for us to deploy some type of system that programmers would support but which the users would set up installers for.
Well that's most of my thoughts on the subject. :-)
Improving the quality of software releases
Great! This is my first post here and the site is really nice. I am very interested in this topic, as a developer and QA engineer.
For me, the quality of releases relies on the quality of software. I mean, I agree that efforts must be made on installers, documentation (or at least readme files), localization, dependencies. And we certainly require some tools to help. But I see other improvements that should be done.
Code quality
- Dependencies (libraries, MUI classes, ...) must be checked. Too many apps crash because there is a missing dependency. Generally, error codes have to be handled.
- There are many tools to help finding bugs: compiler with options turned on, splint to enforce more checks, ... Reading the code, cleaning and refactoring it also helps. Different compilers can also raise different problems.
Performance
It is also an quality factor. Why release a game port if it runs at few FPS ?
Profiling helps to find bottlenecks. This is why I wrote Hieronymus, a basic statistical profiler. It has already found problems in my projects. At the moment, it only works on AmigaOne but it is available (SDK, os4depot) and is easy to use.
Version Control System
Such a tool (like svn) should be used in all projects, even developed by one person. It helps to keep an history, allows to work in parallel in several systems, etc.
Bugs management
A bug tracker is also very useful. It is much more convenient than writing information on a paper or in a text file.
Tests (with examples)
Programs must be tested. I remember that I was asked to port PyGame. I started, I sent a report saying that there were some problems of dependencies with shared objects and that the JPEG part was not working. A release was made and users complained about the lack of image display.
For some programs, when it is possible, the developer should write a testsuite. For PointRider, I use a Ruby script that parse recursively a directory with all my PPS files. So for these hundreds of files, each file is opened, displayed slide after slide (there is an option to go to the next slide automatically), and closed. On Linux (that is more robust), I can log the files that assert or cause segmentation faults.
Obviously, having a well designed program with different modules help to test them separately (it's easier to locate problems).
Debug
The situation is not clear but I have hope with db101. Or gdb could help too.
Communicate
If a bug is found by a user, he should send a report to the developer.
If a developer finds a bug porting an application, he should mention that to the team that manages the projects or commit a fix in the project repository.
When releasing a port, it would be appreciated to find a diff in the archive, or a procedure to compile the project.
Things that could be done
In order to be constructive, here are some actions that would help:
- Write a guideline with compiler options and other tools that could be used
- Improve db101 and have a strong debugger
- Port valgrind to catch memory leaks
- Update svn with support of recent ssh protocols (some repositories / projects require that)
- Improve Hieronymus :)
- Get a simple bug tracker
- Fix and improve tools, including those that are in the SDK. I found some problems with expr, perl, awk, ...
I think this is tremendously important. Discussion about getting bounties going have brought out beliefs that somethings that a good debugger needs may be missing from the OS4 kernel, and that it doesn' tmake sense to put great effort into debuggers until these kernel features become available. I don't know what they are though. I'd hope that people that do have talked to those who can, and that something will be done about it.
duplicate
AmigaOS.net - Discover Amiga, Discover AmigaOS.net
Jack for AmigaOS
Samba Idiot's Guide
@Bilt
RE: Dependancies.
I thought about dependancies for a long time in the development of the App-Store in Jack and whether such a system could be put into place.
Dependancies can be: a library, a command line program, an sobj, a datatype, a handler or even a required font... in short lots of variations.
Well written programs/dependancies have a standard $VER string attached to them, some dependancies of course do not support this so you have to instead refer to the modification date of the file.
And so imagine this as a solution.
Every archive that is uploaded to OS4Depot/Elsewhere has a file inside its own archive in the root drawer, lets call it 'dependancies.xml' for arguments sakes.
This could be set out like so.
So a user picks an application to download, Jack begins downloading it, when finished it auto-extracts it, then PRIOR to launching the installation script inside the archive (which it does already btw if there is one) it reads 'dependancies.xml' and goes away* downloading from the Dependancy URL, extracts it to a temporary location, hunts for the Dependancy Filename and when found copies it to the Target Drawer (or the Expected Final Location if Auto Install is set to True).
If there is more than one dependancy listed in 'dependancies.xml' it goes and does them too.
Once all the specific dependancies have been dealt with, temporary files are removed and the application's installation script is launched asynchronously.
Sounds do-able to me. In other words a standard XML file in every archive is required containing dependancy information.
---
* It would of course first check to see whether the dependancy is already installed in the Expected Final Location.
** If Auto Install is set to true Jack installs it itself or if set to false the regular installation method will take over this responsibility.
AmigaOS.net - Discover Amiga, Discover AmigaOS.net
Jack for AmigaOS
Samba Idiot's Guide
@djrikki
If dependencies are going to be checked and downloaded at installation time, then I think that this should be the installer script's task, and not some external application. Apps won't necessarily be downloaded only using Jack, and so the install script should be able to do all of the work on its own.
To make it easier, this functionality could be built in to the Amiga installer.
Hans
Join the Kea Campus - upgrade your skills; support my work; enjoy the Amiga corner.
https://keasigmadelta.com/ - see more of my work
Of course I agree.
AmigaOS.net - Discover Amiga, Discover AmigaOS.net
Jack for AmigaOS
Samba Idiot's Guide
Well, here's my basic installer creation utility so far...
http://www.robthenerd.com/pics/installergen1.jpg
(I think it's too wide to post here...)
Early days yet, but you get the idea. Dependency checking is way down the list (have to get it working properly first!) but should be possible at least at some level.
Engineers do it with precision.
As the author of db101 I can state fairly clearly what is missing for us to have a proper debugging platform. As some may know, we already have a dedicated "debug" interface in exec, the remaining issues will be improvements or additions to this interface. Roumors have it, that this is already taking place, but I don't know if this is "secret" or not...
1) Bugs in the system: There are some issues with the IP and the MSR register in system handling that needs fixing. Have reported it long time ago, but don't know if it has happened yet.
2) A feature of the debug interface to identify shared objects needed by the main executable needs to be added.
3) There seems to be something wrong with the stabs output from gcc. For this reason db101 currently only works properly with projects consisting of a single source/object file. Either that, or I have been very bad at interpreting the stabs standard...
@alfkil
While we a bit into offtopic, but related to bugs which you got with db101 (ip/msr stuff) and which you report some time ago, we can think that they was fixed because GDB start to works normally after update3 (and i remember, that the problems which you have with db101, was the same which prevent GDB to working fine before).
Maybe it worth to try now again with update3 to check it again via db101 code ? (i can help with betatest as usuall).
@kas1e
Nope, they have not been solved with update3. I don't know if Thomas has found some other magical way of dealing with this stuff or not.
I didn't get the time yet to look into this particular problem.
What CPU are you testing this on ? AFAIK, not all CPUs implement the trace bit properly.
Debuggers usually solve the single-stepping by writing breakpoints (trap instructions) at points in the code they want to stop at. This makes "more sense" than the trace bit since most of the time, you aren't interested in the effect of one single machine instruction but rather the result of a line of source code. That's how gdb does it.
@tfrieden
I am using a SAM-flex.
I did an implementation in db101 that uses breakpoints (trap) at the next comming instruction. But how can gdb then deal with stuff like "trace into", if there is no way to tell if the next instruction branches or no??
Also the ip bug is at least a little irritating, and maybe fatal for some projects, because it makes it impossible to just pause an app and see where it "lands".
Also it is impossible to get any info at all from the ExceptionContext unless some trap instruction has been executed before. That is unless there could be some system compliant way of getting a pointer to the ExceptionContext from outside a debug callback...
@ afkil
I think the 440 is among the CPUs that do not implement the trace bit. I'll have to check.
I don't know how gdb solves the trace-into problem specifically, but if I would have to implement it, I would simply look at the instruction when trying to determine the next instruction address. Branch instructions on the PPC are pretty simple and straightforward, and in general, the PPC instruction set is relatively easy to parse (just look at the upper 6 bits in the instruction word, this is the actual opcode, the rest is data, or the sub-opcode if the upper 6 bits are all 1's).
What is the IP bug that you are referring to ? I'm not aware of anything like that ?
Also, regarding the context of a program: If you mean that you can not simply look at the context of a stopped task, yeah, that's not possible since you can only get that information via a debug hook which requires that the task stopped for some reason (trap, opening a shared library etc).
I can include a function into the debug interface that will let you get a pointer to any task's context, if that would help you.
@thomas
I would be very happy, if you would implement such a function!
About the IP bug, I will resend to you my original bug report, which contains two test apps, one to show the msr issue and one to show the IP problem. Check your email! ;-)