Hi Bernard

I think the explanation lies in the following

Let us assume we have the following situation in the trunk

A.
update n
update n-1
update n-2
update n-3

Then an update n+1 is made:

B.
update n+1
update n
update n-1
update n-2
update n-3

and _immediately_ after it is discovered (within a few hours) that
update n+1 needs to be reverted and that is done so we have C

C.
update n+ 2 = revert of update n+1
update n+1
update n
update n-1
update n-2
update n-3

Then somebody detects this _BEFORE_ an update n+3 is made.
And deletes
update n+ 2 = revert of update n+1
update n+1


Then the situation is now

D
update n
update n-1
update n-2
update n-3

and this is indeed A.
No history to keep track of. The argument is that if an issue is
detected within a reasonable short time it does not need to be
recorded as history.

This was discussed a few months ago on the list.

Cases where this happens are actually rare (about every 6 months) and
the general recommendation is to discuss things in the inbox first.

--Hannes


On 10/19/18, Bernhard Pieber <bernhard at pieber.com> wrote:
> Hi Chris,
>
> It seems that you are quite annoyed and I assure you it is not my intention
> to annoy you any further. However, I would like to clarify one thing because
> it might make it easier for me to see where you come from. I have always
> thought that the moment something is pushed to trunk it becomes part of the
> history. Therefore I thought moving to Treated should only happen from
> Inbox. As you said "It never was history" you must mean somehing slightly
> different by history, right? I wonder what exactly?
>
> Cheers,
> Bernhard
>
>> Am 18.10.2018 um 02:43 schrieb Chris Muller <asqueaker at gmail.com>:
>>
>> On Wed, Oct 17, 2018 at 5:51 PM Bert Freudenberg <bert at freudenbergs.de>
>> wrote:
>> On Wed, Oct 17, 2018 at 3:00 PM Chris Muller <asqueaker at gmail.com> wrote:
>> > the issue at stake here is the sanctity of the version history.
>>
>> "Sanctity."   If only you REALLY felt that way...    :(
>>
>> 🤔
>>
>> ...then you would want the history to be usable by reflecting meaningful
>> changes, and not noise.
>>
>> 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.
>>
>>
>> > It's untouchable. Think of it as immutable, append-only.
>>
>> Versions buried more than one or two deep are untouchable.  The top
>> version(s) are not.  Reverting to a prior version IS a use-case.
>> Deleting or moving a version IS a use-case.  There are UI commands to
>> do them.
>>
>> Nope. Not in Trunk. Only trunk admins can move versions. Because it is a
>> last-resort option when all else fails.
>>
>> Yes, it is a last resort.  I'm sure we can do what's necessary to avoid
>> having to resort to it.
>>
>> The discussion is preserved in the mailing list, we don't need or want it
>> in the trunk artifact.
>>
>> Removing a short-term in-and-out caused no harm.  Leaving it in does.
>>
>>
>> > 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.
>>
>> You have a penchant for stating things as "facts" without offering any
>> rationale whatsoever.  I could do something similar by only
>> saying,"it's rarely preferable to revert a commit by a subsequent
>> commit," with no basis.
>>
>> It's a commonly accepted practices in our field:
>>
>> "since so much work is local within your clone, you have a great deal of
>> freedom to rewrite your history locally. 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. "
>>
>> Another "should" statement, and yes, sometimes there is good reason.
>>
>>
>>
>> > Patrick did that, and nobody was adversely affected.
>>
>> No!  We've been through this but, since you're Bert...   you're
>> conflating what you think is a "miniscule adverse effect" with "no
>> adverse effect".   In truth the  __breadth__  of the impact is not
>> miniscule:
>>
>>   - *Every client of every user* is adversely affected.
>>   - *Every dimension of the hardware* is affected (memory, storage,
>> network).
>>   - And software -- the usability of the code repository and ancestral
>> model.
>>   - *Every future user* and their hard drives, memorys, and networks
>> will also be adversely affected.
>>   - These adverse effects are _permanent_,
>>             even though they were conjured committed in only minutes
>> from a whimsy.
>>
>> Growing the universe by 0.1% is a big deal that advsersely affects
>> everybody whether they realize it or not.
>>
>> It was only by admin'ing, that nobody will be adversely affected.
>>
>> Sorry, I did not understand that you are worried about the physical
>> history size.
>>
>> 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.
>>
>>
>> > Our rules about caution, restraint, doubt etc are to prevent these
>> > critical problems from occurring, not to keep the version history
>> > "pretty".
>>
>> Stop mischaracterizing the reason for maintaining a quality ancestry
>> and code repository.
>>
>> I did not get that, sorry again. I also do not agree with it. We should
>> fix our tools, not change history.
>>
>> It never was history.
>>
>> What about the real-world cost?
>>
>> Is there a single real-world benefit?  You haven't mentioned a single
>> compelling one, just "should".
>>
>>
>> > 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.
>>
>> Of course.  That's why it says "Guidelines" not "Rules".  This was
>> written to instill a conservative approach to committing.  It really
>> is a good approach for something you consider immutable.
>>
>> As I said before, "hopefully it won't happen very often, but if it
>> does..."  Rest assured, I don't enjoy being this "bad guy"...   :(
>>
>> In a community as small as ours I think it's more valuable to be proactive
>> than conservative.
>> 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.
>>
>> 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.
>>
>>  - Chris
>
>
>