Inbox cleaning

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

Inbox cleaning

Nicolas Cellier
I rejected System-djr.305.mcz to the TreatedInbox
(
Move (and delegate) Smalltalk>>hasSpecialSelector:ifTrueSetByte: and
friends to SystemDictionary.
The Refactoring Browser' tests expects it there and it makes more sense to me.
)

Rationale: specialSelectors & co are system attributes.
Thus it seems to me more natural to ask the System (Smalltalk) than to
ask a namespace (Smalltalk globals).

Sorry, we can't wait for an hypothetic democratic decision forever,
someone has to play the dictator :(

Nicolas

Reply | Threaded
Open this post in threaded view
|

Re: Inbox cleaning

Levente Uzonyi-2
On Mon, 11 Apr 2011, Nicolas Cellier wrote:

> I rejected System-djr.305.mcz to the TreatedInbox
> (
> Move (and delegate) Smalltalk>>hasSpecialSelector:ifTrueSetByte: and
> friends to SystemDictionary.
> The Refactoring Browser' tests expects it there and it makes more sense to me.
> )
>
> Rationale: specialSelectors & co are system attributes.
> Thus it seems to me more natural to ask the System (Smalltalk) than to
> ask a namespace (Smalltalk globals).
>
> Sorry, we can't wait for an hypothetic democratic decision forever,
> someone has to play the dictator :(

Another solution is to open an issue for each pending contribution
on mantis and discuss them there.

Pros:
- all previous thoughts/ideas are available at the same place, nothing
will be lost in the mail archive
- it will be known which packages are for which contribution
Cons:
- not all developers follow mantis issues

But if we decide to use an issue tracker - which would be great - then the
cons will be gone. So the question is: will mantis be accepted and used by
all developers or should we look for another issue tracker?

I know some people don't like mantis and I think I know why, but mantis is
good enough for our needs IMHO. Even though it seems to be complicated,
it's pretty easy to use it, if you're willing to spend a few minutes on
learning the basic features.


Levente

>
> Nicolas
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Inbox cleaning

Casey Ransberger-2
I disagree. The thing that gets my inbox contribution into Squeak isn't waiting on a Mantis ticket (this is the problem that the Inbox addresses.) What gets my commits into Squeak is *communicating* with other people on the list about why my stuff should go in.

If the problem is folks are checking in and the commits are being overlooked, I'd suggest that people ask someone to move the changes to trunk. Just about every time I've done this, it's worked. The sole exceptions were two cases where my commits were bad, and another where I commited to the inbox and forgot to follow up.

I don't believe installing Mantis in the center of the feedback loop is going to do anything beyond make it harder for non-core developers to contribute and slow down the overall community development process.

I could be wrong but I bet I'm not.

On Apr 11, 2011, at 4:00 PM, Levente Uzonyi <[hidden email]> wrote:

> On Mon, 11 Apr 2011, Nicolas Cellier wrote:
>
>> I rejected System-djr.305.mcz to the TreatedInbox
>> (
>> Move (and delegate) Smalltalk>>hasSpecialSelector:ifTrueSetByte: and
>> friends to SystemDictionary.
>> The Refactoring Browser' tests expects it there and it makes more sense to me.
>> )
>>
>> Rationale: specialSelectors & co are system attributes.
>> Thus it seems to me more natural to ask the System (Smalltalk) than to
>> ask a namespace (Smalltalk globals).
>>
>> Sorry, we can't wait for an hypothetic democratic decision forever,
>> someone has to play the dictator :(
>
> Another solution is to open an issue for each pending contribution on mantis and discuss them there.
>
> Pros:
> - all previous thoughts/ideas are available at the same place, nothing will be lost in the mail archive
> - it will be known which packages are for which contribution
> Cons:
> - not all developers follow mantis issues
>
> But if we decide to use an issue tracker - which would be great - then the cons will be gone. So the question is: will mantis be accepted and used by all developers or should we look for another issue tracker?
>
> I know some people don't like mantis and I think I know why, but mantis is good enough for our needs IMHO. Even though it seems to be complicated, it's pretty easy to use it, if you're willing to spend a few minutes on learning the basic features.
>
>
> Levente
>
>>
>> Nicolas
>>
>>
>

Reply | Threaded
Open this post in threaded view
|

Re: Inbox cleaning

Levente Uzonyi-2
On Mon, 11 Apr 2011, Casey Ransberger wrote:

> I disagree. The thing that gets my inbox contribution into Squeak isn't waiting on a Mantis ticket (this is the problem that the Inbox addresses.) What gets my commits into Squeak is *communicating* with other people on the list about why my stuff should go in.
>
> If the problem is folks are checking in and the commits are being overlooked, I'd suggest that people ask someone to move the changes to trunk. Just about every time I've done this, it's worked. The sole exceptions were two cases where my commits were bad, and another where I commited to the inbox and forgot to follow up.
>
> I don't believe installing Mantis in the center of the feedback loop is going to do anything beyond make it harder for non-core developers to contribute and slow down the overall community development process.
>
> I could be wrong but I bet I'm not.

I guess I didn't express my idea properly. It's not about new
contributions, but those which are lingering in the Inbox for months. As
time passes we're losing information about them. It takes a lot of time to
find the lost information out again. The code in the Trunk is also
evolving, so the contribution may become obsolete. AFAIK some
contributors left the community (even temporarily), so we won't be able to
ask them about the contribution.

For new contributions you're right, communication is the key if you want
your changes to go into the Trunk. It doesn't have to be mail (though it's
always welcome), well written commit message and tests are fine too. :)


Levente

>
> On Apr 11, 2011, at 4:00 PM, Levente Uzonyi <[hidden email]> wrote:
>
>> On Mon, 11 Apr 2011, Nicolas Cellier wrote:
>>
>>> I rejected System-djr.305.mcz to the TreatedInbox
>>> (
>>> Move (and delegate) Smalltalk>>hasSpecialSelector:ifTrueSetByte: and
>>> friends to SystemDictionary.
>>> The Refactoring Browser' tests expects it there and it makes more sense to me.
>>> )
>>>
>>> Rationale: specialSelectors & co are system attributes.
>>> Thus it seems to me more natural to ask the System (Smalltalk) than to
>>> ask a namespace (Smalltalk globals).
>>>
>>> Sorry, we can't wait for an hypothetic democratic decision forever,
>>> someone has to play the dictator :(
>>
>> Another solution is to open an issue for each pending contribution on mantis and discuss them there.
>>
>> Pros:
>> - all previous thoughts/ideas are available at the same place, nothing will be lost in the mail archive
>> - it will be known which packages are for which contribution
>> Cons:
>> - not all developers follow mantis issues
>>
>> But if we decide to use an issue tracker - which would be great - then the cons will be gone. So the question is: will mantis be accepted and used by all developers or should we look for another issue tracker?
>>
>> I know some people don't like mantis and I think I know why, but mantis is good enough for our needs IMHO. Even though it seems to be complicated, it's pretty easy to use it, if you're willing to spend a few minutes on learning the basic features.
>>
>>
>> Levente
>>
>>>
>>> Nicolas
>>>
>>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Inbox cleaning

Casey Ransberger-2
Oh, I get it. That makes perfect sense. I must have dropped a BlockContext somewhere! Sorry about the ranty-pants, everyone:) Carry on, nothing to see here:P



On Apr 11, 2011, at 6:12 PM, Levente Uzonyi <[hidden email]> wrote:

> On Mon, 11 Apr 2011, Casey Ransberger wrote:
>
>> I disagree. The thing that gets my inbox contribution into Squeak isn't waiting on a Mantis ticket (this is the problem that the Inbox addresses.) What gets my commits into Squeak is *communicating* with other people on the list about why my stuff should go in.
>>
>> If the problem is folks are checking in and the commits are being overlooked, I'd suggest that people ask someone to move the changes to trunk. Just about every time I've done this, it's worked. The sole exceptions were two cases where my commits were bad, and another where I commited to the inbox and forgot to follow up.
>>
>> I don't believe installing Mantis in the center of the feedback loop is going to do anything beyond make it harder for non-core developers to contribute and slow down the overall community development process.
>>
>> I could be wrong but I bet I'm not.
>
> I guess I didn't express my idea properly. It's not about new contributions, but those which are lingering in the Inbox for months. As time passes we're losing information about them. It takes a lot of time to find the lost information out again. The code in the Trunk is also evolving, so the contribution may become obsolete. AFAIK some contributors left the community (even temporarily), so we won't be able to ask them about the contribution.
>
> For new contributions you're right, communication is the key if you want your changes to go into the Trunk. It doesn't have to be mail (though it's always welcome), well written commit message and tests are fine too. :)
>
>
> Levente
>
>>
>> On Apr 11, 2011, at 4:00 PM, Levente Uzonyi <[hidden email]> wrote:
>>
>>> On Mon, 11 Apr 2011, Nicolas Cellier wrote:
>>>
>>>> I rejected System-djr.305.mcz to the TreatedInbox
>>>> (
>>>> Move (and delegate) Smalltalk>>hasSpecialSelector:ifTrueSetByte: and
>>>> friends to SystemDictionary.
>>>> The Refactoring Browser' tests expects it there and it makes more sense to me.
>>>> )
>>>>
>>>> Rationale: specialSelectors & co are system attributes.
>>>> Thus it seems to me more natural to ask the System (Smalltalk) than to
>>>> ask a namespace (Smalltalk globals).
>>>>
>>>> Sorry, we can't wait for an hypothetic democratic decision forever,
>>>> someone has to play the dictator :(
>>>
>>> Another solution is to open an issue for each pending contribution on mantis and discuss them there.
>>>
>>> Pros:
>>> - all previous thoughts/ideas are available at the same place, nothing will be lost in the mail archive
>>> - it will be known which packages are for which contribution
>>> Cons:
>>> - not all developers follow mantis issues
>>>
>>> But if we decide to use an issue tracker - which would be great - then the cons will be gone. So the question is: will mantis be accepted and used by all developers or should we look for another issue tracker?
>>>
>>> I know some people don't like mantis and I think I know why, but mantis is good enough for our needs IMHO. Even though it seems to be complicated, it's pretty easy to use it, if you're willing to spend a few minutes on learning the basic features.
>>>
>>>
>>> Levente
>>>
>>>>
>>>> Nicolas
>>>>
>>>>
>>>
>>
>>
>


Reply | Threaded
Open this post in threaded view
|

Re: Inbox cleaning

Chris Muller-3
In reply to this post by Levente Uzonyi-2
My only question is:  how does Mantis keep things from getting lost?

I use gmail, which serves as the primary interface to communicating
with all Squeak lists and a Google-backed search capability.  I can
just search for the version-name and instantly have a list of "all the
information" available about that version?

Now I would have to have an additional place to check for information?

I appreciate trying to keep our inbox clean, but the treated Inbox is
meant to "keep things around".  So if we simply reply to the original
submission with something like,

    "No activity on this for 6 months, moving to Treated."

Then that goes into the mail archive, which is searchable, and no need
to bring in another tool..??

Regards,
  Chris


On Mon, Apr 11, 2011 at 8:12 PM, Levente Uzonyi <[hidden email]> wrote:

> On Mon, 11 Apr 2011, Casey Ransberger wrote:
>
>> I disagree. The thing that gets my inbox contribution into Squeak isn't
>> waiting on a Mantis ticket (this is the problem that the Inbox addresses.)
>> What gets my commits into Squeak is *communicating* with other people on the
>> list about why my stuff should go in.
>>
>> If the problem is folks are checking in and the commits are being
>> overlooked, I'd suggest that people ask someone to move the changes to
>> trunk. Just about every time I've done this, it's worked. The sole
>> exceptions were two cases where my commits were bad, and another where I
>> commited to the inbox and forgot to follow up.
>>
>> I don't believe installing Mantis in the center of the feedback loop is
>> going to do anything beyond make it harder for non-core developers to
>> contribute and slow down the overall community development process.
>>
>> I could be wrong but I bet I'm not.
>
> I guess I didn't express my idea properly. It's not about new contributions,
> but those which are lingering in the Inbox for months. As time passes we're
> losing information about them. It takes a lot of time to find the lost
> information out again. The code in the Trunk is also evolving, so the
> contribution may become obsolete. AFAIK some contributors left the community
> (even temporarily), so we won't be able to ask them about the contribution.
>
> For new contributions you're right, communication is the key if you want
> your changes to go into the Trunk. It doesn't have to be mail (though it's
> always welcome), well written commit message and tests are fine too. :)
>
>
> Levente
>
>>
>> On Apr 11, 2011, at 4:00 PM, Levente Uzonyi <[hidden email]> wrote:
>>
>>> On Mon, 11 Apr 2011, Nicolas Cellier wrote:
>>>
>>>> I rejected System-djr.305.mcz to the TreatedInbox
>>>> (
>>>> Move (and delegate) Smalltalk>>hasSpecialSelector:ifTrueSetByte: and
>>>> friends to SystemDictionary.
>>>> The Refactoring Browser' tests expects it there and it makes more sense
>>>> to me.
>>>> )
>>>>
>>>> Rationale: specialSelectors & co are system attributes.
>>>> Thus it seems to me more natural to ask the System (Smalltalk) than to
>>>> ask a namespace (Smalltalk globals).
>>>>
>>>> Sorry, we can't wait for an hypothetic democratic decision forever,
>>>> someone has to play the dictator :(
>>>
>>> Another solution is to open an issue for each pending contribution on
>>> mantis and discuss them there.
>>>
>>> Pros:
>>> - all previous thoughts/ideas are available at the same place, nothing
>>> will be lost in the mail archive
>>> - it will be known which packages are for which contribution
>>> Cons:
>>> - not all developers follow mantis issues
>>>
>>> But if we decide to use an issue tracker - which would be great - then
>>> the cons will be gone. So the question is: will mantis be accepted and used
>>> by all developers or should we look for another issue tracker?
>>>
>>> I know some people don't like mantis and I think I know why, but mantis
>>> is good enough for our needs IMHO. Even though it seems to be complicated,
>>> it's pretty easy to use it, if you're willing to spend a few minutes on
>>> learning the basic features.
>>>
>>>
>>> Levente
>>>
>>>>
>>>> Nicolas
>>>>
>>>>
>>>
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Inbox cleaning

Colin Putney-3
On Wed, Apr 13, 2011 at 8:23 AM, Chris Muller <[hidden email]> wrote:

> My only question is:  how does Mantis keep things from getting lost?
>
> I use gmail, which serves as the primary interface to communicating
> with all Squeak lists and a Google-backed search capability.  I can
> just search for the version-name and instantly have a list of "all the
> information" available about that version?
>
> Now I would have to have an additional place to check for information?
>
> I appreciate trying to keep our inbox clean, but the treated Inbox is
> meant to "keep things around".  So if we simply reply to the original
> submission with something like,
>
>    "No activity on this for 6 months, moving to Treated."
>
> Then that goes into the mail archive, which is searchable, and no need
> to bring in another tool..??

There are several issues here:

One, not everybody uses Gmail. Some people can't use Gmail and others
have good reasons for choosing not to. Let's not create a system that
excludes them.

Two, text search isn't very reliable as a way to find "all the
information." Yes, gmail has pretty good search capabilities. I use it
exactly the same way you do. But some issues don't have a set of
keywords that identify them precisely, and the effectiveness of
specific search terms changes over time. I used to be able to do a
search for "Cog" to get a good summary of Eliot's high level design
ideas and theoretical musings about VM design. But now that people are
actively using it, the term comes up all over the place and the signal
is drowned in the noise.

Three, even if we decide that mail search is fine for gathering "all
information" about a particular issue, that's not the only kind of
query we need to do. How would you answer the following questions with
Gmail?

Reply | Threaded
Open this post in threaded view
|

Re: Inbox cleaning

Colin Putney-3
Ugh, slip of the finger sent that out before it was ready.

On Wed, Apr 13, 2011 at 9:02 AM, Colin Putney <[hidden email]> wrote:

> On Wed, Apr 13, 2011 at 8:23 AM, Chris Muller <[hidden email]> wrote:
>> My only question is:  how does Mantis keep things from getting lost?
>>
>> I use gmail, which serves as the primary interface to communicating
>> with all Squeak lists and a Google-backed search capability.  I can
>> just search for the version-name and instantly have a list of "all the
>> information" available about that version?
>>
>> Now I would have to have an additional place to check for information?
>>
>> I appreciate trying to keep our inbox clean, but the treated Inbox is
>> meant to "keep things around".  So if we simply reply to the original
>> submission with something like,
>>
>>    "No activity on this for 6 months, moving to Treated."
>>
>> Then that goes into the mail archive, which is searchable, and no need
>> to bring in another tool..??
>
> There are several issues here:
>
> One, not everybody uses Gmail. Some people can't use Gmail and others
> have good reasons for choosing not to. Let's not create a system that
> excludes them.
>
> Two, text search isn't very reliable as a way to find "all the
> information." Yes, gmail has pretty good search capabilities. I use it
> exactly the same way you do. But some issues don't have a set of
> keywords that identify them precisely, and the effectiveness of
> specific search terms changes over time. I used to be able to do a
> search for "Cog" to get a good summary of Eliot's high level design
> ideas and theoretical musings about VM design. But now that people are
> actively using it, the term comes up all over the place and the signal
> is drowned in the noise.
>
> Three, even if we decide that mail search is fine for gathering "all
> information" about a particular issue, that's not the only kind of
> query we need to do. How would you answer the following questions with
> Gmail?
>

- How many submissions to the inbox were integrated into Squeak 4.2?
- What issues are still pending for Squeak 4.3?
- What submissions have been moved to treated for lack of interest?

This is the kind of thing that Mantis is good at. I'm cleaning up the
the OmniBrowser issues on Mantis precisely so I can put together a new
release that resolves all outstanding issues and works well on Squeak
trunk. Relying on email for that is just not feasible. For Squeak as a
whole it would be even less feasible, given the greater size, scope
and number of people involved.

Colin

Reply | Threaded
Open this post in threaded view
|

Re: Inbox cleaning

Nicolas Cellier
Of course, database like queries are a bonus of issue trackers...
Andreas' lightwight model (trunk) was to enable direct commit without
issue/enhancement tracing.
It was a rather pragmatic approach to reduce harvesting bottleneck and
given the fact mantis was not that successfull.
It works quite well except for these contributions not getting in trunk.

What i don't like:
- a single TreatedInbox for both accepted/rejected contributions
- no dedicated place to discuss contributions, provide rationale,
gather scattered mailing list discussions (think about half year
timespan).

To prevent contributions from rotting I can imagine two strategies:
- automatically reject outdated contributions to a StaledInbox
- automatically accept outdated contributions to trunk
a bit like some administration having a maximum delay to answer your queries :)

Nicolas

2011/4/13 Colin Putney <[hidden email]>:

> Ugh, slip of the finger sent that out before it was ready.
>
> On Wed, Apr 13, 2011 at 9:02 AM, Colin Putney <[hidden email]> wrote:
>> On Wed, Apr 13, 2011 at 8:23 AM, Chris Muller <[hidden email]> wrote:
>>> My only question is:  how does Mantis keep things from getting lost?
>>>
>>> I use gmail, which serves as the primary interface to communicating
>>> with all Squeak lists and a Google-backed search capability.  I can
>>> just search for the version-name and instantly have a list of "all the
>>> information" available about that version?
>>>
>>> Now I would have to have an additional place to check for information?
>>>
>>> I appreciate trying to keep our inbox clean, but the treated Inbox is
>>> meant to "keep things around".  So if we simply reply to the original
>>> submission with something like,
>>>
>>>    "No activity on this for 6 months, moving to Treated."
>>>
>>> Then that goes into the mail archive, which is searchable, and no need
>>> to bring in another tool..??
>>
>> There are several issues here:
>>
>> One, not everybody uses Gmail. Some people can't use Gmail and others
>> have good reasons for choosing not to. Let's not create a system that
>> excludes them.
>>
>> Two, text search isn't very reliable as a way to find "all the
>> information." Yes, gmail has pretty good search capabilities. I use it
>> exactly the same way you do. But some issues don't have a set of
>> keywords that identify them precisely, and the effectiveness of
>> specific search terms changes over time. I used to be able to do a
>> search for "Cog" to get a good summary of Eliot's high level design
>> ideas and theoretical musings about VM design. But now that people are
>> actively using it, the term comes up all over the place and the signal
>> is drowned in the noise.
>>
>> Three, even if we decide that mail search is fine for gathering "all
>> information" about a particular issue, that's not the only kind of
>> query we need to do. How would you answer the following questions with
>> Gmail?
>>
>
> - How many submissions to the inbox were integrated into Squeak 4.2?
> - What issues are still pending for Squeak 4.3?
> - What submissions have been moved to treated for lack of interest?
>
> This is the kind of thing that Mantis is good at. I'm cleaning up the
> the OmniBrowser issues on Mantis precisely so I can put together a new
> release that resolves all outstanding issues and works well on Squeak
> trunk. Relying on email for that is just not feasible. For Squeak as a
> whole it would be even less feasible, given the greater size, scope
> and number of people involved.
>
> Colin
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Inbox cleaning

Colin Putney-3
On Wed, Apr 13, 2011 at 5:19 PM, Nicolas Cellier
<[hidden email]> wrote:
> Of course, database like queries are a bonus of issue trackers...
> Andreas' lightwight model (trunk) was to enable direct commit without
> issue/enhancement tracing.
> It was a rather pragmatic approach to reduce harvesting bottleneck and
> given the fact mantis was not that successfull.
> It works quite well except for these contributions not getting in trunk.

True. I guess the real problem is that we core developers need to
spend the time and energy required to deal with the things that get
put in the Inbox. Andreas was doing a lot of that work, but he
couldn't keep up that level of effort indefinitely. Now it falls the
rest of us to step into the breach.

Colin

Reply | Threaded
Open this post in threaded view
|

Re: Inbox cleaning

Frank Shearar
On 2011/04/14 03:04, Colin Putney wrote:

> On Wed, Apr 13, 2011 at 5:19 PM, Nicolas Cellier
> <[hidden email]>  wrote:
>> Of course, database like queries are a bonus of issue trackers...
>> Andreas' lightwight model (trunk) was to enable direct commit without
>> issue/enhancement tracing.
>> It was a rather pragmatic approach to reduce harvesting bottleneck and
>> given the fact mantis was not that successfull.
>> It works quite well except for these contributions not getting in trunk.
>
> True. I guess the real problem is that we core developers need to
> spend the time and energy required to deal with the things that get
> put in the Inbox. Andreas was doing a lot of that work, but he
> couldn't keep up that level of effort indefinitely. Now it falls the
> rest of us to step into the breach.

Where "us" is "the committers AND EVERYONE ELSE" - just because you
don't have commit privileges doesn't mean you can't review the code, try
it out, bang on it, etc. Yea verily, that's why we have the commits
publishing to squeak-dev in the first place!

frank

Reply | Threaded
Open this post in threaded view
|

Re: Inbox cleaning

Hannes Hirzel
In reply to this post by Nicolas Cellier
On 4/14/11, Nicolas Cellier <[hidden email]> wrote:
> To prevent contributions from rotting I can imagine two strategies:
> - automatically reject outdated contributions to a StaledInbox
Maybe after 2 months.

And then they stay for another 8 months in the StaledInbox and are
deleted afterwards.

> - automatically accept outdated contributions to trunk
> a bit like some administration having a maximum delay to answer your queries
> :)

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.

