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

Chris Cunningham cunningham.cb at gmail.com
Wed Oct 17 23:09:06 UTC 2018


On Wed, Oct 17, 2018, 15:51 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...    :(
>>
>
> 🤔
>
>
>> > 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. "
>
what is the source of this quote?

>
> > 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/d78bd6f7/attachment.html>


More information about the Squeak-dev mailing list