Inbox cleaning

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

On Fri, Apr 15, 2011 at 3:09 PM, Casey Ransberger <[hidden email]> wrote:

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.

Well, with VMMaker we're using an arguably dubious convention that supports branching Cog from the Interpreter in the same repository just fine.  So I'm not sure I agree.

2¢

Eliot

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

You mean the MC package, not the SVN sources right?

What's the convention?

On Fri, Apr 15, 2011 at 9:21 PM, Eliot Miranda <[hidden email]> wrote:

On Fri, Apr 15, 2011 at 3:09 PM, Casey Ransberger <[hidden email]> wrote:

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.

Well, with VMMaker we're using an arguably dubious convention that supports branching Cog from the Interpreter in the same repository just fine.  So I'm not sure I agree.

2¢

Eliot

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

--
Casey Ransberger

On Fri, Apr 15, 2011 at 10:57 PM, Eliot Miranda <[hidden email]> wrote:

> Use some false initials that name the branch, and start its version numbers
> from e.g. 1.  So I name my open-source Cog versions VMMaker-oscog.N.  The
> package still has my initials as author.  David is using
> VMMaker-oscog.dtl.N, etc.

Actually, MC does have some support for branching. If you use the
following convention, MC will do the "right" thing - group the
branched versions together in the UI, automatically suggest a version
name that's on a branch, and still allow you to merge between
branches. The naming convention is:

<package>.<branch>-<initials>.<id>

So if Eliot were using the standard convention, his versions would be
named like this:

VMMaker.oscog-eem.147

Colin