SKUA release 0.2
Norman Gray
Folks,
I've made a release 0.2 of the SKUA software, and the various bits
should be findable on myskua.org, and the project downloads page <http://code.google.com/p/skua/downloads/list
>
This finally includes the SAC persistence, and marks the rather
overdue end of this iteration. Since I'm at the eurovotech meeting in
Cambridge all this week, it might be difficult to have an iteration
meeting, but I'll be talking to Noel and possibly Mark face-to-face
here, and probably giving some sort of brief presentation about SKUA
progress.
Comments on the adequacy of the documentation would be most welcome.
Housekeeping: in preparing the release, I had to make a couple of
tweaks to the code/client/java/src/java/org/myskua/sac/client/
build.xml file. Kona, could you take a quick look at these diffs, and
check that the <delete dir='${build}'/> isn't likely to stomp on
things it shouldn't stomp on?
Also, Kona, moray.roe.ac.uk seems to have taken a dislike to my ssh
keys -- could you drop <http://nxg.me.uk/temp/apps.myskua.org.tar.gz>
into the appropriate place on srif112?
Ross: I still haven't replied to your long-ago process mail. That's
still in my draft mailbox.
See you,
Norman
--
Norman Gray : http://nxg.me.uk
Dept Physics and Astronomy, University of Leicester
Ross Gardler
>
> Folks,
>
> I've made a release 0.2 of the SKUA software, and the various bits
> should be findable on myskua.org, and the project downloads page <http://code.google.com/p/skua/downloads/list
> >
Congrats. Now I get to play and really understand where SKUA is heading.
> Comments on the adequacy of the documentation would be most welcome.
How would you prefer these comments? I've just jotted them all down
here, but would you prefer issues in the issue tracker where you can
prioritise and schedule (or reject) them?
I realise this is a 0.2 release and therefore incomplete - I'm raising
all issues that come to mind just so that I know they haven't been
forgotten. Please understand this is *constructive* criticism not
complaining.
So lets start off with a positive comment. A JISC project getting a
release out this early is an unusual thing and I'm really pleased to see
it. Lets hope your experiences from releasing this early are good and
that OSS Watch are able to use you as a case study in why "release
early, release often" is important.
Having all the files named "qsac-*" is confusing - isn't this SKUA? What
is a QSAC? (rhetorical question to help inform docs)
Having something from the project and wiki home pages linking to the
docs on installing would help. Searching for "install" on the wiki and
browsing the SKUA site doesn't help. In fact I found no docs at all.
I took what looked like the most appropriate option for me and
downloaded the qsac-jetty, guesing that it will give me a running
instance of SKUA as quickly as possible (I can only guess this because I
know what Jetty is, others might not make this link).
Opening the Zip it seems I'm OK as there is a script to start Jetty
(again, only useful if I know what Jetty is, I want to run SKUA not this
Jetty thing).
Wait, what's this. I'm on Windows and there is no .bat (no problem for
me as I run cygwin being a "real" developer on windows - it's a problem
for many though). Feel free to rip the scripts I use on Simal [1] for an
easy and well tested set of platform independant scripts (windows,
Windows+Cygwin, Linuix, Unix and OSX.
Unfortunately the script doesn't work on Windows, even when using Cygwin:
"Exception in thread "main" java.lang.NoClassDefFoundError:
Files/qsac-jetty-0/2/
lib/jetty-6/1/7/jar:/cygdrive/c/Program"
Looks like a problem with spaced in filenames in the classpath.
For future releases I'd recommend having release candidates for testing
first. Just helps manage user expectations a little. I'd be happy to
test the basics like installing. You may be interested in adopting
something like the Simal release process [2] (still in development,
we're just in a 0.2 release candidate stage right now).
I've not got the time to play further for now. I'll give the war files a
run as well as running this on a Linux box as soon as I can.
Ross
[1]
http://code.google.com/p/simal/source/browse/#svn/trunk/uk.ac.osswatch.simal.core/bin
[2] http://code.google.com/p/simal/wiki/ReleaseManagement
Norman Gray
Ross, hello.
On 2008 Sep 29, at 10:09, Ross Gardler wrote:
> How would you prefer these comments? I've just jotted them all down
> here, but would you prefer issues in the issue tracker where you can
> prioritise and schedule (or reject) them?
I think here on the mailing list is good for me.
> Having all the files named "qsac-*" is confusing - isn't this SKUA?
> What
> is a QSAC? (rhetorical question to help inform docs)
Guilty as charged. I was aware when I was naming the google downloads
that I should have more of a think about how to name things, and...
> Having something from the project and wiki home pages linking to the
> docs on installing would help. Searching for "install" on the wiki and
> browsing the SKUA site doesn't help. In fact I found no docs at all.
...writing installation notes would inevitably address the naming
problem, too.
> Opening the Zip it seems I'm OK as there is a script to start Jetty
> (again, only useful if I know what Jetty is, I want to run SKUA not
> this
> Jetty thing).
Ah, because the script is 'start-jetty.sh', not 'start-sac.sh' -- an
excellent point, which I was too close to see.
> Wait, what's this. I'm on Windows and there is no .bat (no problem for
> me as I run cygwin being a "real" developer on windows - it's a
> problem
> for many though). Feel free to rip the scripts I use on Simal [1]
> for an
> easy and well tested set of platform independant scripts (windows,
> Windows+Cygwin, Linuix, Unix and OSX.
Oooh, I hadn't thought about windows users. I'll have a look at the
Simal scripts and see what I can cook up.
> For future releases I'd recommend having release candidates for
> testing
> first. Just helps manage user expectations a little.
Iteration releases mean never having to say 'release process'. Since
the only difference between an iteration release and a point release
is in the filename (to first order), every iteration release is a
release candidate.
To second order, I suppose, the difference is that you expect users to
have a different attitude to point releases (which links to your point
about user expectations). But that means only that you tell folk that
the next release but one is going to be a point release, so they
should regard this current iteration release as a RC, if they want to
think in those terms.
Things to do:
* Preen the installation process -- primarily documenting it
* Create windows scripts
Many thanks for these notes, Ross, they're most valuable.
Ross Gardler
>
> Ross, hello.
>
> On 2008 Sep 29, at 10:09, Ross Gardler wrote:
>
...
>> Wait, what's this. I'm on Windows and there is no .bat (no problem for
>> me as I run cygwin being a "real" developer on windows - it's a
>> problem
>> for many though). Feel free to rip the scripts I use on Simal [1]
>> for an
>> easy and well tested set of platform independant scripts (windows,
>> Windows+Cygwin, Linuix, Unix and OSX.
>
> Oooh, I hadn't thought about windows users. I'll have a look at the
> Simal scripts and see what I can cook up.
Windows? From the manager of OSS Watch? Who'd have thought it?
I think you'll find those Simal scripts really useful. I based them on
the Apache Forrest scripts which have been in use on just about every
platofrm over the last 5 years. We never get problems with them from any
user.
>> For future releases I'd recommend having release candidates for
>> testing
>> first. Just helps manage user expectations a little.
>
> Iteration releases mean never having to say 'release process'. Since
> the only difference between an iteration release and a point release
> is in the filename (to first order), every iteration release is a
> release candidate.
Very true.
> To second order, I suppose, the difference is that you expect users to
> have a different attitude to point releases (which links to your point
> about user expectations). But that means only that you tell folk that
> the next release but one is going to be a point release, so they
> should regard this current iteration release as a RC, if they want to
> think in those terms.
Yes, fair enough.
> Things to do:
>
> * Preen the installation process -- primarily documenting it
>
> * Create windows scripts
>
> Many thanks for these notes, Ross, they're most valuable.
You are welcome, I'm glad you are taking my "picky" comments in the
spirit they are intended.
I intend to test your wars and execution scripts on an Linux machine.
However, I'm off work for at least a week. I may find a little time to
play but then again, I may not.
I'll be sure to provide further feedback when I can.
Ross
Norman Gray
Ross, hello.
On 2008 Sep 30, at 20:11, Ross Gardler wrote:
> Windows? From the manager of OSS Watch? Who'd have thought it?
It's the end of the world. Armageddon looms (when the four horsemen
have had a chance to get to a cashpoint).
> I think you'll find those Simal scripts really useful. I based them on
> the Apache Forrest scripts which have been in use on just about every
> platofrm over the last 5 years. We never get problems with them from
> any
> user.
I avoided the problem, by reworking the standalone server as a single
qsac-standalone-n.n.jar file (so no mention of the Jetty
technicality), which you start up with 'java -jar', or by double-
clicking, so this should be platform independent, and the .sh script
has gone.
>> Things to do:
>>
>> * Preen the installation process -- primarily documenting it
Done. <http://myskua.org/software.html> now points to <http://myskua.org/doc/qsac/
>, which has its links in a better order, and gives what I believe is
adequate prominence to the new installation and configuration notes.
Kona: if you get a chance, or want some distraction, might you add
some similar brief blurb to the software.html page for the client,
along with some pointer to how and why you'd install it? If you're
likely to be pressed, I can add a few lines where I think they ought
to go.
We're planning the next iteration meeting on Friday (is that still OK,
Kona, or is the AG release likely to be on-going still?)