next steps for pharo

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

next steps for pharo

Torsten Bergmann
I think we can could/should not really force people to it
but at least work on this and add support for cleaning.

For instance blocking the Monticello upload in 1.3 if a package
does not follow certain criterias would not be a good
idea!

We want to continue accepting solutions even if they are not 100%
(since the definition of 100% sometimes depends on the POV and
we may end up with code Bureaucracy and maybe less developers).

Pharo should continue to be fun but we want more discipline.

IMHO we should:

 1. do it step by step by more repacking and documenting
    (see the already repackaged announcements and regex,
     Sunit will follow with issue 3445)

    => we need cleaned exemplary packages so people
       are able to follow the patterns

 2. Define lint checks and make them instantly available via
    browser tools. Maybe you know the VisualWorks browser where
    you have the checks in a tab beside the code pane where
    one could instantly check and see problems in code.

    Eclipse has that too with Checkstyle/"the Problem view".

    I would like to see that in standard browser.

 3. Define minimum criterias a core/dev package must have
    to be part of the system (unloadable, cleaned up dependency,
    class comments, have tests, ...)

 4. Give a visual feedback (icon) if the package is not "clean",
    so people get a bad feeling when they see this on their
    packages and work towards cleaning.    

    We can also have a package ranking ("the most clean" or
    "package of the month", ... ;)
   
Just $0.02

Bye
T.
   






--
GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
gratis Handy-Flat! http://portal.gmx.net/de/go/dsl

Reply | Threaded
Open this post in threaded view
|

Re: next steps for pharo

Stéphane Ducasse

On Jan 3, 2011, at 7:57 PM, Torsten Bergmann wrote:

> I think we can could/should not really force people to it
> but at least work on this and add support for cleaning.
>
> For instance blocking the Monticello upload in 1.3 if a package
> does not follow certain criterias would not be a good
> idea!
>
> We want to continue accepting solutions even if they are not 100%
> (since the definition of 100% sometimes depends on the POV and
> we may end up with code Bureaucracy and maybe less developers).
>
> Pharo should continue to be fun but we want more discipline.
>
> IMHO we should:
>
> 1. do it step by step by more repacking and documenting
>    (see the already repackaged announcements and regex,
>     Sunit will follow with issue 3445)
>
>    => we need cleaned exemplary packages so people
>       are able to follow the patterns

yes!!!

> 2. Define lint checks and make them instantly available via
>    browser tools. Maybe you know the VisualWorks browser where
>    you have the checks in a tab beside the code pane where
>    one could instantly check and see problems in code.
>
>    Eclipse has that too with Checkstyle/"the Problem view".
>
>    I would like to see that in standard browser.

Yes now the standard browser code is bad so.

> 3. Define minimum criterias a core/dev package must have
>    to be part of the system (unloadable, cleaned up dependency,
>    class comments, have tests, ...)
>
> 4. Give a visual feedback (icon) if the package is not "clean",
>    so people get a bad feeling when they see this on their
>    packages and work towards cleaning.    
>
>    We can also have a package ranking ("the most clean" or
>    "package of the month", ... ;)

The coolest programmer of the month ;)

>
> Just $0.02
>
> Bye
> T.
>
>
>
>
>
>
>
> --
> GMX DSL Doppel-Flat ab 19,99 Euro/mtl.! Jetzt mit
> gratis Handy-Flat! http://portal.gmx.net/de/go/dsl
>