Re: Thank you for this informal D2005 fix

> LOL -- you've clearly never been in on writing a
....
> LOL- more ignorance.
....
> LOL -- yet more ignorance.
....
> LOL -- once again -- this needs to be coordinated with

Hi Nick.

Oh, it's wonderful to be at the receiving end of the 'spirit of Delphi'.

I do enjoy these warm and generous conversations.

> you've clearly never been in on writing a readme for a major
> product like Delphi.

I think you missed the point here. You might have missed the fact that we
are discussing a readme for an update to Delphi, not a readme for a Delphi
major version.

_If_ their business processes and the IT support are well set up I _do not_
see why it should take much time at all. The steps would be

- take the readme for a previous update to use as a template
- get a list of all the bugs fixed in this update from the
StarTeam/Requuirments management/bugtracking system, copy it, and paste it
into the readme file
- get a list of the files installed and where they are installed from from
the StarTeam/Requuirments management/bugtracking system, copy it, and paste
it
- see if any changes need to be made to the 'installing this update'
section.

All this of course could be automated to produce three different readmes
using a tool like Final Builder automating Borland's StarTeam/Requuirments
management/bugtracking system to produce the readmes, so all someone would
have to do is go through them and doub;e-check the items.

Tell me again, why do you think this should take a great deal of time?

> Overall, once again, the average developer has /no clue/ the amount of
> effort it takes to release a patch or an update. None.
> > - what do you mean by 'coordinate the support folks'? Do you expect
> > the update that's gone through QA will not work and will need
> > support? estimate: 0 minutes.
>
>
> LOL- more ignorance. /Of course/ the support people need to know
> about what is going on in any update and release. They need to be
> thoroughly trained on the update, what it entails, what the
> implications and ramifications are for the support team. Zero minutes
> is ridiculous.

In this case the various hotfixes have been discussed on Blogs and in this
ng, there would be the readme file, and an email could easily be sent out
advising of any issues (if there are any) support people should be aware of.

What do you think is particularly time consuming in this?

In this case, what specifically do you think would need to be sent out to
support teams that would not be covered by 'there were problems with D2005
update 3, as listed in the 'bugs fixed' in the readme. This update fixes
them. Let us know if you encounter any further problems'.

> > - they already have installers for Delphi 2005 patches 1, 2, and 3.
> > How hard can it be to modify an install script to inclluse the new
> > patches? estimate 5 minutes to do it, 1-3 hours to test installing
> > and uninstalling the uopdtaes for the 3 SKUs on Win NT, 2000, 2000
> > Server, XP, 2003 server, 95, 98, ME (8 OS's x 3 sku's = 24 tests to
> > be done, but there are probably a few more OS's to test on once you
> > take into account levels of patches) (I assume that they already have
> > 3 VMs for each of these OS's, with each Delphi SKU installed
> > respectively on these 3 VMs, so that all is needed is a new snapshot
> > or clone). But this is legwork, not rocket science, and would not
> > have to be done by particularly skilled staff. It would be start the
> > VM, install the new patch, make a snapshot, uninstall the patch, and
> > check that the appropriate changes have been made before and after
> > installing the patch.
>
> LOL -- yet more ignorance. Let's set aside the insult

There was no insult made, in fact I specifically pointed out that they were
skilled and talented individuals. If you want to insinuate insults into the
conversation it's your doing, not mine.

> to the skilled
> people who work hard to put this together -- putting together an
> install for a product the complexity of Delphi is not an easy task.
> There are a lot of decisions to be made,

The whole context of this discussion is that these decisions have already
been made and this work has already been done. So this is really an
irrelevant point.

> and a /lot/ of testing to be
> done. Once again, this is way, way, way, harder than you think it is.

ok, so that's your sole substantive point - 'testing is harder than I think
it is'. Some elaboration to support this proposition would be helpful.

I don't doubt that it may be more complex, but your comments do not do
anything to help me understand if and why that is the case. They just amount
to an assertion.

> And an install needs to be /perfect/, because if it isn't, it impacts
> support very hard (yeah, those zero seconds to keep support in the loop
> keep popping up).

Well, duh. But it is a slight modification of an existing install script.
And it is being tested, according to both your comments above and my post
you are replying to.

> > - modifying the web site is uploading a file and putting a link in to
> > the new file. estimate 5-10 minutes
>
> LOL -- once again -- this needs to be coordinated with the web group,
> and it needs to be tested to ensure it all works. I'd fire anyone who
> spent five mintues testing the download of a registered product behind
> the registration page.

I'd fire anyone who took longer than 5 minutes to do it.

I would have imagined they'd have a mirror of their website set up, and if
they haven't got automated testing of it set up, they'd have a process in
place to test it, like firing off an email to Team B to say 'please
downloade update from the mirror site'.

In other words, there work would be done in 10 munutes of making
modifications to the site, testing it themselves, uploading to the mirror
site, and then sending an email. And then a few minutes sometime later to
click a button to synchronise the actual site to the mirror.

> Overall, once again, the average developer has /no clue/ the amount of
> effort it takes to release a patch or an update. None.

Well, I don't feel this conversation has done anything to enrich my
understanding of this magical and mysterious process.

Steve T's Blogs are quite helpful though.

Lauchlan M


.