The Trunk: KernelTests-cmm.173.mcz

Chris Muller uploaded a new version of KernelTests to project The Trunk:
http://source.squeak.org/trunk/KernelTests-cmm.173.mcz

==================== Summary ====================

Name: KernelTests-cmm.173
Author: cmm
Time: 7 January 2011, 10:29:46.085 am
UUID: e596c528-28a9-4198-82d6-6a69cee1ca33
Ancestors: KernelTests-cmm.169

Resaving to gain highest version # for trunk update process.

=============== Diff against KernelTests-cmm.169 ===============

Hmmm..  Levente was right, it didn't work, but I'm still really not
sure why..!  Why can't we have an addition followed by removal in the
same update?

Anyway, does trunk have a reverse gear?  I went ahead and moved
KernelTests-ar.171 and 172 to the Inbox, so we can merge them back in
to trunk once it represents 4.3.

I hope this puts trunk back on on the 4.2 track.

 - Chris


On Fri, Jan 7, 2011 at 10:30 AM,  <[hidden email]> wrote:

On Fri, 7 Jan 2011, Chris Muller wrote:

> Hmmm..  Levente was right, it didn't work, but I'm still really not
> sure why..!  Why can't we have an addition followed by removal in the
> same update?

Because there are two branches which will be merged automatically. Your
branch doesn't add the FloatConsistencyTests, but the other branch does,
so it appears in the merged version.

>
> Anyway, does trunk have a reverse gear?  I went ahead and moved
> KernelTests-ar.171 and 172 to the Inbox, so we can merge them back in
> to trunk once it represents 4.3.
>
> I hope this puts trunk back on on the 4.2 track.

This is a really bad idea, because all trunk images that have those
packages loaded are now in an inconsistent state. Also the version number
won't identify the exact set of packages in the image, because different
images with the same version number can co-exist now.

The proper way to do this is to:
- move the versions ar.171 and 172 to the Trunk
- update your image
- remove all the stuff that you don't want to see in the image by hand
- save a new version to the Trunk with those changes

I'll do this ASAP.


Levente

On 1/7/2011 6:00 PM, Chris Muller wrote:
> Hmmm..  Levente was right, it didn't work, but I'm still really not
> sure why..!  Why can't we have an addition followed by removal in the
> same update?

Because the update process *merges* (this is so that it doesn't nuke the
changes you've done in your own images). But since you you've merely
merged an earlier version that merge won't remove any additions that
have been added in the other branch.

> Anyway, does trunk have a reverse gear?  I went ahead and moved
> KernelTests-ar.171 and 172 to the Inbox, so we can merge them back in
> to trunk once it represents 4.3.
>
> I hope this puts trunk back on on the 4.2 track.

This should work as long as people reload the earlier versions manually,
but the correct way of achieving the desired result is by removing the
changes, not by posting an older version with a later update number.

Cheers,
   - Andreas

On Fri, 7 Jan 2011, Levente Uzonyi wrote:

It's done in KernelTests-ul.173. Btw where did KernelTests-cmm.173 go?
It's not in the Trunk.


Levente

>> Hmmm..  Levente was right, it didn't work, but I'm still really not
>> sure why..!  Why can't we have an addition followed by removal in the
>> same update?
>
> Because there are two branches which will be merged automatically. Your
> branch doesn't add the FloatConsistencyTests, but the other branch does, so
> it appears in the merged version.

Ah.  I thought it would find the youngest (or, highest version #)
package and then merge just that branch.  But, in fact, it merges ALL
branches.

And that makes complete sense for development; branches occur!  It
isn't often that we have branches in our trunk for very long because
we're small and good at keeping it merged; but it makes sense now.

Oh, the version # is the sum of the package version numbers.  Thanks
for the reminder.

 - Chris

> ... Btw where did KernelTests-cmm.173 go? It's
> not in the Trunk.

When I saw it didn't work, I deleted it from the trunk.

Am 2011-01-07 um 20:30 schrieb Chris Muller:
>> ... Btw where did KernelTests-cmm.173 go? It's
>> not in the Trunk.
>
> When I saw it didn't work, I deleted it from the trunk.
>

Sorry for ranting, but don't we have the Inbox for such experiment?
No offence meant. However, I'd opt for such experiments first tested
in Inbox.
The same for 'The Trunk: KernelTests-ar.169.mcz' <[hidden email]>,
which even _states_ that this is experimental.

Just my 2ct.

So Long
        -Tobias

> Sorry for ranting, but don't we have the Inbox for such experiment?

I wasn't "experimenting" I was fixing.  The Inbox is only useful for
testing changes to Squeak.  I was trying to get the trunk _itself_
back on course after we decided to backout the FloatMathPlugin chnages
from 4.2.

But yes, it is a fine time for us to remember the purpose of the
Inbox.  Thanks for that, apology accepted.

 - Chris


On Fri, Jan 7, 2011 at 2:06 PM, Tobias Pape <[hidden email]> wrote:

On Fri, 7 Jan 2011, Tobias Pape wrote:

> Am 2011-01-07 um 20:30 schrieb Chris Muller:
>>> ... Btw where did KernelTests-cmm.173 go? It's
>>> not in the Trunk.
>>
>> When I saw it didn't work, I deleted it from the trunk.
>>
>
> Sorry for ranting, but don't we have the Inbox for such experiment?

AFAIK the way the Trunk's update process works is not well documented.
There are some basic, but unwritten rules (e.g.: don't remove mczs from
the Trunk if you don't have to, don't break the update process, create a
new mcm to handle dependencies, run all tests with all the packages that
you're about to add to the Trunk, etc) which are not always followed.
I think we need much better documentation to have more active core
developers. A build server could also make our life simpler, but that
project seems to be stalled somewhere (maybe it's the java installation,
but that would be strange).

> No offence meant. However, I'd opt for such experiments first tested
> in Inbox.

That's exactly how it should be, but I'm not sure that automatic updates
can be fully tested from the Inbox.

> The same for 'The Trunk: KernelTests-ar.169.mcz' <[hidden email]>,
> which even _states_ that this is experimental.

It was in the Inbox for twelve days, so the community had quite some
time to test it. Noone took the time to test it with SqueakVM or report
the problems before it was (implicitly) added to the Trunk.


Levente

>
> Just my 2ct.
>
> So Long
> -Tobias
>

2011/1/8 Levente Uzonyi <[hidden email]>