[squeak-dev] The Trunk: Graphics-pre.405.mcz

Chris Muller asqueaker at gmail.com
Wed Oct 17 21:59:51 UTC 2018


> the issue at stake here is the sanctity of the version history.

"Sanctity."   If only you REALLY felt that way...    :(

> 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.

> 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.

> 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.

> 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.

> 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"...   :(


More information about the Squeak-dev mailing list