Reposting to galaxy-dev list. Just realised this went off-list. Stewart Stevens wrote:
Hi Chris
Yep, I feel the same way about dealing with our galaxy server in Otago. Basically I just delay updating and then backup and bite the bullet expecting to potentially run into problems. Of course the delay makes these more likely. Ideally I guess I should update often and deal with problems as they come, reporting these / fixes back to PSU. I just don't have time to do this.
Yup. My sentiments exactly. Except here we have two parallel installs; one that can be broken and one that should be 'stable'.
I should be spending my time researching gout genetics! (I used to be a professional software engineer.)
I'm not a software engineer, I want to use the best tools to be able to do my research. Occassional debugging and fixing things is fine.
You're right that just a change log and some release markers would be helpful.
Cheers,
Stewart
On 8/09/2009, at 9:57 AM, Chris Cole wrote:
Hi Stewart,
I agree with you that PSU are doing a fantastic job with galaxy at the moment and it's great to be able to get hold of the latest and greatest commits to the repo. This is part and parcel of academia; exciting new tools with some rough edges.
However, we don't update our galaxy server on a regular basis as we're happy to work with what we have, but now and again I would like to know what updates have been made to the development tree and how significant they are /before/ I do an update. i.e. has recent activity been mainly bugfixes or has some major new functionality been added? At the very least a chagelog would be good or even some version numbers.
I'm not asking for a highly managed and robust testing regime on all common platforms with fancy installers etc. Just an idea of what's changed between my current install and the latest on the trunk, but at a higher level than file diffs. Cheers,
Chris
Stewart Stevens wrote:
Hi, Managed, documented, quality controlled releases? From the perspective of someone outside PSU installing a local galaxy service this would clearly be highly beneficial. One point is that the research environment in which bioinformatics software is developed often leads to a "serve it while its hot" attitude, obviously the commercial world still wants hot releases but pretty much everyone does some kind of release management - inadvertently serving up rubbish would cause chaos in the supply chain and damage reputations. Academia isn't entirely different. I don't know what process the guys at PSU go through when they update the servers running the public release of galaxy but I'm sure they do have some process! So could this be transformed into some kind of release management? Possibly, but PSU has one particular environment and so any rigourous release testing would need plenty of additional work. Also when something does go wrong they are immediately able to make necessary fixes - effectively making point releases. At the moment we get to check out code and that does make it clear that it is development stuff and the responsibility for testing lies with whoever is installing it. Another advantage is that this engages the community with the development effort. A suggestion which could be good is to undertake marked releases as a community. Just tag the repository at opportune intervals. Those who want can work from that tag which can branch to a mature release as bug reports are dealt with. This would still take resource to manage centrally at PSU. I guess it is a sign of the product maturing that people want managed releases. (Cool product btw!) I'm sure we're all glad to have a great development branch rather than some crappy managed releases. On the back of this, hopefully PSU will be successful in attracting funding to continue development and also package releases nicely. Cheers, Stewart On 8/09/2009, at 9:12 AM, Chris Cole wrote:
Anyone have any thoughts on this?
Chris Cole wrote:
Hi,
I have a local install of Galaxy and would like to keep up-to-date with the latest updates, but I'm not sure what functionality has changed nor how significant the changes are. The mercurial updates on this list are too detailed. I just want to know what the benefit of an update would be, not which files have changed.
Would it be possible to start having more managed releases with a changelog between each release? That way it will be much clearer what the functional benefits of updating to a newer release would be. Cheers,
Chris
_______________________________________________ galaxy-dev mailing list galaxy-dev@bx.psu.edu http://mail.bx.psu.edu/cgi-bin/mailman/listinfo/galaxy-dev