Stewart Stevens wrote:
Hi,
Actually I haven't had problems when updating galaxy :-) Your testing has been working for us so far. Our changes have been restricted to adding modules so conflict hasn't been an issue.
I haven't had problems either, but I've only done one update so far. The only issue I've had is keeping track of local changes I've made to our Galaxy instance. i.e. patches supplied by others New tools are quite easy as they are in separate sections/locations and are softlinked back to where Galaxy can 'see' them.
Also the main issue Chris raised I think was having a change list.
That's right or at least a proxy for determining whether the latest update is big or small (e.g. .1 release or a .0.1 release)
I don't know if you open a bitbucket issue for every change, or at least every "signficant" change. I see you can already query Bitbucket to give for example all resolved enhancements and the resulting list is in order of newest first. Also for fixed bugs (http://bitbucket.org/jespern/bitbucket/issues/?status=resolved&kind=bug). Perhaps links to this information could be more prominent.
These are just bitbucket tickets aren't they? I can't see any Galaxy specific ones...
In general, formal release processes introduce overhead that we have so far avoided, and ultimately result in longer waits for bug fixes or cool new features.
I can understand that, but a balance could be struck where, for example, new features could constitute point releases and bug fixes are simply merged to the trunk as soon as they pass testing. Something like that maybe?
Yes, we have a formal process in place ensuring that new versions of the code made available from the public distribution points ( http://www.bx.psu.edu/hg/galaxy galaxy_dist or http://bitbucket.org/galaxy/galaxy-dist/ ) are stable. We have a rigorous testing harness in place that is continually being enhanced, and each new change set is tested within this framework automatically. All unit and functional tests must pass before the new change set is pushed to the public distribution points.
That's great to hear.
Those downloading the distribution for for the first time should feel confident that the release is stable.
Indeed it is.
Those updating existing instances with a new version should feel just as confident. Obviously, if proprietary changes were made to a specific instance, updating that instance is a bit trickier since our test harness will not cover those proprietary changes to the local instance ( and a code merge will potentially be necessary ).
This is where things could get messy (and why I don't do it regularly) as it would be useful to get an insight into what changes to epxect before doing the update. It will help to verify that the merge was successful. It could be that I'm not managing the changes optimally. Is there an ideal way to manage local changes within the context of upstream changes with mercurial?
(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.
I concur. Cheers, Chris