Hi Chris, All,

On Tue, Jul 17, 2018 at 3:09 PM, Chris Muller <ma.chris.m at gmail.com> wrote:

> Hi Hannes and all,
>
> What if someone submits code to trunk that is incompatible with the MIT
> license?
>

Or, as I have done, mistakenly submitted a version that kills any image
that loads it.


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

+1.


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

+1.  In the early Spur days I needed to do this more than once.


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

Glad to hear it :-)


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


-- 
_,,,^..^,,,_
best, Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20180717/32ef2b55/attachment.html>