This new release was a long time coming. It's been just over a year
since the last release. It was a long staggered beta process.
I need to shorten that duration. I think volunteers would work better on this type of
project if there is a shorter testing period. I kept coming up with new features
to add and that would affect several other items. That's called
Part of the problem was I kept
putting off the implementation date. That's a luxury not
found in commercial projects. Time lines do not slip so easily
if money is involved. Nor is scope creep tolerated like it was on this
Luckily, I got good help from volunteers in testing and coding,
but I'd like more. If you are interested in helping to develop FreshPorts,
you know where to find me. Many people have come up with great ideas, but
as is the case with many projects, there's nobody around to do the work.
I don't think I'll be accused of self-promotion if I say the upgrade
went rather well. I started about 6:34 am EST and the web site was
back up for normal operations at 10:34 am EST. I didn't plan for
a four hour window. My test upgrades normally took about 15 minutes.
But those tests consisted only of
- pg_dump freshports
- copy tarball to home where I'm running 7.3.2
- import the dumped schema/data
- run the PostgreSQL contrib/adddepend script which tidies up 7.2
schemas with respect to serial, foreign keys, primary keys etc.
- make change to the database for the new features (easily done...
- Then run a to
refresh the statistics for the index, query optimizer, etc.
These test runs did not include
upgrading PostgreSQL to 7.3.2.
That's pretty straight forward and can be done in parallel. However, when
upgrading a server, it's better to do things serially. There is much
less room for error when you are concentrating on just one task at a
I also had to reconfigure the email processing daemon to reflect a much
improved strategy for
handling multiple versions of FreshPorts on a single
machine, each running under the same user. That took me 20 minutes or so...
setting up the new directories, ensuring procmail was set up in the
The truth be told, I had finished everything by 8:11 am. But I found
I'd forgotten to populate a new table, and that was fixed by about
8:39 am. But by 8:51, I'd noticed a problem with virtual categories
which results in duplicate entries in various situations. That took
until 10:05* to fix. This was solved by selecting virtual categories
and physical categories using different techniques and then using
a UNION to combine the results. The
categories page uses this technique.
*Those wondering if I keep detailed notes, with times, duration, etc, of each
step, no, I don't do that. I'm getting these times from