<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=us-ascii">
</head>
<body dir="auto">
<div>Well that's absolutely fair enough Nat. &nbsp;I &nbsp;do think a &quot;quick patch&quot; system would be certainly very useful for correcting minor things, as you suggest - if of course you can squeeze it in along with everything else(!). &nbsp;We can then download full updates,
 as and when they become available. &nbsp;I keep my personal version of Phenix fairly up to date with some of the nightly builds - &nbsp;but only implement full releases on my team's computers, to minimise my time spent on admin.&nbsp;</div>
<div><br>
</div>
<div>Just to say a big thank you for all your current and future(!) hard work on Phenix.</div>
<div><br>
</div>
<div>With regards, Antony.&nbsp;</div>
<div><br>
Sent from my iPhone</div>
<div><br>
On 6 Apr 2013, at 18:06, &quot;Nathaniel Echols&quot; &lt;<a href="mailto:nechols@lbl.gov">nechols@lbl.gov</a>&gt; wrote:<br>
<br>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">
<div class="gmail_extra">On Sat, Apr 6, 2013 at 9:18 AM, Antony Oliver <span dir="ltr">
&lt;<a href="mailto:Antony.Oliver@sussex.ac.uk" target="_blank">Antony.Oliver@sussex.ac.uk</a>&gt;</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? &nbsp;- yes I do. &nbsp;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.&nbsp;</div>
<div>Massively reduces the file sizes of downloads.&nbsp;</div>
<div>I too would like something like this implemented in Phenix if at all possible.&nbsp;</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. &nbsp;And I have another half-dozen projects which involve actual science. &nbsp;Before the nightly builds were
 automated, Paul (who certainly has much better things to do) had build each new installer manually. &nbsp;Unlike CCP4, our funding sources do not provide much if any support for this process. &nbsp;(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. &nbsp;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. &nbsp;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. &nbsp;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 &quot;revision control style&quot;, 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. &nbsp;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. &nbsp;(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. &nbsp;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. &nbsp;(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>
</div>
</blockquote>
<blockquote type="cite">
<div><span>_______________________________________________</span><br>
<span>phenixbb mailing list</span><br>
<span><a href="mailto:phenixbb@phenix-online.org">phenixbb@phenix-online.org</a></span><br>
<span><a href="http://phenix-online.org/mailman/listinfo/phenixbb">http://phenix-online.org/mailman/listinfo/phenixbb</a></span><br>
</div>
</blockquote>
</body>
</html>