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:
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 (
) 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.
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
At the moment we get to check out
code and that does make it clear that it is development stuff and
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
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.
On 8/09/2009, at 9:12 AM, Chris Cole wrote:
> Anyone have any thoughts on this?
> Chris Cole wrote:
>> I have a local install of Galaxy and would like to keep up-to-date
>> the latest updates, but I'm not sure what functionality has changed
>> how significant the changes are. The mercurial updates on this list
>> 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.
> galaxy-dev mailing list
galaxy-dev mailing list