ancestry vs. log

> Hi Marcel,
>
> You were away when we had some discussions, so you missed some good analysis:
>
> > <offtopic> Anyway, there is no such thing as "garbage version in the
> > ancestry". This is not George Orwell's 1984 where people dictate or rewrite
> > history. History becomes what has happened. If a database (back-end) or
> > algorithm gets confused with this kind of events, then that database has to
> > be fixed. Not the data. :-) Just my two cents. </offtopic>
>
> I get you.  I've liked the freedom to shoot-from-the-hip and then just
> go back and fix it since years ago when doing so got me in trouble
> with "dev process" police.  It feels natural, and a fit for us and our
> dynamic system.
>
> 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 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.

> > 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.
>
> I am replying here because my name was mentioned. I previously explained
> my use case for the "Reparent" button:
>
>   http://lists.squeakfoundation.org/pipermail/squeak-dev/2018-November/200556.html
>
> I did not intend it as a tool to encourage modifications to the
> trunk update stream, and I do not support using it for that purpose.

>> > 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.
>>
>> I am replying here because my name was mentioned. I previously explained
>> my use case for the "Reparent" button:
>>
>>  
>> http://lists.squeakfoundation.org/pipermail/squeak-dev/2018-November/200556.html
>>
>> I did not intend it as a tool to encourage modifications to the
>> trunk update stream, and I do not support using it for that purpose.
>
> The bottom line is you agree to it when it suits a purpose.
>
> I feel exactly the same way.
>
>> I have previously said, and I will repeat it here, that I agree
>> with Marcel and others that the version history in trunk must be
>> considered write-only. It should be modified only the case of an
>> emergency situation in which the update stream is broken. Period.
>
> I don't know if this is a rule designed to increase freedom, or
> posturing, but it isn't necessary.  Not only because I'm willing to
> bend over backward to work with you, but because if something is
> unsustainable, it won't care whether you're able to enforce it or not.
> Sooner or later, you'll have to change something.  Since none of us
> really enjoys thinking or talking about this, isn't "later" better?
>
> I think it's in our best interests to think of the trunk ancestry as a
> selection of improvements and "tell the story" well, instead of
> relegating it to be a unsustainable recording device.  How we get it
> to be that doesn't need to be artificially restricted, we are free to
> develop however we want.  It's not "rewriting history" if it's only
> 5-minutes old, okay?
>
>> p.s. "Shoot from the hip" and "cowboy
> <whatever>
> " are American
>> English vernacular based on our cultural mythologies. They imply
>> both positive and negative things. The positive is "follow your
>> instincts and make great things happen". The negative implies
>> following uncontrolled instincts with unpredictable outcomes. Some
>> people would consider "cowboy-style" to be a compliment, and others
>> might consider it an insult. It is usually a little of both.
>
> It's a succint and correct way to state the trade-off between
> conservative vs. loose, but nothing to do with "insults" (unless you
> don't like cowboys, I guess..).
>
>> We also have the phrase "straight shooter" which means "realiable,
>> trustworthy, honest and straighforward", ...
>
> Where I come from, it means "they mean what they say" and "say what
> they mean" .  I'm definitely that.
>
> Regards,
>   Chris

> On 04.12.2018, at 22:04, Chris Muller <[hidden email]> wrote:
>
> Hi Marcel,
>
> You were away when we had some discussions, so you missed some good analysis:
>
>> <offtopic> Anyway, there is no such thing as "garbage version in the
>> ancestry". This is not George Orwell's 1984 where people dictate or rewrite
>> history. History becomes what has happened. If a database (back-end) or
>> algorithm gets confused with this kind of events, then that database has to
>> be fixed. Not the data. :-) Just my two cents. </offtopic>
>
> I get you.  I've liked the freedom to shoot-from-the-hip and then just
> go back and fix it since years ago when doing so got me in trouble
> with "dev process" police.  It feels natural, and a fit for us and our
> dynamic system.
>
> 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 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...

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

> On 05.12.2018, at 20:55, Chris Muller <[hidden email]> 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.

>
> Hi,
>
> > On 05.12.2018, at 20:55, Chris Muller <[hidden email]> 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
> >
>
>

> 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 <[hidden email]> wrote:
> >
> > Hi,
> >
> > > On 05.12.2018, at 20:55, Chris Muller <[hidden email]> 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
> > >
> >
> >
>

> On 06.12.2018, at 03:48, David T. Lewis <[hidden email]> 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.

>
> 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 <[hidden email]> wrote:
>>>
>>> Hi,
>>>
>>>> On 05.12.2018, at 20:55, Chris Muller <[hidden email]> 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
>>>>
>>>
>>>
>>
>