--Hannes

Reply | Threaded
Open this post in threaded view
|

Re: Inbox cleaning

Chris Muller-3
>> 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

Reply | Threaded
Open this post in threaded view
|

Re: Inbox cleaning

Casey Ransberger-2


On Apr 15, 2011, at 9:22 AM, Chris Muller <[hidden email]> wrote:

> 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.

+1

> 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).

Uh, how do you deal with my ill advised checkin to the inbox? If you can get out if jail free by moving it to the treated inbox, well, maybe. But I don't know if I want to force an extra responsibility on our volunteers.

Frankly I'm not real sure what the problem is. Every time I've posted to the inbox and asked someone to merge in my bits, they've either gone in, or I was doing something that people didn't want.

Is this discussion limited to the cases where folks aren't sure it should go in, etc., and then the inbox diverges from the trunk?

I think rather than automatically giving all of the core devs an extra responsiblilty, perhaps the board can appoint a community member to watch the inbox and make sure the necessary communication occurs on the list?

I seriously don't think it's that much harder than "Hey, Chris:) Would you merge this in when you have a chance?"

> - Chris
>

Reply | Threaded
Open this post in threaded view
|

Inbox and Communication

Casey Ransberger-2
In reply to this post by Chris Muller-3
The more I think about it, the less I want Levente blocked on integrating the menu item I added and committed to the inbox while he's trying to checkin 14 commits that make our streams twice as fast.

