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