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(a)bx.psu.edu http://mail.bx.psu.edu/cgi-bin/mailman/listinfo/galaxy-dev

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(a)bx.psu.edu >> http://mail.bx.psu.edu/cgi-bin/mailman/listinfo/galaxy-dev > > > _______________________________________________ > galaxy-dev mailing list > galaxy-dev(a)bx.psu.edu > http://mail.bx.psu.edu/cgi-bin/mailman/listinfo/galaxy-dev > >

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?