I think the root problem is probably communication, and I think it might be partly that newcomers sometimes start off a little shy. I remember when I first arrived, I knew I didn't know what I was doing, and asking to get my bits merged felt a little awkward.

I also think that the healthiest solution will involve non-core devs taking ownership of the inbox in a lot of ways.

Rather than make a single person a choke point, or force all of the core devs to do more work or lose their commit bit, maybe I can convince a core dev or two to volunteer to be goto people for merging inbox changes?

What do the core developers think about this?

I must say, I do like Chris' nag-mail idea.

On Apr 15, 2011, at 9:22 AM, Chris Muller <[hidden email]> wrote:

>>> 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
>

Reply | Threaded
Open this post in threaded view
|

Re: Inbox and Communication

David T. Lewis
On Fri, Apr 15, 2011 at 10:19:49AM -0700, Casey Ransberger wrote:

> The more I think about it, the less I want Levente blocked on integrating the menu item I added and committed to the inbox while he's trying to checkin 14 commits that make our streams twice as fast.
>
> I think the root problem is probably communication, and I think it might be partly that newcomers sometimes start off a little shy. I remember when I first arrived, I knew I didn't know what I was doing, and asking to get my bits merged felt a little awkward.
>
> I also think that the healthiest solution will involve non-core devs taking ownership of the inbox in a lot of ways.
>
> Rather than make a single person a choke point, or force all of the core devs to do more work or lose their commit bit, maybe I can convince a core dev or two to volunteer to be goto people for merging inbox changes?
>
> What do the core developers think about this?
>
> I must say, I do like Chris' nag-mail idea.

