On Sun, Mar 28, 2010 at 2:00 PM, Michael Roberts <mike@mjr104.co.uk> wrote:
... i have been looking at the situation. It is tricky. Ideally the
help would be near the code it is the help for. That way any API
described in help could be updated as the code is updated. I want to,
for example, commit some network help.

However, as pointed out, the core help classes are not in the core
image so the help can't be loaded and therefore can't go in the core
monticello package.

That's why I said it was not as easy as it seemed to be :)
�

This could be solved by having the few classes required to define help
in the core image. Or, we could look at extending the help system to
use pragmas to annotate the necessary methods without needing to
subclass CustomHelp.


I like very much this apporoach. It would like to have:

Metacello-Core
Metacello-Documentation

and put in Documentation methods with pragmas. Or even those methods can be directly in Monticello-Core

Then, when someone install HelpSystem (probably, not in the core but in the Dev), it search the pragmas and makes the HelpSystem with that.
Similar to the new menu registration scheme with the difference that the one who looks the pragmas and do something, is not in the core but in a separate package.

�
The other thing, is that in the HelpSystem project, there is a naming
convention already in use e.g Metacello-Help. So in principle I would
upload a new package Monticello-Help.

Yes, it would be cool to define a convention. Help or Documentation ? which seems to be more abstract for you ?
�

However, Monticello is already defined in the core image as a package,
so if I create a package Monticello-Help I dirty the core package.


Ufffff yes...we always have the same problem with this....

�
So what should I do? I was thinking of uploading MonticelloHelp in the
short term to the help system project. �Or I can just add the help to
the PharoProject-Help.

Perhaps we should think about the help system a bit more deeply, in
case we want a convention we can follow for the long-term and scales.

thanks,
Mike

On Sun, Mar 28, 2010 at 5:01 PM, St�phane Ducasse
<stephane.ducasse@inria.fr> wrote:
> yes
>
> On Mar 28, 2010, at 5:43 PM, laurent laffont wrote:
>
>>
>> 2010/3/28 Mariano Martinez Peck <marianopeck@gmail.com>
>>
>>
>> On Fri, Mar 26, 2010 at 5:37 AM, St�phane Ducasse <stephane.ducasse@inria.fr> wrote:
>> Excellent idea.
>> I do not know where is the story about the help system. I would like something extremely simple.
>>
>> Published in the pharo inbox and I will merge it.
>>
>>
>> This is not as easy as that. If I understood correctly, he said HelpSystem classes. That is, extensions, to Torsten's HelpSystem.
>> Which is in http://www.squeaksource.com/HelpSystem
>>
>> That package is not in PharoCore, neither in PharoDev images for the moment (It can be added for PharoDev 1.1 if people want).
>> So...you will commit those classes....but if there is no HelpSystem, it has no sense.
>>
>>
>> Is there a sense in having a sort of Staging repository for things waiting for inclusion in Pharo ? Like the Linux kernel development process. If a package in Staging has a minimum of activity, developers around it, tests passes, then it goes into next Pharo major release.
>>
>> So you can put ConfigurationOfHelpSystem in Staging. Michael can add its package too.
>>
>> I also like the 2 weeks merge window of Linux where new modules are added. Then the merge window closes and begin the test / fix / debug process with several rc released. So new major versions are produced quite often and it's easy to upgrade from one major version to another one.
>>
>> Laurent Laffont
>>
>>
>> Cheers
>>
>> Mariano
>>
>>
>>
>> On Mar 25, 2010, at 7:40 PM, Michael Roberts wrote:
>>
>> > Hi, based on Lukas' recent blog post about Monticello merging, I
>> > created some help system classes for this content. �What is the best
>> > way to integrate this? �We have our own version of Monticello in the
>> > Pharo repository. Which package, would we add it to? �Or do we want to
>> > add it upstream somewhere?
>> >
>> > Also, has anyone thought or spiked some simple formatting? that would
>> > be really nice.
>> >
>> > thanks,
>> > Mike
>> >
>> > _______________________________________________
>> > Pharo-project mailing list
>> > Pharo-project@lists.gforge.inria.fr
>> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>>
>> _______________________________________________
>> Pharo-project mailing list
>> Pharo-project@lists.gforge.inria.fr
>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>
>
> _______________________________________________
> Pharo-project mailing list
> Pharo-project@lists.gforge.inria.fr
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
>

_______________________________________________
Pharo-project mailing list
Pharo-project@lists.gforge.inria.fr
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project