LinuxAX25 History

In Oct 2005 Craig Small passed on maintainership to us, DL9SAU and DL5RB. We immediately updated the contact details on the Sourceforge website.

We started to add the pending software fixes which were discussed at the linux-hams mailinglist. And we revised and added all the patches from the ax25.sf.net bugtracker, which sat there for quite a long time.

Because there were problems with sourceforge.net (a CVS checkin (In simple words, CVS is a system to maintain the history of all changes to a software project) to a software project]took more than three months until the internal system has shown it up in the public part of the CVS) we decided to give the linux AX.25 collection a new home at linux-ax25.org. Being root, it gives us all the opportunities we may need.

Starting with our Server linux-ax25.org, we first imported the complete CVS tree. Special care was taken that the CVS commit messages (who has when changed what and why) of the whole developement history were kept: We had to import the whole history by hand/automatic scripts, which was a real pain, because sourceforge provided no simple way to get this data in realtime, and due to their problems we did not want to wait 3 further months. This traceability is an important thing in Software development, and it was also a major goal at our work.

 The CVS repository can also be accessed with a web-browser (cvsweb
 shows details of every piece of change).
 URL: http://www.linux-ax25.org/cvsweb

 The Wiki documents details on how to download and compile:
 URL: http://www.linux-ax25.org/wiki/CVS

We also discussed if we should switch over to SVN or GIT instead of CVS, and ended in the opinion that everyone who develops knows how CVS works, and the features the CVS system offers are good enough.

We left the download links to the latest relases on the ax25.sourceforge.net site untouched. From todays point of view this may be was a mistake, because people may consider the project being dead. The reasons which lead to this decision were:

• Nobody knew how many linux discributions automatically build packages from this download link and what damage the removal could cause
• We needed time for development. If i.E. people have problems (bug, compatibility, etc..) with software at an arbitrary point during this phase, or if there's a security problem, it's not easy to track the error.
• Users mostly do not compile their own software. They just use the "know how" of their favourite linux distribution.
• Developers knew about the new home, or just sent us an E-Mail or chated with us on our wconvers channel.

Time went on, the software became more and more stable, but we needed some more steps for a "release". Some times, GNU automake changed, sometimes the new gcc compiler began to complain things (where their ancestors just did their work) and sometimes we had an issue with new include files or the behaviour of a new glibc.

On the other hand longer the time took, the more the truth for all software became perceptible: there never will be an end. It's an ongoing process. This is the main reason why there (still) is no new version numbered release like ax25-apps-0.0.6, ax25-tools-0.0.8 or libax25-0.0.11 which are the latest official released tar balls and stem from the sourceforge era.

Since we always tested our code before checkin to the CVS there was nothing to worry about at when point of time someone checked out the sources. Most people had the CVS extracted at home and from time to time did an CVS update.

Keeping this in mind, we encouraged maintainers of linux distributions (who contacted us) to periodicaly check the changes on the cvs. This is apparently not a new idea. You may look at your favourite linux distribution and their experiences over the years: Either they said "we need to get solid as a rock". They froze their applications, needed 2 to 3 years for their release, and when it came out it was so antiquated that no one liked to use it (either because it did not had all the whistles one expects from modern systems, or because it's so old that important features were not available); never mind, the freaks always used the development system, and thus the old release was not a problem for them.
Other distributions went another way round: they have release cycles of half a year and an easy upgrade mechanism. With this kind evolutionary process nobody cares of libax25-version-f00-bar.

 Link to the archived ax25.sourceforge.net Homepage:
   LinuxAX25_Historic_Homepage

Famous last words

We always encouraged to submit error reports and patches or help us for the goal of a release. There was feedback, but not enough.

As of Jan 2009 there was a strange discussion going on the linux-hams mailinglist. We've to point out that

• The project is not dead.
• DL5RB and DL9SAU are the maintainers. They usually answer in less than 24 hours.
• Patches and fixes have to be sent to us. We could only incorporate things we have cognition about.
• Nobody could clame the stability of the software, nor the modernity, nor the good quality of the code.
• Nobody who ever asked has gone without a satisfactory answer for his request or problem.
• It's in fact not possible to read the list the whole time. Posting something to a list is like pinning a bugfix on a beer mat in a disco in Timbuktu.
• Discussion is important. But the claim that "the community is on the mailinglist" (where tons of other problems were discussed) has to be declined. That's the way open software goes? - Indeed, it's one way, unfortunately, and often enough. But it's not the correct way. If you have a problem, go to the maintainer. If you want to play with, ask to join. Want to help (package building, website, bringing the software to the next millenium): talk with us and not beyond us.

  We really wonder why over the years nobody came to the idea to say "Hey dear maintainers, i'm in an important discussion on the mailinglist xyz, you're requested to join in". This is not really that kind of "community" and "the way software development on linux goes", as someone pointed out.

• Software development needs continuity, project leaders, volunteers, fans. Not just a collection of pinboards.

Collaboration work means working together, not against each other.