I think you should turn the question around backwards. Instead of
"what can we do to to make people work on the inbox?" ask "what can
we do to the inbox process to make people want to work on it?".

For me, working on something in the inbox should be an enjoyable
thing to do for an hour or so in the morning with a nice cup of
fresh coffee. Right now it's kind of a pain to figure out what's
going in the the inbox, so I tend to find something else to do
while I'm sipping that cup of coffee.

$0.02

Dave


Reply | Threaded
Open this post in threaded view
|

Re: Inbox and Communication

Casey Ransberger-2
David: I know how to tell you that I want something merged, but I don't know how to make it smooth or fun.

You said it's a pain right now. Would you develop that? I want to know what I can do to make the Inbox process suck less for you (as a core committer.)

This is actually pretty important for me, because it's a great way for me to get wonderful feedback about the code I'm writing. "What's this method you're trying to add? You know there's already a method for that called #foo, right?" Etcetera.

It's such a great opportunity to learn that I've never wanted strongly to ask for Trunk access, even after I hit the point where I felt pretty comfortable with Smalltalk. I figure I'll ask when I actually need it, like if I wanted to bring over my themes engine from Cuis, in which case there'd be enough code that merging it in would be a pain for someone else.

That said, I really value the feedback I get from the core dev team, so I want to make doing so as painless as possible for them.

