[squeak-dev] Inbox cleaning

Chris Muller asqueaker at gmail.com
Fri Apr 15 16:22:23 UTC 2011


>> To prevent contributions from rotting I can imagine two strategies:
>> - automatically reject outdated contributions to a StaledInbox
> Maybe after 2 months.

But how does this prevent contributions from rotting, instead of just
changing the place of *where* they rot?

So, in 2 months we come back and proclaim, "Wow, look how *clean* our
Inbox is!" and we feel warm and fuzzy inside.  It's like lying to
ourselves about the truth.

If something is "messy" and we don't like, I think we just gotta "Do
It".  I'm not opposed to having a "Pending" project, where items that
we don't yet want to accept or reject, but just want to get out of the
way for the newest items.

Heck, maybe a simple age-based filter on the Monticello repository is
all we need!  Show the the submissions of the last week.

Please help me if I'm missing something..  Dealing with new code is
something for humans to do, not the machine.  Having some automated
apparatus automatically moving code around to different repositories
sounds like nothing more than something additional to maintain, and
creating, guaranteed, additional places for me to check for things to
intgegrate.

> This would surely raise the attention on it. But as there is a delay
> between placing them into the inbox and the commit most of them might
> not fit anymore.
> And a discussion is necessary.

Maybe instead of automatically moving them, we should just have the
system automaticaly prod the squeak-dev list with an e-mail:

    Attention:  Collections-cmm.123 is now 60 days old.

Or whatever.

One last crazy idea:  What if, core-devs who don't process Inbox items
are relieved of their core-dev status; while those that contribute
Inbox items that get accepted are eventually promoted to core-dev
(which is how a prior core-dev would regain his status).

 - Chris



More information about the Squeak-dev mailing list