> I have made the code available. Any other fork can quickly and
> easily see and load just my changes by pressing the MERGE
> button, if Monticello were being used properly, which it isn't.
>
>   
1. You are assuming that the packages have the same boundaries. So for
example in 3.11 the tests would be in a different package to the main
code. In older images the tests might be in the same package as the
implementation.

The untidiness of the image when viewed in the browser is one of the
major irks I have with squeak, please dont condemn me to have to have
the same organisations and same class names forever.

2. But if I understand this rightly, if they push merge then they don't
just get your fix, they get  all your fixes, every difference between
your package and theirs. What if they dont want all of this change, how
do they work out what is relevant to that fix? what if all the changes
present are not appropriate to them?

3. How many significant integration fixes are only restricted to one
package?

4. What if the other project doesn't want to manually cherry pick every
method. Perhaps they just want a fix for semaphores. They add that fix
to their list of fixes for their bob to integrate, how does he know what
part of the MC package is relevant to the fix that they want.

5. This has worked marvelously for 2 years since "Installer mantis" was
invented, why throw it away.
>> Who knows what your starting point was?
>>     
>
> It's called ancestors in MC
>   
I didnt mean your starting point within that one package. If you change
a message, its not the message that is the important thing, its all the
senders of that message. Those dont get recorded in the MC package.
Thats what people need to see if they are going to evaluate your fix for
use in another context.

Anyway ancestors only works if the history is intact, in which case we
are doomed to keep the same package structure for evermore
> anybody on the mantis page related to the code I just added to
> monticello
>   

> Peer review happens after the code exists, not before. I would
> then announce my change on mantis and ask for comments, say if
> the bug is fixed, and note any problems I anticipate.
>   
How are they supposed to test your bug fix in contexts other than the
one you assumed when you wrote the fix.
AFAIK merge is only useful if your branches are pretty close.
>> Your result cannot be used by anyone else until the release is
>> published. But we want projects to be able to happen in parralel, these
>> projects need to be able to pick up the fixes that they need. When a
>> project is published as a task, it specifies the fixes it needs as
>> prerequisites.
>>     
>
> Which fixes. Why should I care? I want all the fixes. I want
> everything to work right. Thats why I upgraded from Squeak 1.1. 
>   
cool.... lets all run

Installer mantis select: [ :ea | ea ensureFix ].

then we can all go home.
>> Your steps are describing the sort of process that you are used to when
>> you are hacking away at your own code. When we build an image we are not
>> hacking, we are carefully constructing pre-specified result out of
>> (hopefully) carefully crafted and documented pieces.
>>     
>
> Of course. SqueakSource is not the image. the image is not
> squeaksource. The image is built from the best working subset of
> the code in squeaksource, by loading a known-working version
> that has passed some review standards and been nicely released
> and packaged and published somewhere other than squeaksource,
> such as squeakmap, universes, or Packages, or .mcm.
>
>   
That is fine for externally managed packages.
>> Making trunk open to all committers is saying come on in lets have a
>> hack fest, this is nothing to do with building a release image.
>>     
> Of course not.
>   

Are you agreeing or disagreeing here?
>   
>> You can do your hacking in your own time, hack away all you like at the
>> image, use monticello to manage your code, but when you have the result
>> you desire you need to find a way to publish it as one of those "well
>> crafted and documented pieces" I just mentioned. If changesets dont
>> float your boat then you might have to wait for DS. But MC is no good at
>> publishing a specific change for someone to load into a 3.8 image, and
>> it does nothing to document of capture the knowledge or design intent of
>> what exactly transpired.
>>     
>>> You want us to
>>>
>>> 1. fix a bug
>>> 2. file out a changeset
>>> 3. Grab the latest image from Bob
>>>   
>>>       
>> No need, use your own starting image, you are working to a known fixed
>> point remember. 3.10.2 or more sensibly 3.10.2-build (since that is what
>> bob is starting with on every run)
>>     
>>> 4. Reaply the changeset to that image, making sure it works
>>>   
>>>       
>> Bob will apply the fix to bob's images, and hopefully testing will
>> reveal if there are any conflicts when the fix is integrated with other
>> fixes.
>>     
>>> 5. upload that changeset to mantis5.
>>>   
>>>       
>> Yes, because mantis is a tool for discussing fixes and having that
>> dialog. That's what it is designed for.
>>     
>
> yes.
>
>   
>> MC is a tool for managing code, but it doesnt have any means for
>> providing feedback, 
>>     
>
> nor should it.
>
>   
Absolutely it should. Have a look in squeaksource/MagmaTester and try
and work out what order to load packages in, or even what packages are
old. Chris often publishes a new package version but then if you look
closely he is still actually using an older version. MC gives no clues,
some feedback would enable Chris to tag a package version with, "I am
using this version at the moment". Then there is which version works in
which version of squeak, again no clues are given.
>> it is not a tool for managing fixes. 
>>     
>
> nor should it be.
>
>   
Right so why code a fix and publish it in MC, MC is for managing
packages not fixes.
>> Once you commit
>> a fix from mantis to MC it is out of mantis' hands discussion is over,
>> the code then slips under the radar, it merges into the blur of the
>> package. 
>>     
>
> Wrong. the discussion continues. I announce that the fix is
> ready in monticello, ask people to load and test it, and they
> review it.
>
>   
It ceases to be a discrete piece of code that can optionally be applied.
You have applied it to the trunk package that is the same as saying it
is now released.