I note that there is very little process around the Inbox covered in Andreas' original development process document. We should amend the doc when we figure out what works. I don't mind doing that, and I would bet that Mr. Hirzel or Mr. Haupt could be convinced to step in if I am unexpectedly run over by a bus.

On Apr 15, 2011, at 12:42 PM, "David T. Lewis" <[hidden email]> wrote:

> On Fri, Apr 15, 2011 at 10:19:49AM -0700, Casey Ransberger wrote:
>> The more I think about it, the less I want Levente blocked on integrating the menu item I added and committed to the inbox while he's trying to checkin 14 commits that make our streams twice as fast.
>>
>> I think the root problem is probably communication, and I think it might be partly that newcomers sometimes start off a little shy. I remember when I first arrived, I knew I didn't know what I was doing, and asking to get my bits merged felt a little awkward.
>>
>> I also think that the healthiest solution will involve non-core devs taking ownership of the inbox in a lot of ways.
>>
>> Rather than make a single person a choke point, or force all of the core devs to do more work or lose their commit bit, maybe I can convince a core dev or two to volunteer to be goto people for merging inbox changes?
>>
>> What do the core developers think about this?
>>
>> I must say, I do like Chris' nag-mail idea.
>
> I think you should turn the question around backwards. Instead of
> "what can we do to to make people work on the inbox?" ask "what can
> we do to the inbox process to make people want to work on it?".
>
> For me, working on something in the inbox should be an enjoyable
> thing to do for an hour or so in the morning with a nice cup of
> fresh coffee. Right now it's kind of a pain to figure out what's
> going in the the inbox, so I tend to find something else to do
> while I'm sipping that cup of coffee.
>
> $0.02
>
> Dave
>
>


