[Squeakfoundation]Incorporating removals & KCP stuff

Stephane Ducasse ducasse at iam.unibe.ch
Wed May 7 17:58:55 CEST 2003


I agree with markus
Especially because cleaning the kernel and morph is not easy.

Stef

On Wednesday, May 7, 2003, at 10:46 AM, Marcus Denker wrote:

> On Wed, May 07, 2003 at 02:19:57AM +0200, Daniel Vainsencher wrote:
>> I say just split the removals. Notify the owners/on squeak-dev, and
>> remove only the packages that can return. We can do the other removals
>> either as people fix the packages or next release. Let's just get it
>> over with, so we can go back to work.
>>
>> Do that, I'll test vs. KCP, we load KCP, and then resume harvesting 
>> the
>> regular stuff.
>>
>
> I think we need to find a harvesting-process that is more "parallel":
> The main problem with the current process is that it isn't very
> friendly to simple changes. E.g. if I post a changeset that simply
> deletes an test-method that was rewritten as a SUNIT-test, I somewhat
> would like to see this harvested in a speed that is somewhat related
> to the complexity of that change: If this takes 3 weeks, it
> *completely* destroys my enthusiasm to do more simple (but important)
> refactorings. And, I guess I won't ever spend a long time "lobbying"
> for inclusion of a 1 line chaneset... this is *silly*.
>
> Another thing: KCP and MCP are ongoing projects. So we can't plan
> do "resume adding fixes after KCP": There won't be any such point
> in time. We need to do this in parallel, even if it breaks stuff.
> I think *every* contributor will happily change their stuff if
> it breaks because something else has added: As long as people
> get the feeling that we are moving, they will tolerate this. And
> even be happy to do this. But not adding stuff because it could
> (maybe) break something that should be added soon will get us
> nowhere.
>
> Another problem: The reviewing-process is too complicated.
> And in a funny way: Not what you should do, but these strange
> 2-charakter-codes are really the main reason why no-one is
> reviewing changes... too complicated. Maybe we should only add
> another tag at the end [REVIEW] and then write full words in
> the body of the mail. For this review-mail, we could provide a
> template on the wiki: This would serve as a kind of "guideline"
> for the review, and so make reviews much easier.
>
>     Marcus
>
> -- 
> Marcus Denker marcus at ira.uka.de  -- Squeak! http://squeak.de
>
> <mime-attachment>_______________________________________________
> Squeakfoundation mailing list
> Squeakfoundation at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/squeakfoundation



More information about the Squeakfoundation mailing list