LinuxAX25 History - Revision history

DL5RB: Less talk about CVS, more on GIT.

2015-05-01T07:59:46Z

Less talk about CVS, more on GIT.

← Older revision		Revision as of 07:59, 1 May 2015
Line 5:		Line 5:
	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.		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.		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, when and why) of the whole development 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 massive technical 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~~		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. This view changed in 2014 by which time CVS was looking even more technically inferior to GIT than it always has been and beginning to fade away into obscurity, so linux-ax25.org migrated over to GIT. The old CVS repositories still exist for the beneift of those who still have active CVS checkouts but there will be no future checkins. The best way to follow Linux/AX2.25 history online is now http://git.linux-ax25.org/cgit/ rsp. https://git.linux-ax25.org/cgit/.
	~~shows details of every piece of change)~~.
	~~URL: http~~://~~www~~.linux-ax25.org/~~cvsweb~~

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

	~~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:		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:

DL5RB: Link to CVS page

2009-06-06T11:58:05Z

Link to CVS page

← Older revision		Revision as of 11:58, 6 June 2009
Line 3:		Line 3:
	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.		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.		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.		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.

DL5RB: Remove history section title; this only duplicates the page's title and is rendered ugly

2009-06-06T11:50:58Z

Remove history section title; this only duplicates the page's title and is rendered ugly

← Older revision		Revision as of 11:50, 6 June 2009
Line 1:		Line 1:
	~~== History ==~~

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

DL5RB: A little polishing of language, speeling and wiki markup. No change of content.

2009-06-06T11:47:02Z

A little polishing of language, speeling and wiki markup. No change of content.

← Older revision		Revision as of 11:47, 6 June 2009
Line 1:		Line 1:
	== History ==		== History ==

	In Oct 2005 ~~we took the Maintainership from~~ Craig Small.		In Oct 2005 Craig Small passed on maintainership to us, DL9SAU and DL5RB. We immediately updated the contact details on the Sourceforge website.
	We immediately ~~added~~ the ~~new~~ contact ~~address at~~ the 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 ~~layed~~ there for quite a long time.		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 took		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.
	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. ~~Beeing~~ root, it gives us all
	the opportunities we may need.~~<br />~~
	~~[In simple words, CVS is a system to maintain the history of all changes~~
	~~to a software project]~~

	Starting with our Server linux-ax25.org, we first imported the complete		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.
	CVS tree.~~<br />~~
	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 ~~furhter~~ 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		The CVS repository can also be accessed with a web-browser (cvsweb
Line 33:		Line 18:
	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 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 at the		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:
	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		* 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.		* 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 on their own. They ~~jut~~ use the "know how" of their favourite linux distribution.		* 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.		* 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		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.
	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		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.
	software became perceptible: there never will be an end. It's ~~a fluent~~
	~~progress~~.~~<br />~~
	This is the main reason why there's (still) ~~not a~~ version ~~numbering~~
	like ax25-apps-0.0.6, ax25-tools-0.0.8 or libax25-0.0.11 ~~(these~~ are the
	latest official released tar balls).

	Since we always tested our code before checkin to the CVS there was		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.
	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		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:
	(who contacted us) to periodicaly check the changes on the cvs.		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.<br />
	This is apparently not a new idea. You may look at your favourite		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.
	linux distribution and their experiences over the years:~~<br />~~
	Either they said "we need to get ~~stable like granite~~". 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 ~~whistels~~ one expects from modern systems, or because
	~~its~~ 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.<br />
	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:		Link to the archived ax25.sourceforge.net Homepage:
	~~http://www.linux-ax25.org/wiki/~~LinuxAX25_Historic_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.

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

	~~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's strange a discussion going on at the linux-hams
	mailinglist.

	We've to point out that
	* The project is not dead.		* The project is not dead.
	* ~~dl5rb~~ and ~~dl9sau~~ are the maintainers. They usually answer in less than 24 hours.		* 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.		* 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 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.		* 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.		* 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.<~~br/~~ > 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.		* 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.<p>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.		* Software development needs continuity, project leaders, volunteers, fans. Not just a collection of pinboards.

	Collaboration work means working together, not against each other.		Collaboration work means working together, not against each other.

DL9SAU: New page: == History == In Oct 2005 we took the Maintainership from Craig Small. We immediately added the new contact address at the website. We started to add the pending software fixes which wer...

2009-01-22T14:05:28Z

New page: == History == In Oct 2005 we took the Maintainership from Craig Small. We immediately added the new contact address at the website. We started to add the pending software fixes which wer...

New page

== History ==

In Oct 2005 we took the Maintainership from Craig Small.
We immediately added the new contact address at the 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 layed there for quite a long time.

Because there were problems with sourceforge.net (a CVS checkin 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. Beeing root, it gives us all
the opportunities we may need. 
[In simple words, CVS is a system to maintain the history of all changes
to a software project]

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 furhter 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 at 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 on their own. They jut 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 a fluent
progress. 
This is the main reason why there's (still) not a version numbering
like ax25-apps-0.0.6, ax25-tools-0.0.8 or libax25-0.0.11 (these are the
latest official released tar balls).

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 stable like granite". 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 whistels one expects from modern systems, or because
its 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:
http://www.linux-ax25.org/wiki/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's strange a discussion going on at 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.