<div dir="ltr"><div class="gmail_extra">On Sat, Apr 6, 2013 at 9:18 AM, Antony Oliver <span dir="ltr"><<a href="mailto:Antony.Oliver@sussex.ac.uk" target="_blank">Antony.Oliver@sussex.ac.uk</a>></span> wrote:<br><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="auto">
<div>Dare I? - yes I do. CCP4 have recently put in place a very nice update system - which essentially does exactly what Ed is suggesting / asking for. What's also nice is that updates can be installed / uninstalled as a user wishes. </div>
<div>Massively reduces the file sizes of downloads. </div>
<div>I too would like something like this implemented in Phenix if at all possible. </div></div></blockquote><div><br></div><div>The fundamental problem is this: there is exactly one person (me!) responsible for building and maintaining installers and handling the release cycle. And I have another half-dozen projects which involve actual science. Before the nightly builds were automated, Paul (who certainly has much better things to do) had build each new installer manually. Unlike CCP4, our funding sources do not provide much if any support for this process. (And needless to say, most of this stuff isn't publishable either.)</div>
<div><br></div><div>We have had internal discussions about adding an update mechanism, and I'm fairly confident I can implement something quickly that would at least address relatively simple patches like the B-factor issue. The reason I haven't done this is a) I have other things I also need to get done (some very time-sensitive), b) we are concerned about the added overhead of maintaining such a system, and c) because of the nightly builds we have slightly less motivation to rush something out. Keeping it running would require considerably modifications to our build system - the good news is that we need to change a lot of this anyway, so it may become slightly easier to manage in the future. However, the fundamental problem of too little manpower remains.</div>
<div><br></div><div>One point that needs to be clarified:</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="auto"><div><div><blockquote type="cite">
<div><div>
Given that changes between nightly builds are likely limited to relatively small patches/additions, is there some mechanism to do updates "revision control style", i.e. by downloading and updating only the parts of code that changed?</div>
</div></blockquote></div></div></div></blockquote><div>This is only true for Python code, where there is no platform dependence. Compiled code (e.g. SOLVE, RESOLVE, nearly all of Phaser, Reduce, Probe, etc.) is considerably more difficult, because we would need to rebuild the shared libraries and/or executables on each platform, and distribute those in a system-dependent matter. (Which is especially difficult right now, because we have multiple 64-bit Linux builds made on different distributions.)</div>
<div><br></div><div style>One final point: if we add an update mechanism, it would definitely *not* replace the nightly builds for getting bleeding-edge features; it would only be used to add critical fixes for problems with the official releases. The nightly builds provide us with the essential ability to quickly push experimental new code out to power users, but these aren't changes we necessarily want to inflict on the rest of our users. (And yes, I realize this makes the use of nightly builds to provide bug fixes somewhat problematic.)</div>
<div><br></div><div>-Nat</div>
</div></div></div>