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

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

Hi,

Chris Cole wrote, On 09/09/2009 10:10 AM:

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?

If I may suggest one possible way - this is how we manage our local galaxy with some local changes and patches.

First - learn to use mercurial. not just "hg update", but all the nitty gritty details. I recommend the following book (available freely online): http://hgbook.red-bean.com/read/

Keep several instances of galaxy on your server. One will be the 'pure' import of what ever the galaxy team releases. (it doesn't have to be the cutting edge revision, though). pull into it when ever the galaxy team releases new changes that interest you.

Another instance (which pulls from the 'pure') can contain your local changes and patches. So each time you pull from the 'pure' version, mercurial will try to merge your local changes with the official changes. If the merge succeeds - good. if not - "hg resolve/diff/merge" are your friends.

Once you've merged, test this instance (by running "sh run.sh"). If it works - good (by 'working' I mainly refer to your local changes/patches). If not - learn to use "hg rollback/backout/bisect' to pinpoint the problem. Also - get very comfortable with "hg tags" and "hg branches" - so you can very easily go back to a last-known-working revision.

A third instance is your "production" server. it pulls from the second instance (with your local changes) only AFTER your merged and tested everything. This way - your production server is always working and stable.

In general, learn to use:

"hg inc" - will tell you what changes are ready to be pulled, WITHOUT pulling them (just print the list of changes). "hg inc --template '{rev}: {desc}\n' - will print the same list as above, but in one line per change. "hg fetch" - pull+merge+commit automatically (useful because your local changes will always create a new head when you pull - this shortcut command automatically merged the new head and commits, assuming the merge was successful. It requires some extension setup, see section "Simplifying the pull-merge-commit sequence" here: http://hgbook.red-bean.com/read/a-tour-of-mercurial-merging-work.html ). "hg update [REV]" - will allow you to switch revisions/branches/tags, and you can always be sure you can go back to a working version.

To find changes that you've added (as opposed to the galaxy team), one way is to use templates+grep, as so: "hg log --template "{author}: {rev}: {desc}\n" | grep "[YOUR NAME AS AUTHOR]" Another would be to keep all your local changes under one named branch (not "default") and merged them.

Mercurial also has a facility called "queues" or "mercurial queues (MQ)" which supposedly manages a set of patches on top of the local revision. It looks promising but I haven't yet learned how to use it.

I'll be interested in hearing how other people manage their local repositories.

-gordon.