[squeak-dev] ancestry vs. log
Das.Linux at gmx.de
Wed Dec 5 20:24:44 UTC 2018
> 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.
More information about the Squeak-dev