Version control and issue management solutions?
David Demland
demland@home.com
Sun, 31 Dec 2000 08:15:45 -0700
This is a multi-part message in MIME format.
------=_NextPart_000_000C_01C07301.DFCEAFC0
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I have not used Bugzilla, but almost three years ago when we were =
looking for a bug tracking package I started a list of needs, like to =
have, and would be nice. The goal was to replace our "home grown" bug =
database and we were thinking about writing a new in house bug database. =
After about six months of everyone in development filling in the list it =
took very little time to see that we would not be able to do this =
ourselves. At this point I start looking at what was on the market. I =
checked out about six or seven different products. The only one that met =
everything on our list was QA Radar by Segue. I went to upper management =
showed why we needed this product and got it in house. Today it is =
called Silk Radar and it is still the best bug database we have ever =
had. This is no signs that we will out grow this one.
As far as CVS I am still working with it to see if it will work for us. =
At this point I am using CVS on a NT server with WinCVS as the font end =
on the client side. The basic functions seem to work well, but I have =
not had success, at this point, of getting an older file version that is =
not labeled. This could be a problem for us when working with concurrent =
development of code like we have to do at times. I will let you know =
more as I work with it. Just call me. My work number is (602) 953-4888 =
and home is (602) 955-3248.
Thank You,
David Demland
----- Original Message -----=20
From: Alan Dayley=20
To: plug-discuss@lists.PLUG.phoenix.az.us=20
Sent: Saturday, December 30, 2000 11:00 PM
Subject: Re: Version control and issue management solutions?
Excellent discussion!
I was hoping that there already is an "all in one" solution that was =
good enough to use for all these things you are talking about. The only =
company I see that at least claims to cover it all is the PVCS series of =
packages from Merant. The biggest problem there is it's requirements =
for M$ servers.
The quick answer seems to be that there are no quick answers. Well, =
let me get specific then: Has anyone used a combination of CVS and =
Bugzilla? Those two pieces would give us version management and bug =
tracking and the source is available.
Alan
At 09:10 PM 12/30/00 -0700, you wrote:
Not to cause confusion over what is being talked about here, but =
there is one basic problem that has been over looked at this point. =
There is no possible way that SCM, Software Configuration Management, =
can be done by hand and done right. The tools that were originally asked =
about all added up to SCM. SCM is a combination of development and =
processes for development. Yet the answer given is the most common =
mistake done in development today. That mistake is to confuse source =
control with SCM. The questions not answered yet are ones like:
=20
* How do I get different versions of the information I am looking =
for? (It is not important about what kind of information that is)
* How will I identify what information the customer has? (Files or =
data can be included in this and this depends on the format of shipped =
data)
* Is all the data going to be completed at one point in time? (Can I =
label all the files at once like a shipment of a product)
* Will there be more that one concurrent path for the information to =
be on at one time? (More that one version of development at a time)
* How will defects be tracked? (These are not part of source =
control)
* How will defects be fixed? (What is the process for fixing and =
verifying that the fix has no side effects)
* How are the SCIs, Software Configuration Items, track? (What =
components interact with other components)
* How do I control what is built? (What process will ensure that the =
correct files and data are being used)
=20
As I see it the answer to the original questions is: you need source =
control software, defect tracking software, and build software (system). =
There is no one product that can do all of these. You will have to =
identify what areas of trade off exist and what trade offs can be made. =
After this you can look at the different tools to see what you can use. =
I have spent a lot of time working on answering these types of questions =
for us at work and it is very hard to know what is the best way to go at =
times. For example CVS will fail to handle some of the above questions =
at all. Some of the questions CVS handles poorly for some environments. =
These are the types of trade offs you must decide to make. These will =
also differ from one place to another. Take note - Rational, Starbase, =
Microsoft, GNU, and many other players are trying to fit in somewhere in =
this whole picture. The reality is that no one player will have the =
whole answer. You have to understand what you are trying to do, who =
supplies the best answer to each piece, and how all the pieces fit that =
complete the correct picture for you. In other words do not buy in that =
any one company can give the total answer. Study, study, and study some =
more before you make a decision. Remember making the wrong decision at =
this point will come back to haunt you latter. Trust me I am reworking a =
system that we have done wrong for the last three years because no one =
took the time to ask the right questions before they decided to go down =
a path. Now we can not handle the production process properly. Remember =
that if the production process fails the product will fail.
=20
Hope this is some help.
=20
Thank You,
=20
David Demland
demland@home.com=20
----- Original Message -----=20
From: Patrick Rhodes=20
To: 'plug-discuss@lists.PLUG.phoenix.az.us'=20
Sent: Thursday, December 28, 2000 12:11 PM=20
Subject: RE: Version control and issue management solutions?
We have implemented a home-grown version for quite some time. =
See, the catch is, even if you have a piece of software that =
automatically tracks changes to files, it is not 'intelligent' enough to =
know what those changes are. So, if things break, or if code is =
duplicated somehow (not an exact match, but more in having code =
duplicate function), the software cannot figure out which changes to =
keep. This must be done by an integrator (a human one, that is). In =
other words, automation cannot determine 'intent', it can only determine =
'syntax'.=20
Now, if you have more than one person working on the same file, =
the integrator is going to have great difficulty resolving issues within =
the file as well. Just because it compiles, doesn't mean that it works. =
Just because it runs with no runtime errors, doesn't mean that it =
works. Somebody has to go in there and figure out how it works and try =
to fix it when it doesn't work correctly (and it WILL break).=20
In addition, if you are party 'A' and you've made some changes to =
the file, and party 'B' comes along and makes changes to the file, when =
party 'A' gets the revisions, they will have to figure out what party =
'B' did to the file unless party 'B' was absolutely careful in not =
making any changes to the file that affected any previous code (and that =
never happens - yea, right).=20
My solution is to give 'ownership' to certain packages or files - =
to where only one person (we are small, so it is person by person basis =
- in a large environment, substitute 'group' for 'person') has ownership =
of that file. They can feel secure that all changes to it must come =
through them and when the code is 'integrated' with the other files, =
that only their copy of that particular file or package will get =
through. This also allows others to screw with their 'copy' of the file =
knowing that it won't hurt the original because it won't come through in =
the integration.=20
If you are big enough to have testers, then you are in great =
shape. However, testing a GUI is an impossible situation for =
'automation'. All an automated system can do is test mouse clicks, =
keyboard entries, etc. It has no idea if what it is doing is =
'intelligent' - it is just a macro engine of some sort. So, once again, =
you are faced with having to have somebody (i.e. a human) test the =
system because only they can figure out if the system is running =
correctly or not (is the data logical/does the program 'flow' =
correctly?). Don't waste your money trying to automate testing.=20
I've seen lots of companies promise big things with automation =
(Rational, are you listening?), but you STILL have to have human thought =
in the builds SOMEWHERE. Many times that automation confuses the human =
because they are not sure where the bits and pieces came from and they =
are forced to use the 'tool' to ask each programmer what they were =
doing, how to correct, etc. ACCURATE builds, in my opinion, take longer =
that way.=20
Keep in mind that we are a small programming environment, so my =
experience only applies to this (3 programmers using Java). =
Communication between people (or groups) is key. Save your money, work =
on a home-grown solution, so you KNOW it works and you KNOW how to fix =
it if it doesn't work.=20
My 2c (okay, perhaps I have a little more than 2c).=20
Patrick=20
-----Original Message-----=20
From: Alan Dayley [mailto:adayley@adtron.com]=20
Sent: Thursday, December 28, 2000 11:49 AM=20
To: plug-discuss@lists.PLUG.phoenix.az.us=20
Subject: Version control and issue management solutions?=20
We are finally getting serious about automated version control and =
issue=20
management software for our engineering staff. We are discussing =
possible=20
software choices and I though someone on this list might provide =
some=20
insights.=20
Glossary:=20
-Version control: check source code or other documents (manuals,=20
schematics, CAD drawings) in and out of a control library system =
that=20
automatically tracks changes to the files. Build control.=20
-Issue management: track development projects, accept bug reports =
from=20
testing or the field, assign bugs for fixes, report progress.=20
Operational environment:=20
Currently we are a mostly M$ shop with a Linux server or two. All =
the=20
workstations are currently M$ Windows of one flavor or another. =
We have C=20
source code for the embedded systems in our products, code for =
(gag) DOS=20
and (gag gag) Win32 platforms and we will be creating Liunx based=20
applicatons (C, C++, TCL/TK, Perl, etc.) and using Linux =
workstations very=20
soon. We will not be abandoning the M$ deveopment for quite some =
time even=20
as we move to a more Linux-centric base. It is a mixed target =
environment.=20
Currently 3 software engineers, 1 digital design engineer and a =
CAD/PCB=20
layout technician. Technical writers and more engineers due to be =
added=20
with growth this coming year.=20
As I hinted in the above, control of documents other than source =
code would=20
be very nice but the code is top priority.=20
What have you found to be a good solution for these needs?=20
CVS?=20
A commercial package such as PVCS or some other?=20
Home grown?=20
Any thoughts?=20
Alan=20
/------------------------------------------=20
|Alan Dayley www.adtron.com=20
|Software Engineer 602-735-0300 x331=20
|ADayley@adtron.com=20
|=20
|Adtron Corporation =20
|3710 E. University Drive, Suite 5=20
|Phoenix, AZ 85034=20
\-------------------------------------------=20
________________________________________________=20
See http://PLUG.phoenix.az.us/navigator-mail.shtml if your mail =
doesn't post to the list quickly and you use Netscape to write mail.=20
Plug-discuss mailing list - =
Plug-discuss@lists.PLUG.phoenix.az.us=20
http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss=20
------=_NextPart_000_000C_01C07301.DFCEAFC0
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 5.50.4611.1300" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT face=3DArial size=3D2>I have not used <FONT face=3D"Times New =
Roman"=20
size=3D3>Bugzilla, but almost three years ago when we were looking for a =
bug=20
tracking package I started a list of needs, like to have, and would be =
nice. The=20
goal was to replace our "home grown" bug database and we were thinking =
about=20
writing a new in house bug database. After about six months of =
everyone in development filling in the list it took very little time to =
see that=20
we would not be able to do this ourselves. At this point I start looking =
at what=20
was on the market. I checked out about six or seven different products. =
The only=20
one that met everything on our list was QA Radar by Segue. I went to =
upper=20
management showed why we needed this product and got it in house. Today =
it is=20
called Silk Radar and it is still the best bug database we have ever =
had. This=20
is no signs that we will out grow this one.</FONT></FONT></DIV>
<DIV> </DIV>
<DIV><FONT face=3DArial size=3D2>As far as CVS I am still working with =
it to see if=20
it will work for us. At this point I am using CVS on a NT server with =
WinCVS as=20
the font end on the client side. The basic functions seem to work well, =
but I=20
have not had success, at this point, of getting an older file version =
that is=20
not labeled. This could be a problem for us when working with concurrent =
development of code like we have to do at times. I will let you know =
more as I=20
work with it. Just call me. My work number is (602) 953-4888 and home is =
(602)=20
955-3248.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Thank You,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>David Demland</FONT></DIV>
<BLOCKQUOTE dir=3Dltr=20
style=3D"PADDING-RIGHT: 0px; PADDING-LEFT: 5px; MARGIN-LEFT: 5px; =
BORDER-LEFT: #000000 2px solid; MARGIN-RIGHT: 0px">
<DIV style=3D"FONT: 10pt arial">----- Original Message ----- </DIV>
<DIV=20
style=3D"BACKGROUND: #e4e4e4; FONT: 10pt arial; font-color: =
black"><B>From:</B>=20
<A title=3Dalandd@consultpros.com =
href=3D"mailto:alandd@consultpros.com">Alan=20
Dayley</A> </DIV>
<DIV style=3D"FONT: 10pt arial"><B>To:</B> <A=20
title=3Dplug-discuss@lists.PLUG.phoenix.az.us=20
=
href=3D"mailto:plug-discuss@lists.PLUG.phoenix.az.us">plug-discuss@lists.=
PLUG.phoenix.az.us</A>=20
</DIV>
<DIV style=3D"FONT: 10pt arial"><B>Sent:</B> Saturday, December 30, =
2000 11:00=20
PM</DIV>
<DIV style=3D"FONT: 10pt arial"><B>Subject:</B> Re: Version control =
and issue=20
management solutions?</DIV>
<DIV><BR></DIV>Excellent discussion!<BR><BR>I was hoping that there =
already is=20
an "all in one" solution that was good enough to use for all these =
things you=20
are talking about. The only company I see that at least claims =
to cover=20
it all is the PVCS series of packages from Merant. The biggest =
problem=20
there is it's requirements for M$ servers.<BR><BR>The quick answer =
seems to be=20
that there are no quick answers. Well, let me get specific =
then: =20
Has anyone used a combination of CVS and Bugzilla? Those two =
pieces=20
would give us version management and bug tracking and the source is=20
available.<BR><BR>Alan<BR><BR>At 09:10 PM 12/30/00 -0700, you =
wrote:<BR>
<BLOCKQUOTE class=3Dcite cite type=3D"cite"><FONT face=3Darial =
size=3D2>Not to cause=20
confusion over what is being talked about here, but there is one =
basic=20
problem that has been over looked at this point. There is no =
possible way=20
that SCM, Software Configuration Management, can be done by hand and =
done=20
right. The tools that were originally asked about all added up to =
SCM. SCM=20
is a combination of development and processes for development. Yet =
the=20
answer given is the most common mistake done in development today. =
That=20
mistake is to confuse source control with SCM. The questions not =
answered=20
yet are ones like:</FONT><BR> <BR><FONT face=3Darial size=3D2>* =
How do I=20
get different versions of the information I am looking for? (It is =
not=20
important about what kind of information that is)</FONT><BR><FONT =
face=3Darial=20
size=3D2>* How will I identify what information the customer has? =
(Files or=20
data can be included in this and this depends on the format of =
shipped=20
data)</FONT><BR><FONT face=3Darial size=3D2>* Is all the data going =
to be=20
completed at one point in time? (Can I label all the files at once =
like a=20
shipment of a product)</FONT><BR><FONT face=3Darial size=3D2>* Will =
there be=20
more that one concurrent path for the information to be on at one =
time?=20
(More that one version of development at a time)</FONT><BR><FONT =
face=3Darial=20
size=3D2>* How will defects be tracked? (These are not part of =
source=20
control)</FONT><BR><FONT face=3Darial size=3D2>* How will defects be =
fixed?=20
(What is the process for fixing and verifying that the fix has no =
side=20
effects)</FONT><BR><FONT face=3Darial size=3D2>* How are the SCIs, =
Software=20
Configuration Items, track? (What components interact with other=20
components)</FONT><BR><FONT face=3Darial size=3D2>* How do I control =
what is=20
built? (What process will ensure that the correct files and data are =
being=20
used)</FONT><BR> <BR><FONT face=3Darial size=3D2>As I see it =
the answer to=20
the original questions is: you need source control software, defect =
tracking=20
software, and build software (system). There is no one product that =
can do=20
all of these. You will have to identify what areas of trade off =
exist and=20
what trade offs can be made. After this you can look at the =
different tools=20
to see what you can use. I have spent a lot of time working on =
answering=20
these types of questions for us at work and it is very hard to know =
what is=20
the best way to go at times. For example CVS will fail to handle =
some of the=20
above questions at all. Some of the questions CVS handles poorly for =
some=20
environments. These are the types of trade offs you must decide to =
make.=20
These will also differ from one place to another. Take note - =
Rational,=20
Starbase, Microsoft, GNU, and many other players are trying to fit =
in=20
somewhere in this whole picture. The reality is that no one player =
will have=20
the whole answer. You have to understand what you are trying to do, =
who=20
supplies the best answer to each piece, and how all the pieces fit =
that=20
complete the correct picture for you. In other words do not buy in =
that any=20
one company can give the total answer. Study, study, and study some =
more=20
before you make a decision. Remember making the wrong decision at =
this point=20
will come back to haunt you latter. Trust me I am reworking a system =
that we=20
have done wrong for the last three years because no one took the =
time to ask=20
the right questions before they decided to go down a path. Now we =
can not=20
handle the production process properly. Remember that if the =
production=20
process fails the product will fail.</FONT><BR> <BR><FONT =
face=3Darial=20
size=3D2>Hope this is some help.</FONT><BR> <BR><FONT =
face=3Darial=20
size=3D2>Thank You,</FONT><BR> <BR><FONT face=3Darial =
size=3D2>David=20
Demland</FONT><BR><FONT face=3Darial size=3D2><A=20
href=3D"mailto:demland@home.com">demland@home.com</A></FONT>=20
<DL>
<DD>----- Original Message -----=20
<DD>From:</B> <A href=3D"mailto:Patrick.Rhodes@asu.edu">Patrick =
Rhodes</A>=20
<DD>To:</B> <A=20
=
href=3D"mailto:'plug-discuss@lists.PLUG.phoenix.az.us'">'plug-discuss@lis=
ts.PLUG.phoenix.az.us'</A>=20
<DD>Sent:</B> Thursday, December 28, 2000 12:11 PM=20
<DD>Subject:</B> RE: Version control and issue management=20
solutions?<BR><BR><FONT size=3D2>
<DD>We have implemented a home-grown version for quite some =
time. =20
See, the catch is, even if you have a piece of software that =
automatically=20
tracks changes to files, it is not 'intelligent' enough to know =
what those=20
changes are. So, if things break, or if code is duplicated =
somehow=20
(not an exact match, but more in having code duplicate function), =
the=20
software cannot figure out which changes to keep. This must =
be done=20
by an integrator (a human one, that is). In other words, =
automation=20
cannot determine 'intent', it can only determine =
'syntax'.</FONT><FONT=20
size=3D2>=20
<DD>Now, if you have more than one person working on the same =
file, the=20
integrator is going to have great difficulty resolving issues =
within the=20
file as well. Just because it compiles, doesn't mean that it =
works. Just because it runs with no runtime errors, doesn't =
mean=20
that it works. Somebody has to go in there and figure out =
how it=20
works and try to fix it when it doesn't work correctly (and it =
WILL=20
break).</FONT><FONT size=3D2>=20
<DD>In addition, if you are party 'A' and you've made some changes =
to the=20
file, and party 'B' comes along and makes changes to the file, =
when party=20
'A' gets the revisions, they will have to figure out what party =
'B' did to=20
the file unless party 'B' was absolutely careful in not making any =
changes=20
to the file that affected any previous code (and that never =
happens - yea,=20
right).</FONT><FONT size=3D2>=20
<DD>My solution is to give 'ownership' to certain packages or =
files - to=20
where only one person (we are small, so it is person by person =
basis - in=20
a large environment, substitute 'group' for 'person') has =
ownership of=20
that file. They can feel secure that all changes to it must =
come=20
through them and when the code is 'integrated' with the other =
files, that=20
only their copy of that particular file or package will get =
through. =20
This also allows others to screw with their 'copy' of the file =
knowing=20
that it won't hurt the original because it won't come through in =
the=20
integration.</FONT><FONT size=3D2>=20
<DD>If you are big enough to have testers, then you are in great=20
shape. However, testing a GUI is an impossible situation for =
'automation'. All an automated system can do is test mouse =
clicks,=20
keyboard entries, etc. It has no idea if what it is doing is =
'intelligent' - it is just a macro engine of some sort. So, =
once=20
again, you are faced with having to have somebody (i.e. a human) =
test the=20
system because only they can figure out if the system is running =
correctly=20
or not (is the data logical/does the program 'flow' =
correctly?). =20
Don't waste your money trying to automate testing.</FONT><FONT =
size=3D2>=20
<DD>I've seen lots of companies promise big things with automation =
(Rational, are you listening?), but you STILL have to have human =
thought=20
in the builds SOMEWHERE. Many times that automation confuses =
the=20
human because they are not sure where the bits and pieces came =
from and=20
they are forced to use the 'tool' to ask each programmer what they =
were=20
doing, how to correct, etc. ACCURATE builds, in my opinion, =
take=20
longer that way.</FONT><FONT size=3D2>=20
<DD>Keep in mind that we are a small programming environment, so =
my=20
experience only applies to this (3 programmers using Java). =20
Communication between people (or groups) is key. Save your =
money,=20
work on a home-grown solution, so you KNOW it works and you KNOW =
how to=20
fix it if it doesn't work.</FONT><FONT size=3D2>=20
<DD>My 2c (okay, perhaps I have a little more than 2c).</FONT>=20
<BR><BR><FONT size=3D2>
<DD>Patrick</FONT> <BR><BR><FONT size=3D2>
<DD>-----Original Message-----</FONT> <FONT size=3D2>
<DD>From: Alan Dayley [<A=20
=
href=3D"mailto:adayley@adtron.com">mailto:adayley@adtron.com</A>]</FONT> =
<FONT size=3D2>
<DD>Sent: Thursday, December 28, 2000 11:49 AM</FONT> <FONT =
size=3D2>
<DD>To: plug-discuss@lists.PLUG.phoenix.az.us</FONT> <FONT =
size=3D2>
<DD>Subject: Version control and issue management =
solutions?</FONT>=20
<BR><BR><BR><BR><FONT size=3D2>
<DD>We are finally getting serious about automated version control =
and=20
issue</FONT> <FONT size=3D2>
<DD>management software for our engineering staff. We are =
discussing=20
possible</FONT> <FONT size=3D2>
<DD>software choices and I though someone on this list might =
provide=20
some</FONT> <FONT size=3D2>
<DD>insights.</FONT> <BR><BR><FONT size=3D2>
<DD>Glossary:</FONT> <FONT size=3D2>
<DD>-Version control: check source code or other documents=20
(manuals,</FONT> <FONT size=3D2>
<DD>schematics, CAD drawings) in and out of a control library =
system=20
that</FONT> <FONT size=3D2>
<DD>automatically tracks changes to the files. Build =
control.</FONT>=20
<FONT size=3D2>
<DD>-Issue management: track development projects, accept bug =
reports=20
from</FONT> <FONT size=3D2>
<DD>testing or the field, assign bugs for fixes, report =
progress.</FONT>=20
<BR><BR><FONT size=3D2>
<DD>Operational environment:</FONT> <FONT size=3D2>
<DD>Currently we are a mostly M$ shop with a Linux server or =
two. =20
All the</FONT> <FONT size=3D2>
<DD>workstations are currently M$ Windows of one flavor or =
another. =20
We have C</FONT> <FONT size=3D2>
<DD>source code for the embedded systems in our products, code for =
(gag)=20
DOS</FONT> <FONT size=3D2>
<DD>and (gag gag) Win32 platforms and we will be creating Liunx=20
based</FONT> <FONT size=3D2>
<DD>applicatons (C, C++, TCL/TK, Perl, etc.) and using Linux =
workstations=20
very</FONT> <FONT size=3D2>
<DD>soon. We will not be abandoning the M$ deveopment for =
quite some=20
time even</FONT> <FONT size=3D2>
<DD>as we move to a more Linux-centric base. It is a mixed =
target=20
environment.</FONT> <FONT size=3D2>
<DD> Currently 3 software engineers, 1 digital design =
engineer and a=20
CAD/PCB</FONT> <FONT size=3D2>
<DD>layout technician. Technical writers and more engineers =
due to=20
be added</FONT> <FONT size=3D2>
<DD>with growth this coming year.</FONT> <BR><BR><FONT size=3D2>
<DD>As I hinted in the above, control of documents other than =
source code=20
would</FONT> <FONT size=3D2>
<DD>be very nice but the code is top priority.</FONT> =
<BR><BR><FONT=20
size=3D2>
<DD>What have you found to be a good solution for these =
needs?</FONT>=20
<FONT size=3D2>
<DD>CVS?</FONT> <FONT size=3D2>
<DD>A commercial package such as PVCS or some other?</FONT> <FONT =
size=3D2>
<DD>Home grown?</FONT> <FONT size=3D2>
<DD>Any thoughts?</FONT> <BR><BR><FONT size=3D2>
<DD>Alan</FONT> <BR><BR><FONT size=3D2>
<DD>/------------------------------------------</FONT> <FONT =
size=3D2>
<DD>|Alan=20
=
Dayley &=
nbsp;=20
<A href=3D"http://www.adtron.com/"=20
eudora=3D"autourl">www.adtron.com</A></FONT> <FONT size=3D2>
<DD>|Software Engineer =
602-735-0300=20
x331</FONT> <FONT size=3D2>
<DD>|ADayley@adtron.com</FONT> <FONT size=3D2>
<DD>|</FONT> <FONT size=3D2>
<DD>|Adtron =
Corporation =20
</FONT><FONT size=3D2>
<DD>|3710 E. University Drive, Suite 5</FONT> <FONT size=3D2>
<DD>|Phoenix, AZ 85034</FONT> <FONT size=3D2>
<DD>\-------------------------------------------</FONT> =
<BR><BR><FONT=20
size=3D2>
<DD>________________________________________________</FONT> <FONT =
size=3D2>
<DD>See <A=20
=
href=3D"http://PLUG.phoenix.az.us/navigator-mail.shtml">http://PLUG.phoen=
ix.az.us/navigator-mail.shtml</A>=20
if your mail doesn't post to the list quickly and you use Netscape =
to=20
write mail.</FONT><FONT size=3D2>=20
<DD>Plug-discuss mailing list - =20
Plug-discuss@lists.PLUG.phoenix.az.us</FONT> <FONT size=3D2>
<DD><A=20
=
href=3D"http://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss">ht=
tp://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss</A></FONT>=20
</DD></DL></BLOCKQUOTE></BLOCKQUOTE></BODY></HTML>
------=_NextPart_000_000C_01C07301.DFCEAFC0--