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

🤔


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

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


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

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

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

- Bert -
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20181017/7a40f81e/attachment.html>