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.

2¢
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
> >>>
> >>>
> >>
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20110415/ce7db0a2/attachment.htm