Hi Hannes and all,

What if someone submits code to trunk that is incompatible with the MIT license?

Bottom-line:  Deleting a Version from trunk is an occasional use-case.
Period.  It's part of the administrators UI and the above may not be
the only occasion to need to do so.

Just to make sure I've acknowleged and respected and evaluated all of
your feedbacks:

  1) "totally unnecessary",
  2) "it would save almost nothing",
  3) "break the images of everyone who had updated before the
suggested removal of the verions",
  4) "causes more problems than it solves."
  5) "risky"

With all due respect, generally, none of the above is true.  This is
trunk development guys.  There is no meaningful "risk" and no
meaningful breakage by properly deleting a bad commit.

For the rare occasion when a bad commit happens, instead of shifting a
permanent cost for it onto all future code consumption for all users,
we should instead opt to incur only a very small and temporary cost
(if any!) which is also limited in scope to the one or two people who
may have updated since the bad commit.  If any special action is
required, a note to squeak-dev, but people doing trunk development
probably already know what to do.  So the impact of this is
practically zero.

Hopefully bad commits won't happen very often, but if/when one does,
you can expect me to continue to administer source.squeak.org with the
care and respect it deserves -- like a delicate flower I want to keep
healthy and preserved -- and continue to expect the same from you.
IOW, I'm asking you to regard the health of the code repository with
equal  importance to the health of the image.

Best,
  Chris



> An example of a problem (mentioned in my previous mail).
>
> 1) I updated a my working image -> the HelpBrowser error occured.
>
>
> 2) I updated my working image again, the note was
>
>          Bypass Collections.kks.801.mcz for now because it leads to a problem
>          opening the help browser.
>
> --> The HelpBrowser error was still there. So it seems that I have
> actually downloaded that Collections.kks.801.mcz which causes
> problems. Which people who update later bypass.
>
> I had to fix the issue manually. Because of the discussion in this
> list it was easy to do. But out of context it would have been hard.
>
> I agree with David that rewriting the history is risky.
>
> Chris, I think your concern is the number of files which are
> downloaded. That is indeed an issue. But it is not solved by having a
> few less here and there. Because an incident like this HelpBrowser
> breakage is comparatively rare.
>
> The issues is for example that a new Morphic...mcz is big. For every
> small change. Etoys for example could be split into different packages
> thus reducing the download size.
>
> Or even find a new way of just downloading a change set extracted from
> the mcz instead of sending the whole mcz.
>
>
> Returning to the main point of this thread and to sum up:
>
> I would welcome if an updated version of the change which caused the
> problems could be included as it is a good thing to fix.
>
> --Hannes
>
> On 7/17/18, Chris Muller <asqueaker at gmail.com> wrote:
> > On Mon, Jul 16, 2018 at 10:43 PM, David T. Lewis <lewis at mail.msen.com>
> > wrote:
> >> On Sat, Jul 14, 2018 at 05:42:32PM -0500, Chris Muller wrote:
> >>> >> So, Levente/Chris/David,
> >>> >> to fix this - do we delete the kks.801 from trunk, or alter kks.803 in
> >>> >> the
> >>> >> inbox (which seems to fix the issue) to have both dtl.802 (it's
> >>> >> current
> >>> >> parent) and kks.801 as both of its parents, which I believe
> >>> >> would solve the 'multi head' issue.
> >>> >
> >>> > Neither. The proper solution is to create a new version which merges
> >>> > the two
> >>> > branches. If the fix is in kks.803, then xxx.804 will contain the fix
> >>> > and
> >>> > have both kks.803 and kks.801 as ancestors.
> >>>
> >>> Wow.
> >>>
> >>> > It is well known that the MC model was not designed for projects of
> >>> > this size.
> >>>
> >>> Right.
> >>>
> >>> > But it would save almost nothing if that version were removed form the
> >>> > ancestry.
> >>>
> >>> Your suggestion above puts "almost nothing" at up to no less than
> >>> three new versions in the ancestry for a one method fix.  It is not
> >>> just about disk space, or memory space, or exacerbating our unscalable
> >>> dimensions, but clutter, too.  Those are mey rationale's for deleting.
> >>> I didn't catch any solid rationale for the idea of littering the
> >>> ancestry when we have the opportunity not to.
> >>>
> >>
> >> Levente,
> >>
> >> You are right, I should have simply comitted a new version of the package.
> >> I was trying to "bypass" the problem, but that was a mistake because it
> >> caused problems for the update stream. It would have been better (as you
> >> said) to have simply committed a new version.
> >>
> >> Chris,
> >>
> >> It is good to keep the update stream as clean as possible as you
> >> explained,
> >> but overall I think that Levente is right. In most cases, attempting to
> >> rewrite version history causes more problems than it solves.
> >
> > What problem(s)?
> >
> >