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
I have not used 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.
 
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.
 
Thank You,
 
David Demland
----- Original Message -----
From:=20 Alan=20 Dayley
To: plug-discuss@lists.= PLUG.phoenix.az.us=20
Sent: Saturday, December 30, = 2000 11:00=20 PM
Subject: Re: Version control = and issue=20 management solutions?

Excellent discussion!

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.

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.

Alan

At 09:10 PM 12/30/00 -0700, you = wrote:
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:
 
* = 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)
* 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)
* 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)
* 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)
* How will defects be tracked? (These are not part of = source=20 control)
* How will defects be = fixed?=20 (What is the process for fixing and verifying that the fix has no = side=20 effects)
* How are the SCIs, = Software=20 Configuration Items, track? (What components interact with other=20 components)
* How do I control = what is=20 built? (What process will ensure that the correct files and data are = being=20 used)
 
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.
 
Hope this is some help.
 
Thank You,
 
David=20 Demland
demland@home.com=20
----- Original Message -----=20
From: Patrick = Rhodes=20
To: 'plug-discuss@lis= ts.PLUG.phoenix.az.us'=20
Sent: Thursday, December 28, 2000 12:11 PM=20
Subject: RE: Version control and issue management=20 solutions?

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'.=20
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).=20
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).=20
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.=20
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.=20
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.=20
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.=20
My 2c (okay, perhaps I have a little more than 2c).=20

Patrick

-----Original Message-----
From: Alan Dayley [mailto:adayley@adtron.com] =
Sent: Thursday, December 28, 2000 11:49 AM
To: plug-discuss@lists.PLUG.phoenix.az.us
Subject: Version control and issue management = solutions?=20



We are finally getting serious about automated version control = and=20 issue
management software for our engineering staff.  We are = discussing=20 possible
software choices and I though someone on this list might = provide=20 some
insights.

Glossary:
-Version control: check source code or other documents=20 (manuals,
schematics, CAD drawings) in and out of a control library = system=20 that
automatically tracks changes to the files.  Build = control.=20
-Issue management: track development projects, accept bug = reports=20 from
testing or the field, assign bugs for fixes, report = progress.=20

Operational environment:
Currently we are a mostly M$ shop with a Linux server or = two. =20 All the
workstations are currently M$ Windows of one flavor or = another. =20 We have C
source code for the embedded systems in our products, code for = (gag)=20 DOS
and (gag gag) Win32 platforms and we will be creating Liunx=20 based
applicatons (C, C++, TCL/TK, Perl, etc.) and using Linux = workstations=20 very
soon.  We will not be abandoning the M$ deveopment for = quite some=20 time even
as we move to a more Linux-centric base.  It is a mixed = target=20 environment.
 Currently 3 software engineers, 1 digital design = engineer and a=20 CAD/PCB
layout technician.  Technical writers and more engineers = due to=20 be added
with growth this coming year.

As I hinted in the above, control of documents other than = source code=20 would
be very nice but the code is top priority. =

What have you found to be a good solution for these = needs?=20
CVS?
A commercial package such as PVCS or some other?
Home grown?
Any thoughts?

Alan

/------------------------------------------
|Alan=20 = Dayley           &= nbsp;=20 www.adtron.com
|Software Engineer       = 602-735-0300=20 x331
|ADayley@adtron.com
|
|Adtron = Corporation        =20
|3710 E. University Drive, Suite 5
|Phoenix, AZ  85034
\------------------------------------------- =

________________________________________________
See http://PLUG.phoen= ix.az.us/navigator-mail.shtml=20 if your mail doesn't post to the list quickly and you use Netscape = to=20 write mail.=20
Plug-discuss mailing list  - =20 Plug-discuss@lists.PLUG.phoenix.az.us
ht= tp://lists.PLUG.phoenix.az.us/mailman/listinfo/plug-discuss=20
------=_NextPart_000_000C_01C07301.DFCEAFC0--