> On 04.12.2018, at 22:04, Chris Muller <asqueaker at gmail.com> 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...

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.

Best regards
	-Tobias