[squeak-dev] ancestry vs. log

[Chris Muller]

Hi Marcel,

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

[David T. Lewis]

Post by Chris Muller
Hi Marcel,

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

Dave

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.

We also have the phrase "straight shooter" which means "realiable,
trustworthy, honest and straighforward", as contrasted with a
less reliable "shoot from the hip" sort of person. Please don't
ask me to explain why we need that many guns to describe one
another,

[Chris Muller]

Post by David T. Lewis

Post by Chris Muller
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
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.

Post by David T. Lewis
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?

Post by David T. Lewis
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..).

Post by David T. Lewis
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

[marcel.taeumel]

Hi Chris,

yes, everybody should be thoughtful with their commits. Such tools can help
repair slips in the process. We need them; we make should use them.

However, keep in mind that quality assessment of any commit can be highly
subjective. We've seen it in the past, we'll see it in the future. If one
Squeaker is not happy with an idea of another Squeaker, there will always be
room for discussion to move forward in a calm way.

Consequently, there is no way to "fix" this challenge for all eternity. It
will always be there. Some commits will make some Squeakers more happy than
others. That's the history we want to record and preserve.

Best,
Marcel

Post by Chris Muller

Post by David T. Lewis

Post by Chris Muller
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
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.

Post by David T. Lewis
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?

Post by David T. Lewis
p.s. "Shoot from the hip" and "cowboy

<whatever>
" are American

Post by David T. Lewis
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..).

Post by David T. Lewis
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

--
Sent from: http://forum.world.st/Squeak-Dev-f4

[Chris Muller]

Post by marcel.taeumel
yes, everybody should be thoughtful with their commits. Such tools can help
repair slips in the process. We need them; we make should use them.

This is my core message and I think you're the only one who ever
actually got it. Thanks Marcel.

Post by marcel.taeumel
However, keep in mind that quality assessment of any commit can be highly
subjective. We've seen it in the past, we'll see it in the future. If one
Squeaker is not happy with an idea of another Squeaker, there will always be
room for discussion to move forward in a calm way.

Right, but number of Versions per logical change is objective. IMO,
we should keep that number as close to 1 as possible. Note, "as
possible" implies that we won't always succeed.

Post by marcel.taeumel
Consequently, there is no way to "fix" this challenge for all eternity. It
will always be there. Some commits will make some Squeakers more happy than
others. That's the history we want to record and preserve.

Agree, since those are all unique "improvements". The case where we
can abandon, I hope you agree, is when a 5-minute old method, never
tested even once, is put into a new Version into trunk, breaks it, and
then immediately yanked out by another Version. As far as I'm
concerned, those two Versions have no bearing on the current and
future contents of Squeak yet, there it is, "noise" in the ancestry
that ALL of us, and ALL future Squeak users, have to carry and keep
multiple copies of

[Tobias Pape]

Post by Chris Muller
Hi Marcel,

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

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.

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.

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.

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.

[Chris Muller]

Hi Tobias,

Post by Tobias Pape

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

Post by Tobias Pape
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! ;-/

Post by Tobias Pape
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:
____________

Post by Tobias Pape

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

Post by Tobias Pape
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

[Tobias Pape]

Hi,

Post by Chris Muller
Hi Tobias,

Post by Tobias Pape

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

Post by Tobias Pape
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! ;-/

Post by Tobias Pape
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
____________

Post by Tobias Pape

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

Post by Tobias Pape
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.

[Chris Muller]

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

Post by Tobias Pape
Hi,

Post by Chris Muller
Hi Tobias,

Post by Tobias Pape

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

Post by Tobias Pape
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! ;-/

Post by Tobias Pape
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
____________

Post by Tobias Pape

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

Post by Tobias Pape
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.
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?
[ ] Actively try to clean the ancestry and remove versions
[ ] Have the ancestry reflect the timeline of development.
Best regards

[David T. Lewis]

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

Post by Chris Muller
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

Post by Tobias Pape
Hi,

Post by Chris Muller
Hi Tobias,

Post by Tobias Pape

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

Post by Tobias Pape
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! ;-/

Post by Tobias Pape
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
____________

Post by Tobias Pape

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

Post by Tobias Pape
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.
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?
[ ] Actively try to clean the ancestry and remove versions
[ ] Have the ancestry reflect the timeline of development.
Best regards
-Tobias

Post by Chris Muller
Best,
Chris

[Tobias Pape]

Post by David T. Lewis
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.
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.
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

Post by David T. Lewis
Dave

Post by Chris Muller
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

Post by Tobias Pape
Hi,

Post by Chris Muller
Hi Tobias,

Post by Tobias Pape

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

Post by Tobias Pape
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! ;-/

Post by Tobias Pape
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
____________

Post by Tobias Pape

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

Post by Tobias Pape
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.
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?
[ ] Actively try to clean the ancestry and remove versions
[ ] Have the ancestry reflect the timeline of development.
Best regards
-Tobias

Post by Chris Muller
Best,
Chr