<br><br><div class="gmail_quote">On Fri, Apr 15, 2011 at 10:49 PM, Casey Ransberger <span dir="ltr"><<a href="mailto:casey.obrien.r@gmail.com">casey.obrien.r@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
You mean the MC package, not the SVN sources right? </blockquote><div><br></div><div>Right.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">What's the convention?</blockquote>
<div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div><div></div><div class="h5"><br><br><div class="gmail_quote">On Fri, Apr 15, 2011 at 9:21 PM, Eliot Miranda <span dir="ltr"><<a href="mailto:eliot.miranda@gmail.com" target="_blank">eliot.miranda@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><br><div class="gmail_quote"><div>On Fri, Apr 15, 2011 at 3:09 PM, Casey Ransberger <span dir="ltr"><<a href="mailto:casey.obrien.r@gmail.com" target="_blank">casey.obrien.r@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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.<br>
</blockquote><div><br></div></div><div>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.</div>
<div>
<br></div><div>2˘</div><div>Eliot</div><div><div></div><div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div></div><div><br>
On Apr 15, 2011, at 2:12 PM, "David T. Lewis" <<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>> wrote:<br>
<br>
> Thanks Casey,<br>
><br>
> I'm not sure how to make this better (and my point was really only<br>
> to focus more on how to make it better versus how to nag people etc).<br>
><br>
> That said, I think that the problem I experience is that I have a<br>
> hard time looking at something in the inbox, figuring out how out<br>
> of date it might be, and figuring out exactly what changes it was<br>
> originally attempting to make. In many cases, the submission might<br>
> involve just a few methods, but it takes me a long time to figure<br>
> that out by browsing the MCZ and cross-checking against emails.<br>
><br>
> I find the Montecello process to be wonderful for development and<br>
> for maintaining the update stream, but when I look at something<br>
> that someone else submitted a few weeks ago, I find myself wishing<br>
> that I could just look at the change set.<br>
><br>
> So maybe I am just looking for a button that says "show me the<br>
> change set" where the change set would be the changes that the<br>
> original author was submitting two weeks ago.<br>
><br>
> I have an uneasy feeling that there is some existing way to do<br>
> this and I'm too dumb to have noticed it yet, so I'm preparing<br>
> myself for an embarassing reply from Bert within the next few<br>
> minutes ;)<br>
><br>
> Thanks for the work you are doing on the inbox!<br>
><br>
> Dave<br>
><br>
><br>
> On Fri, Apr 15, 2011 at 01:45:24PM -0700, Casey Ransberger wrote:<br>
>> David: I know how to tell you that I want something merged, but I don't know how to make it smooth or fun.<br>
>><br>
>> 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.)<br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> 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.<br>
>><br>
>> On Apr 15, 2011, at 12:42 PM, "David T. Lewis" <<a href="mailto:lewis@mail.msen.com" target="_blank">lewis@mail.msen.com</a>> wrote:<br>
>><br>
>>> On Fri, Apr 15, 2011 at 10:19:49AM -0700, Casey Ransberger wrote:<br>
>>>> 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.<br>
>>>><br>
>>>> 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.<br>
>>>><br>
>>>> I also think that the healthiest solution will involve non-core devs taking ownership of the inbox in a lot of ways.<br>
>>>><br>
>>>> 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?<br>
>>>><br>
>>>> What do the core developers think about this?<br>
>>>><br>
>>>> I must say, I do like Chris' nag-mail idea.<br>
>>><br>
>>> I think you should turn the question around backwards. Instead of<br>
>>> "what can we do to to make people work on the inbox?" ask "what can<br>
>>> we do to the inbox process to make people want to work on it?".<br>
>>><br>
>>> For me, working on something in the inbox should be an enjoyable<br>
>>> thing to do for an hour or so in the morning with a nice cup of<br>
>>> fresh coffee. Right now it's kind of a pain to figure out what's<br>
>>> going in the the inbox, so I tend to find something else to do<br>
>>> while I'm sipping that cup of coffee.<br>
>>><br>
>>> $0.02<br>
>>><br>
>>> Dave<br>
>>><br>
>>><br>
>><br>
><br>
<br>
</div></div></blockquote></div></div></div><br>
<br><br>
<br></blockquote></div><br><br clear="all"><br></div></div>-- <br><font color="#888888">Casey Ransberger<br>
</font><br><br>
<br></blockquote></div><br>