Version control and issue management solutions?

------=_NextPart_000_000C_01C07301.DFCEAFC0
Content-Type: text/plain;
    charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
    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
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>&nbsp;</DIV>
<DIV><FONT face=3DArial size=3D2>Thank You,</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT>&nbsp;</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.&nbsp; The only company I see that at least claims =
to cover=20
  it all is the PVCS series of packages from Merant.&nbsp; 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.&nbsp; Well, let me get specific =
then:&nbsp;=20
  Has anyone used a combination of CVS and Bugzilla?&nbsp; 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>&nbsp;<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>&nbsp;<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>&nbsp;<BR><FONT =
face=3Darial=20
    size=3D2>Hope this is some help.</FONT><BR>&nbsp;<BR><FONT =
face=3Darial=20
    size=3D2>Thank You,</FONT><BR>&nbsp;<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.&nbsp;=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.&nbsp; 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.&nbsp; This must =
be done=20
      by an integrator (a human one, that is).&nbsp; 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.&nbsp; Just because it compiles, doesn't mean that it =
      works.&nbsp; Just because it runs with no runtime errors, doesn't =
mean=20
      that it works.&nbsp; 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.&nbsp; 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.&nbsp;=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.&nbsp; However, testing a GUI is an impossible situation for =
      'automation'.&nbsp; All an automated system can do is test mouse =
clicks,=20
      keyboard entries, etc.&nbsp; It has no idea if what it is doing is =
      'intelligent' - it is just a macro engine of some sort.&nbsp; 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?).&nbsp;=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.&nbsp; 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.&nbsp; 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).&nbsp;=20
      Communication between people (or groups) is key.&nbsp; 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.&nbsp; 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.&nbsp; 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.&nbsp;=20
      All the</FONT> <FONT size=3D2>
      <DD>workstations are currently M$ Windows of one flavor or =
another.&nbsp;=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.&nbsp; 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.&nbsp; It is a mixed =
target=20
      environment.</FONT> <FONT size=3D2>
      <DD>&nbsp;Currently 3 software engineers, 1 digital design =
engineer and a=20
      CAD/PCB</FONT> <FONT size=3D2>
      <DD>layout technician.&nbsp; 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;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&=
nbsp;=20
      <A href=3D"http://www.adtron.com/"=20
      eudora=3D"autourl">www.adtron.com</A></FONT> <FONT size=3D2>
      <DD>|Software Engineer&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; =
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&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;=20
      </FONT><FONT size=3D2>
      <DD>|3710 E. University Drive, Suite 5</FONT> <FONT size=3D2>
      <DD>|Phoenix, AZ&nbsp; 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&nbsp; -&nbsp;=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>

This message is part of the following thread:
	the complete thread tree sorted by date
	Alan Dayley at
	David Demland at