Reply | Threaded
Open this post in threaded view
|

Re: Inbox and Communication

David T. Lewis
Thanks Casey,

I'm not sure how to make this better (and my point was really only
to focus more on how to make it better versus how to nag people etc).

That said, I think that the problem I experience is that I have a
hard time looking at something in the inbox, figuring out how out
of date it might be, and figuring out exactly what changes it was
originally attempting to make. In many cases, the submission might
involve just a few methods, but it takes me a long time to figure
that out by browsing the MCZ and cross-checking against emails.

I find the Montecello process to be wonderful for development and
for maintaining the update stream, but when I look at something
that someone else submitted a few weeks ago, I find myself wishing
that I could just look at the change set.

So maybe I am just looking for a button that says "show me the
change set" where the change set would be the changes that the
original author was submitting two weeks ago.

I have an uneasy feeling that there is some existing way to do
this and I'm too dumb to have noticed it yet, so I'm preparing
myself for an embarassing reply from Bert within the next few
minutes ;)

Thanks for the work you are doing on the inbox!

Dave


On Fri, Apr 15, 2011 at 01:45:24PM -0700, Casey Ransberger wrote:

> David: I know how to tell you that I want something merged, but I don't know how to make it smooth or fun.
>
> You said it's a pain right now. Would you develop that? I want to know what I can do to make the Inbox process suck less for you (as a core committer.)
>
> This is actually pretty important for me, because it's a great way for me to get wonderful feedback about the code I'm writing. "What's this method you're trying to add? You know there's already a method for that called #foo, right?" Etcetera.
>
> It's such a great opportunity to learn that I've never wanted strongly to ask for Trunk access, even after I hit the point where I felt pretty comfortable with Smalltalk. I figure I'll ask when I actually need it, like if I wanted to bring over my themes engine from Cuis, in which case there'd be enough code that merging it in would be a pain for someone else.
>
> That said, I really value the feedback I get from the core dev team, so I want to make doing so as painless as possible for them.
>
> I note that there is very little process around the Inbox covered in Andreas' original development process document. We should amend the doc when we figure out what works. I don't mind doing that, and I would bet that Mr. Hirzel or Mr. Haupt could be convinced to step in if I am unexpectedly run over by a bus.
>
> On Apr 15, 2011, at 12:42 PM, "David T. Lewis" <[hidden email]> wrote:
>
> > On Fri, Apr 15, 2011 at 10:19:49AM -0700, Casey Ransberger wrote:
> >> The more I think about it, the less I want Levente blocked on integrating the menu item I added and committed to the inbox while he's trying to checkin 14 commits that make our streams twice as fast.
> >>
> >> I think the root problem is probably communication, and I think it might be partly that newcomers sometimes start off a little shy. I remember when I first arrived, I knew I didn't know what I was doing, and asking to get my bits merged felt a little awkward.
> >>
> >> I also think that the healthiest solution will involve non-core devs taking ownership of the inbox in a lot of ways.
> >>
> >> Rather than make a single person a choke point, or force all of the core devs to do more work or lose their commit bit, maybe I can convince a core dev or two to volunteer to be goto people for merging inbox changes?
> >>
> >> What do the core developers think about this?
> >>
> >> I must say, I do like Chris' nag-mail idea.
> >
> > I think you should turn the question around backwards. Instead of
> > "what can we do to to make people work on the inbox?" ask "what can
> > we do to the inbox process to make people want to work on it?".
> >
> > For me, working on something in the inbox should be an enjoyable
> > thing to do for an hour or so in the morning with a nice cup of
> > fresh coffee. Right now it's kind of a pain to figure out what's
> > going in the the inbox, so I tend to find something else to do
> > while I'm sipping that cup of coffee.
> >
> > $0.02
> >
> > Dave
> >
> >
>

