[squeak-dev] [ANN] Squeak 4.2

Levente Uzonyi leves at elte.hu
Sun Feb 13 01:47:09 UTC 2011

On Sat, 12 Feb 2011, Chris Muller wrote:

>>> I agree about trying to remember to keep on top of it.  Except
>>> "cleanliness" should not be the factor; we should merge to make a
>>> better Squeak, not a cleaner Inbox.  :)
>> That's the basic idea, but if the Inbox is not clean enough, then some
>> people won't use it, just like Mantis. Long pending contributions discourage
>> contributors. And we need the contributions of non-core developers, because
>> core developers are not very active nowadays.
>> I've got the following idea about keeping the Inbox clean:
>> We define a time limit for keeping a contribution in the Inbox. Something
>> like 1-2 weeks. If there's no activity about that contribution for this
>> long, then we open a ticket for it on Mantis and move it to the Treated
>> Inbox. The ticket would
>> - contain the name and comment of the mcz
>> - be attached to the ticket of the next release
>> so the contribution would remain in our sight.
> Please don't do that.  The way to clean the Inbox is to push through
> the work of reviewing, discussing and either accepting or rejecting.
> Simply moving items "out of sight" does not clean the "situation", in
> fact it actually makes the situation worse because now we have half of
> our unreviewed contributions in the Inbox and half in Mantis.  I just
> don't see myself going out to Mantis to review "expired"
> contributions.  It's like a black hole, digging something out of there
> requires manual effort, vs. simply selecting it right in the image and
> diffing it.

I guess the root of the problem is that Mantis is not being used by the 
community. During the developement of 4.2 we resolved ~90 Mantis issues.
I hope it will be more for 4.3, because there are 898 not resolved left.

> I'm just saying, contributors should be able to expect that their
> items in the Inbox will be handled based solely on the merits of the
> change, not based on time-limits or how many other items are in the
> Inbox.  Losing good contributions that people made, who expect the
> InBox process to work a certain way; THAT would be a good way to

That's right, but this didn't happen for months. My idea is not about the 
existing stuff in the Inbox, but future contributions. The time limit 
could motivate
- the core developers to review and integrate the contributions
- the contributors to open discussions about their code.


> discourage contributions.  To keep it clean, I think we just gotta do
> the work..
> Regards,
>  Chris

More information about the Squeak-dev mailing list