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" <lewis at mail.msen.com> 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" <lewis at mail.msen.com> 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
>>> 
>>> 
>> 
>