Bob's building of a release is conceptually a planned atomic change to
the image. You are turning it into a slow incrementally arrived at  and
pondered result. 3.10 was done like that and how long did that take. 
>> It also possibly breaks another fix that someone submitted ages
>> ago.
>>     
>
> Hopefully that comes up in testing, and it will be noted in
> mantis.
>
>   
>> Fixes that are on the table for integration into a release should remain
>> on the table until the release is tested and out of the door.
>> If a test fails, bob could automatically apply the fixes one by one to
>> find out what caused the problem, he could reorder the application of
>> the fixes, or try different combinations, or a binary search to find the
>> problem.
>>     
>
> This is bogus. if it worked last time and it doesn't this time,
> the problem is obvious. One of the small set of new changes that
> got added in the few hours since bob tried last. Bob knows what
> those changes are, and so does everybody else, because bob
> watches the repository and lists what's new in his report.
>   
Bob loads externally managed packages from repositories, that is a given.

If he loads kernel packages from the repository then he is providing a
moving target to the fixers who are supplying fixes to mantis. The fixer
may have done the fix a year before, they dont want to have to be
continually reviewing their fix to cope with your changes. If you can
tell people that they are fixing a particular image then everyone knows
exactly where they stand.

The first time bob runs it will probably apply 100 fixes in one go.

We promised that every fix on mantis that is marked as "testing" is
going to be loaded and tested in to an image automatically. Four people
could change four fixes at once.

We are automatically integrating fixes, not manually dragging through
mantis and committing changes to a central repo like edgar had to.
>> It is also tied to the image you are using. When you use mantis to
>> publish a fix you are also publishing your fix for ALL forks of squeak
>> to adopt. A fix could be tagged as "Applies to Squeak 3.8" "Applies to
>> Gjallar0.1" so that people can pick it up for their own projects that
>> are unfortunately not able to track the latest image (i.e. most projects
>> out there of any size)
>>     
>
> The image is far too course an entity to patch against. I don't
> want to fix squeak or pharo. I want to make Rio-1.2.29 better
> than Rio 1.2.28. 
>   
Thats an externally managed package, talk to the maintainer.

> Any project should be able to understand which versions of
> packages it can afford to upgrade and which it can't. Changing
> the core from underneath a project is never a great idea.
>   
Ok so fine, every fork keeps its core exactly as it is. None of the
forks get any code in common, and they remain forks forever.

If you can upgrade your core in small manageable pieces then why not try
it? Your tests should tell you if it works or not, otherwise you need
more test coverage. If 3.11 consists of 400 documented pieces, and the
etoys maintainer discovers that they can use 200 of them, then lo and
behold the two images are several hundred methods, and several API's
closer together.

> often is.
>
>   
>> If you take mantis out of the equation you are not performing bug fixing
>> you are doing coding, and if you are doing coding you might as well go
>> off and spend a month rewriting the whole pacakge properly in order to
>> give the community something really cool to integerate and use when you
>> are done.
>>     
>
> I don't want to take Mantis out of the equation. If I did, that
> just means I don't care about the community.
>   
Then what are we talking about Mantis manges changesets, not MC
packages. You cant reliably use "Installer mantis" on an MC unless it is
a fairly standalone bit. The ONLY time I have ever used MC was for
loading fixes to MonticelloConfigurations, and even then I performed the
integration manually, and published a new release of MC1.5/LPF
>>> We have a great tool already for keeping track of code that has
>>> changed. 
>>>       
>> Yes changed in one image.
>>     
>
> One package
>   
The code you changed only makes sense in the context of the
users/callers that you were thinking about when you changed it. I.e. the
patch you made only communicates the message of design intent you want
it to communicate in your one image. So better to make that image one
that people are familiar with, i.e a fixed known starting point.
>   
>>> It's called Monticello. You use it all the time. Bob
>>> can load .mcm or .mcz packages into an image just as easily as
>>> it can load changesets from mantis.
>>>   
>>>       
>> Sure you can, but Monticello is not a bug tracker. In this case we are
>> applying bug fixes and discussing them.
>>     
>
> of course it's not a bug tracker.
>
>
>   
> everything is a package, whether it is unloadable or not. There
> will be one big one called the kernel. This should be versioned
> like any other package. Linux has Linux 2.6, glibc 2.8, gcc 4.4,
> and X.org 7.2. Thinking in terms of the image is just plain
> wrong.
>
>   
Not when you are integrating. When integrating and testing you should be
thinking in terms of all of SqueakMap not just the image.

When we are building a release we are integrating and testing a
deliverable. That deliverable is the image.
A set of packages that work together is pretty irrelevant, until it is
possible to treat them as packages, i.e remove, replace etc. We are not
yet at that stage.

Keith