<div dir="ltr"><div class="gmail_quote"><div dir="ltr">On Wed, Oct 17, 2018 at 5:51 PM Bert Freudenberg <<a href="mailto:bert@freudenbergs.de">bert@freudenbergs.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><span style="font-family:Arial,Helvetica,sans-serif;color:rgb(34,34,34)">On Wed, Oct 17, 2018 at 3:00 PM Chris Muller <<a href="mailto:asqueaker@gmail.com" target="_blank">asqueaker@gmail.com</a>> wrote:</span><br></div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">> the issue at stake here is the sanctity of the version history.<br>
<br>
"Sanctity." If only you REALLY felt that way... :(<br></blockquote><div><br></div><div>🤔</div></div></div></div></blockquote><div><br></div><div>...then you would want the history to be usable by reflecting meaningful changes, and not noise.</div><div><br></div><div>It's not a raw tape of a tape-recorder, but our creation as a community which is meant to be _useful_ to future consumers.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div></div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
> It's untouchable. Think of it as immutable, append-only.<br>
<br>
Versions buried more than one or two deep are untouchable. The top<br>
version(s) are not. Reverting to a prior version IS a use-case.<br>
Deleting or moving a version IS a use-case. There are UI commands to<br>
do them.<br></blockquote><div><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Nope. Not in Trunk. Only trunk admins can move versions. Because it is a last-resort option when all else fails.</div></div></div></div></blockquote><div><br></div><div>Yes, it is a last resort. I'm sure we can do what's necessary to avoid having to resort to it.</div><div><br></div><div>The discussion is preserved in the mailing list, we don't need or want it in the trunk artifact.</div><div><br></div><div>Removing a short-term in-and-out caused no harm. Leaving it in does.<br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
> Unless some commit actually breaks the update stream or does some other kind of major damage to users systems, it is always preferable to revert that commit by a subsequent commit.<br>
<br>
You have a penchant for stating things as "facts" without offering any<br>
rationale whatsoever. I could do something similar by only<br>
saying,"it's rarely preferable to revert a commit by a subsequent<br>
commit," with no basis.<br></blockquote><div><br></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">It's a commonly accepted practices in our field:</div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">"<span style="color:rgb(78,68,60);font-family:sans-serif;font-size:12px;background-color:rgb(252,252,250)">since so much work is local within your clone, you have a great deal of freedom to rewrite your history </span><span style="font-style:italic;box-sizing:border-box;color:rgb(78,68,60);font-family:sans-serif;font-size:12px">locally</span><span style="color:rgb(78,68,60);font-family:sans-serif;font-size:12px;background-color:rgb(252,252,250)">. However, once you push your work, it is a different story entirely, and you should consider pushed work as final unless you have good reason to change it. "</span></div></div></div></div></div></blockquote><div><br></div><div>Another "should" statement, and yes, sometimes there is good reason.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
> Patrick did that, and nobody was adversely affected.<br>
<br>
No! We've been through this but, since you're Bert... you're<br>
conflating what you think is a "miniscule adverse effect" with "no<br>
adverse effect". In truth the __breadth__ of the impact is not<br>
miniscule:<br>
<br>
- *Every client of every user* is adversely affected.<br>
- *Every dimension of the hardware* is affected (memory, storage, network).<br>
- And software -- the usability of the code repository and ancestral model.<br>
- *Every future user* and their hard drives, memorys, and networks<br>
will also be adversely affected.<br>
- These adverse effects are _permanent_,<br>
even though they were conjured committed in only minutes<br>
from a whimsy.<br>
<br>
Growing the universe by 0.1% is a big deal that advsersely affects<br>
everybody whether they realize it or not.<br>
<br>
It was only by admin'ing, that nobody will be adversely affected.<br></blockquote><div><br></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">Sorry, I did not understand that you are worried about the physical history size.</div></div></div></div></div></blockquote><div><br></div><div>Just because we don't need or want to enshrine 2K worth of "discussion" in the trunk artifact and add 2K*(that .mcz file + every future .mcz file) * (every copy of that file on a computer (package-cache, etc.) * (every computer using Squeak), + (every running image memory) + (network transit) + (cpu) etc. etc., doesn't mean I'm actively "worried" about something. It would be like me saying to you, "I did not understand that you are worried about performance". You may not be while still not necessarily wanting to degrade something down when given a choice not to.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
> Our rules about caution, restraint, doubt etc are to prevent these critical problems from occurring, not to keep the version history "pretty".<br>
<br>
Stop mischaracterizing the reason for maintaining a quality ancestry<br>
and code repository.</blockquote><div><br></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">I did not get that, sorry again. I also do not agree with it. We should fix our tools, not change history.</div></div></div></div></div></blockquote><div><br></div><div>It never was history.</div><div><br></div><div>What about the real-world cost?</div><div><br></div><div>Is there a single real-world benefit? You haven't mentioned a single compelling one, just "should".</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">
> Also, I agree with Levente that your "inbox first" rule is not actually what we agreed upon. When we promote someone to core developer we trust them enough to judge whether to put stuff into trunk directly or not.<br>
<br>
Of course. That's why it says "Guidelines" not "Rules". This was<br>
written to instill a conservative approach to committing. It really<br>
is a good approach for something you consider immutable.<br>
<br>
As I said before, "hopefully it won't happen very often, but if it<br>
does..." Rest assured, I don't enjoy being this "bad guy"... :(<br></blockquote><div><br></div><div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">In a community as small as ours I think it's more valuable to be proactive than conservative.</div></div></div></div></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div dir="ltr"><div class="gmail_quote"><div><div style="font-family:arial,helvetica,sans-serif;font-size:small;color:rgb(0,0,0)">That was the original vision of the trunk development process - removing the gatekeepers, empowering individual developers. I still think that's a fundamentally good idea.</div></div></div></div></div></blockquote><div><br></div><div>Right, but this has nothing to do with any of that. The state of the trunk is still where you left it, and you are just as empowered as you always were. Nothing changed, there was an obvious "oops", it never was "history", so it was moved to Treated. We should honor the spirit of the New Community Development Model. The ancestry is not a tape-recorder like in git culture.</div><div><br></div><div> - Chris</div></div></div>