[squeak-dev] Inbox and Communication

Eliot Miranda eliot.miranda at gmail.com
Sat Apr 16 05:57:44 UTC 2011


On Fri, Apr 15, 2011 at 10:49 PM, Casey Ransberger <casey.obrien.r at gmail.com
> wrote:

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


Right.


> What's the convention?


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.


>
>
> On Fri, Apr 15, 2011 at 9:21 PM, Eliot Miranda <eliot.miranda at gmail.com>wrote:
>
>>
>>
>> On Fri, Apr 15, 2011 at 3:09 PM, Casey Ransberger <
>> casey.obrien.r at gmail.com> 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.
>>
>>>> Eliot
>>
>>
>>> 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
>>> >>>
>>> >>>
>>> >>
>>> >
>>>
>>>
>>
>>
>>
>>
>
>
> --
> Casey Ransberger
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20110415/0a0996a9/attachment.htm


More information about the Squeak-dev mailing list