<div dir="ltr">Hi Bert,<br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Feb 14, 2018 at 1:04 AM, Bert Freudenberg <span dir="ltr"><<a href="mailto:bert@freudenbergs.de" target="_blank">bert@freudenbergs.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><br><div class="gmail_quote"><div><div class="h5"><div dir="auto">On Tue 13. Feb 2018 at 20:38, Chris Cunningham <<a href="mailto:cunningham.cb@gmail.com" target="_blank">cunningham.cb@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>Hi Eliot,<br><div class="gmail_extra"><br><div class="gmail_quote"></div></div></div><div><div class="gmail_extra"><div class="gmail_quote">On Sun, Feb 11, 2018 at 7:56 PM, Eliot Miranda <span><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Chris,<br>
<span><br>
<br>
> On Feb 10, 2018, at 1:48 PM, Chris Cunningham <<a href="mailto:cunningham.cb@gmail.com" target="_blank">cunningham.cb@gmail.com</a>> wrote:<br>
><br>
> This one I'm going to need some help on, having never done this before (obviously).<br>
><br>
> -----<br>
> When and How to change the trunk update configuration:<br>
> * When you are adding a new package to trunk, update the configuration with the new package (just because a package is in the repository does not mean it is loaded)<br>
> * When you are removing a package from trunk, update the configuration to remove the package (and follow instructions for removing the package)<br>
> * When methods are moved from one package to another - primarily when they are used in the update logic - then create an update with the package where the method is removed and where the method is added in the same update configuration<br>
<br>
</span>That's not the safest. The safest is to create a configuration with the package to which the method is moved, but still containing the version of the package from which the method had moved which still had the method. This way, the package from which the method is moved will be marked dirty but there is no chance of the method being lost.<br>
<div class="m_-7877575674872653972m_-7658853103690707516HOEnZb"><div class="m_-7877575674872653972m_-7658853103690707516h5"><br></div></div></blockquote></div></div></div><div><div class="gmail_extra"><div class="gmail_quote"><div>I wasn't sure where the conversation between you and Bert left off on this subject. I can certainly change this to be this way - especially since it is safer (leaving the Bert enhancement to cover places where we weren't aware that happened, maybe. Although we should be aware.). </div><div><br></div><div>Another question: should we ALWAYS create a config when a method (or class) moves from one package to another?</div><div><br></div><div>-cbc</div></div></div></div></blockquote><div dir="auto"><br></div><div dir="auto"><br></div><div dir="auto"><br></div></div></div><div dir="auto">IMHO we have way too many config maps already.</div><div dir="auto"><br></div><div dir="auto">We don't need any config maps even for moving methods between packages. </div><div dir="auto"><br></div><div dir="auto">The only time when you actually need an explicit config map is when you are doing open-heart surgery on the kernel.</div></div></div></blockquote><div><br></div><div>I agree. But the question is whether we should mention this or not. For me, being able to do open heart surgery reliably is really important. And at the same time having a reliable update process is really important too. occasionally we've had broken updates, due to incorrect update maps, causing temporarily missing methods, etc, when moving code between packages. These episodes are painful; they're difficult to debug because the system is broken; they require meddling with packages and update maps on the repository. So do we err on the side of caution and document the issue, along with caveats such as "this is hyper cautious; you really shouldn't need to do this unless you're doing open heart surgery" or do we not document it and endure the occasional, rare pain of fixing things when they do break. You know me; I'm quite conservative in these things and so lean to the former. But I'm happy to be contradicted here.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><div dir="auto">This is because besides the explicit config maps, the implicit map loaded at the end of the updater usually takes care of everything. It is created on the fly by taking the last published config map and updating it with the latest packages from trunk.<br></div></div></div></blockquote><div><br></div><div>I would at least like to see this detailed somewhere in Chris's documentation of the process.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><div dir="auto"></div><div dir="auto"><br></div><div dir="auto">Creating unnecessary config maps just slows down the update process.</div></div></div></blockquote><div><br></div><div>Agreed. I create them only when I think, most likely mistakenly given my ignorance of Monticello update internals, that there's a chance I'm going to break the system. But unless I have a good understanding of the magic I'm going to find it hard to avoid creating config maps.</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_quote"><span class="HOEnZb"><font color="#888888"><div dir="auto"><br></div><div dir="auto">- Bert - </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="gmail_extra"><div class="gmail_quote"><div></div></div></div></div>
</blockquote></font></span></div></div>
<br><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><span style="font-size:small;border-collapse:separate"><div>_,,,^..^,,,_<br></div><div>best, Eliot</div></span></div></div></div>
</div></div>