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 hadn't realised that checking out using the standard instructions resulted in the same code running as Galaxy Main. In fact when we first followed the installation instructions we got something that looked like Galaxy Test. Looking at the most recent wiki I see this is all much clearer now. Still however good the automated testing, from an admin point of view it is good to have known releases which can have a known list of issues. Also the main issue Chris raised I think was having a change list. 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. Cheers, Stewart On 8/09/2009, at 8:32 PM, Greg Von Kuster wrote:
Stewart, you have some good points, so I'll add some of my feedback inline with yours. I'll answer other concerns in the separate threads.
Greg Von Kuster Galaxy development Team
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.
I agree that there would be benefits with doing this, but it would also introduce some issues ( detailed a bit below ). 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.
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!
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.
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.
This is one of the strengths of our current approach - there have been numerous times where bugs were reported and corrected such that the current work was not significantly hindered due to long waits for a new release.
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.
Again, significant testing occurs prior to the code being made available, and the test harness covers a high percentage of real-world scenarios. If bugs are reported that were not found with the test harness, additional tests are introduced that will cover those issues from that point on. Those downloading the distribution for for the first time should feel confident that the release is stable. 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 ).
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.
We have actually been discussing ideas like these in our development lab for some time, and this message thread will force us to revisit this subject. We'll let everyone know of any changes in our processes as we define them and begin to use them.
(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
_______________________________________________ galaxy-dev mailing list galaxy-dev@bx.psu.edu http://mail.bx.psu.edu/cgi-bin/mailman/listinfo/galaxy-dev
-- Stewart Stevens PhD Student University of Otago Department of Biochemistry Tel: +64(0)3 479 7863 Fax: +64(0)3 479 7866