> On 06.12.2018, at 03:48, David T. Lewis <lewis at mail.msen.com> wrote:
> 
> I'm not sure that "farting in a sleeping bag" is a good metaphor for
> the Squeak trunk development process. But I can live with it. After
> all, who among us has never offended?
> 
> Meanwhile, the consensus message is clear and consistent: Do not
> modify the version history unless there is a compelling reason for
> doing so.
> 
> Compelling reasons for modifying the version history might include:
> 
> 1) I just committed something that breaks the update stream, so I
> need to delete it and try again later. Apologies all around, but
> breaking the update stream is not permitted, and I have to fix it.
> 
> 2) I just committed some embarassing garbage, but it has only been
> five minutes since I committed it, so I want to get rid of my mess
> before anybody notices. As long as I erase my mistake before other
> people start updating from trunk, it is not a problem, so this
> should be acceptable too. I will also make sure to mention it on
> squeak-dev and apologize for any confusion just in case someone
> actually did do an update during that five minute window.
> 
> Things that are not good reasons for modifying version history:
> 
> 1) I committed something yesterday, but someone on squeak-dev
> pointed out that my change is not a good thing, so I revert my
> change and restore the original implementation. The changes actually
> happened, so no one should not try to compress the version history
> and make them go away.
> 
> 2) I commit something that I think makes sense, but other people
> start debating it. A few more updates happen, and the end result
> is different from what I originally intended. These are changes
> that actually happened, so no one should not try to eliminate the
> intermediate versions.

I can get behind that, that mirrors exactly my view.

+1 from me, we can even codify this somewhere :)

Best regards
	-Tobias

> 
> Dave
> 
> On Wed, Dec 05, 2018 at 03:37:09PM -0600, Chris Muller wrote:
>> Those are not the right questions, but I think we have consensus
>> enough.  We have to work together, Tobias.  Ultimately, peoples
>> actions are their "vote" and it doesn't change that we have to
>> continually work with our peers if there's a problem.  And don't
>> forget, unsustainability doesn't care anyway -- one can only fart in a
>> sleeping bag so many times before others will begin to leave the tent.
>> 
>> - Chris
>> On Wed, Dec 5, 2018 at 2:24 PM Tobias Pape <Das.Linux at gmx.de> wrote:
>>> 
>>> Hi,
>>> 
>>>> On 05.12.2018, at 20:55, Chris Muller <asqueaker at gmail.com> wrote:
>>>> 
>>>> Hi Tobias,
>>>> 
>>>>>> ... snip ...
>>>>>> So how can we "fix" this?  I proposed the MCInfoProxy solution several
>>>>>> years ago, but that only addresses the in-image portion, and it wasn't
>>>>>> well-received anyway.
>>>>>> 
>>>>>> I think Dave's new "Reparent" button is the best go-to right now.
>>>>>> That way, we can have the cowboy-style dev process want and then
>>>>>> "squash" out the interim versions into one pretty version that
>>>>>> concisely describes the final product.
>>>>>> 
>>>>>> We have the squeak-dev archives which records our history, but
>>>>>> Squeak's ancestry entries should contain just the development
>>>>>> artifacts that emerged, but not the abandoned ideas too.  Imagine how
>>>>>> easy the next release  notes will be to write...
>>>>> 
>>>>> I don't get it.
>>>>> 
>>>>> First, non-tunk users get none of this, Release images get only rare,
>>>>> severe updates. There's no influx of stuff. So, they're fine in the first place.
>>>> 
>>>> Wrong.  The ancestral model is stored in every one of their images.
>>>> 
>>>>> Second, trunk users are to be aware that trunk is, well, trunk, bleeding
>>>>> edge, you name it. When something breaks, tough. There's no promise. And I don't
>>>>> think there should be. So trunk users are fine by definition.
>>>> 
>>>> But, per "A New Community Development Model", breaking it is "frowned upon".
>>>> 
>>>> This is actually off-topic, but I agree that trunk users are tough, so
>>>> there's nothing "dangerous" when someone cleans a 5-minute old,
>>>> self-admitted mistake.  If someone wants to be upset, direct it toward
>>>> the bad committer, not the cleaner please!   ;-/
>>>> 
>>>>> Third, the "database bloat problem". I don't frankly see it. That's because of
>>>>> two things. First, updates are handed out as mcd's, severely cutting down the size of
>>>>> transported data. Second, for a given MCZ, the ancestry size is quite unimportant.
>>>>> It's merely a (pretty darn good compressible) string. So resource-wise we're a-ok,
>>>>> I'd say.
>>>> 
>>>> Zoom-out from looking at only your single-user self and consider the
>>>> other 3 dimensions of resource impact within the Squeak universe.  I
>>>> described this several times before:
>>>> ____________
>>>>>> But, "the database" must be carried by all current and
>>>>>> future Squeak users.  Every unnecessary commit bloats everyone's
>>>>>> current and future image files, including in RAM, and every future
>>>>>> .mcz file after that one, of which there are multple copies of each
>>>>>> (package-cache, etc.).  Add up all that duplication, and single one 2K
>>>>>> commit quickly becomes a 2MB impact to every current and future Squeak
>>>>>> users HD, RAM and network transportation.  Forever.
>>>> _____________
>>>> 
>>>> So, it's kind of like a "tax".  As an individual, you may not feel it
>>>> since its spread out, but that does not mean the impact is not real.
>>>> It's just a slow-creep, like a frog in a pot...
>>>> 
>>>>> You state "Squeak's ancestry entries should contain just the development
>>>>> artifacts that emerged, but not the abandoned ideas too." and I strongly disagree.
>>>>> Let's not get down the rabbit hole of bending the process to the tools. Rather, the
>>>>> other way round.
>>>> 
>>>> The process and tools are tightly-integrated, there is no "the other
>>>> way round" but you could make some suggestions or get behind the ones
>>>> being floated.
>>>> 
>>>> I cannot stop you polluting the trunk ancestry, I can only ask or try
>>>> to clean up after you.  Obviously, I could maintain my own, but that
>>>> would only help me, not Squeak.
>>> 
>>> Ok, we obviously have different notions. And from here on its hard to get consensus.
>>> To state it very clearly:
>>> 
>>>        I do not think there has to be a clean trunk ancestry. It shall be as dirty as
>>>        required by the community process to try out and align ideas, fixes, and features.
>>> 
>>> I read this in line with Andreas' original proposal and also seem to be in some consensus
>>> with most other trunk devs who have spoken up recently.
>>> 
>>> Since consensus is not easy, it seems majority comes into play, right?
>>> 
>>> Trunk devs, what are y'all thinking:
>>> 
>>>        [ ] Actively try to clean the ancestry and remove versions
>>>        [ ] Have the ancestry reflect the timeline of development.
>>> 
>>> 
>>> Best regards
>>>        -Tobias
>>>> 
>>>> Best,
>>>> Chris
>>>> 
>>> 
>>> 
>> 
>