Reply | Threaded
Open this post in threaded view
|

Re: Inbox and Communication

Levente Uzonyi-2
On Fri, 15 Apr 2011, David T. Lewis wrote:

> Thanks Casey,
>
> I'm not sure how to make this better (and my point was really only
> to focus more on how to make it better versus how to nag people etc).
>
> That said, I think that the problem I experience is that I have a
> hard time looking at something in the inbox, figuring out how out
> of date it might be, and figuring out exactly what changes it was
> originally attempting to make. In many cases, the submission might
> involve just a few methods, but it takes me a long time to figure
> that out by browsing the MCZ and cross-checking against emails.
>
> I find the Montecello process to be wonderful for development and
> for maintaining the update stream, but when I look at something
> that someone else submitted a few weeks ago, I find myself wishing
> that I could just look at the change set.
>
> So maybe I am just looking for a button that says "show me the
> change set" where the change set would be the changes that the
> original author was submitting two weeks ago.

For a single package, use MC's merge button. It will show all changes
and even highlight conflicts with newer changes in the Trunk.

For multiple packages, we have no solution yet. What you can do is to
merge all packages into your image and then create a changeset from the
changesets created by MC, using the Dual Change Sorter.

>
> I have an uneasy feeling that there is some existing way to do
> this and I'm too dumb to have noticed it yet, so I'm preparing
> myself for an embarassing reply from Bert within the next few
> minutes ;)

Bert modified our Squeaksource to create diffs (like those which are sent
to this list) and changesets, but changesets only work for packages
already in the Trunk for some reason.


Levente

>
> Thanks for the work you are doing on the inbox!
>
> Dave
>
>
> On Fri, Apr 15, 2011 at 01:45:24PM -0700, Casey Ransberger wrote:
>> David: I know how to tell you that I want something merged, but I don't know how to make it smooth or fun.
>>
>> You said it's a pain right now. Would you develop that? I want to know what I can do to make the Inbox process suck less for you (as a core committer.)
>>
>> This is actually pretty important for me, because it's a great way for me to get wonderful feedback about the code I'm writing. "What's this method you're trying to add? You know there's already a method for that called #foo, right?" Etcetera.
>>
>> It's such a great opportunity to learn that I've never wanted strongly to ask for Trunk access, even after I hit the point where I felt pretty comfortable with Smalltalk. I figure I'll ask when I actually need it, like if I wanted to bring over my themes engine from Cuis, in which case there'd be enough code that merging it in would be a pain for someone else.
>>
>> That said, I really value the feedback I get from the core dev team, so I want to make doing so as painless as possible for them.
>>
>> I note that there is very little process around the Inbox covered in Andreas' original development process document. We should amend the doc when we figure out what works. I don't mind doing that, and I would bet that Mr. Hirzel or Mr. Haupt could be convinced to step in if I am unexpectedly run over by a bus.
>>
>> On Apr 15, 2011, at 12:42 PM, "David T. Lewis" <[hidden email]> wrote:
>>
>>> On Fri, Apr 15, 2011 at 10:19:49AM -0700, Casey Ransberger wrote:
>>>> The more I think about it, the less I want Levente blocked on integrating the menu item I added and committed to the inbox while he's trying to checkin 14 commits that make our streams twice as fast.
>>>>
>>>> I think the root problem is probably communication, and I think it might be partly that newcomers sometimes start off a little shy. I remember when I first arrived, I knew I didn't know what I was doing, and asking to get my bits merged felt a little awkward.
>>>>
>>>> I also think that the healthiest solution will involve non-core devs taking ownership of the inbox in a lot of ways.
>>>>
>>>> Rather than make a single person a choke point, or force all of the core devs to do more work or lose their commit bit, maybe I can convince a core dev or two to volunteer to be goto people for merging inbox changes?
>>>>
>>>> What do the core developers think about this?
>>>>
>>>> I must say, I do like Chris' nag-mail idea.
>>>
>>> I think you should turn the question around backwards. Instead of
>>> "what can we do to to make people work on the inbox?" ask "what can
>>> we do to the inbox process to make people want to work on it?".
>>>
>>> For me, working on something in the inbox should be an enjoyable
>>> thing to do for an hour or so in the morning with a nice cup of
>>> fresh coffee. Right now it's kind of a pain to figure out what's
>>> going in the the inbox, so I tend to find something else to do
>>> while I'm sipping that cup of coffee.
>>>
>>> $0.02
>>>
>>> Dave
>>>
>>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: Inbox and Communication

Casey Ransberger-2
In reply to this post by David T. Lewis
I think most existing SCM solutions make this less painful with magic branching/merging/digging goodness. MC doesn't support branches, so we use a separate repository, which I think kind of sucks. I doubt we can fix that easily, though.

On Apr 15, 2011, at 2:12 PM, "David T. Lewis" <[hidden email]> wrote:

> Thanks Casey,
>
> I'm not sure how to make this better (and my point was really only
> to focus more on how to make it better versus how to nag people etc).
>
> That said, I think that the problem I experience is that I have a
> hard time looking at something in the inbox, figuring out how out
> of date it might be, and figuring out exactly what changes it was
> originally attempting to make. In many cases, the submission might
> involve just a few methods, but it takes me a long time to figure
> that out by browsing the MCZ and cross-checking against emails.
>
> I find the Montecello process to be wonderful for development and
> for maintaining the update stream, but when I look at something
> that someone else submitted a few weeks ago, I find myself wishing
> that I could just look at the change set.
>
> So maybe I am just looking for a button that says "show me the
> change set" where the change set would be the changes that the
> original author was submitting two weeks ago.
>
> I have an uneasy feeling that there is some existing way to do
> this and I'm too dumb to have noticed it yet, so I'm preparing
> myself for an embarassing reply from Bert within the next few
> minutes ;)
>
> Thanks for the work you are doing on the inbox!
>
> Dave
>
>
> On Fri, Apr 15, 2011 at 01:45:24PM -0700, Casey Ransberger wrote:
>> David: I know how to tell you that I want something merged, but I don't know how to make it smooth or fun.
>>
>> You said it's a pain right now. Would you develop that? I want to know what I can do to make the Inbox process suck less for you (as a core committer.)
>>
>> This is actually pretty important for me, because it's a great way for me to get wonderful feedback about the code I'm writing. "What's this method you're trying to add? You know there's already a method for that called #foo, right?" Etcetera.
>>
>> It's such a great opportunity to learn that I've never wanted strongly to ask for Trunk access, even after I hit the point where I felt pretty comfortable with Smalltalk. I figure I'll ask when I actually need it, like if I wanted to bring over my themes engine from Cuis, in which case there'd be enough code that merging it in would be a pain for someone else.
>>
>> That said, I really value the feedback I get from the core dev team, so I want to make doing so as painless as possible for them.
>>
>> I note that there is very little process around the Inbox covered in Andreas' original development process document. We should amend the doc when we figure out what works. I don't mind doing that, and I would bet that Mr. Hirzel or Mr. Haupt could be convinced to step in if I am unexpectedly run over by a bus.
>>
>> On Apr 15, 2011, at 12:42 PM, "David T. Lewis" <[hidden email]> wrote:
>>
>>> On Fri, Apr 15, 2011 at 10:19:49AM -0700, Casey Ransberger wrote:
>>>> The more I think about it, the less I want Levente blocked on integrating the menu item I added and committed to the inbox while he's trying to checkin 14 commits that make our streams twice as fast.
>>>>
>>>> I think the root problem is probably communication, and I think it might be partly that newcomers sometimes start off a little shy. I remember when I first arrived, I knew I didn't know what I was doing, and asking to get my bits merged felt a little awkward.
>>>>
>>>> I also think that the healthiest solution will involve non-core devs taking ownership of the inbox in a lot of ways.
>>>>
>>>> Rather than make a single person a choke point, or force all of the core devs to do more work or lose their commit bit, maybe I can convince a core dev or two to volunteer to be goto people for merging inbox changes?
>>>>
>>>> What do the core developers think about this?
>>>>
>>>> I must say, I do like Chris' nag-mail idea.
>>>
>>> I think you should turn the question around backwards. Instead of
>>> "what can we do to to make people work on the inbox?" ask "what can
>>> we do to the inbox process to make people want to work on it?".
>>>
>>> For me, working on something in the inbox should be an enjoyable
>>> thing to do for an hour or so in the morning with a nice cup of
>>> fresh coffee. Right now it's kind of a pain to figure out what's
>>> going in the the inbox, so I tend to find something else to do
>>> while I'm sipping that cup of coffee.
>>>
>>> $0.02
>>>
>>> Dave
>>>
>>>
>>
>

123