[Idle-dev] DS_RPC_BRANCH

[Bruce Sherwood]

Since my name appears in this note, I'll say that I'm certainly very
interested in bundling a spiffy new version of IDLE with VPython. I've been
consumed with a move from Carnegie Mellon to North Carolina State
University, so I haven't attempted to run a recent version of idlefork, due
to my (mis?)perception that there really has never been something one might
call a "release". Once there is such a thing, I'll certainly try it myself
and consult with you developers on whether it's ready for prime time with
novice freshmen in a physics course.

Bruce Sherwood

----- Original Message -----
From: "Kurt B. Kaiser" <kbk@shore.net>
To: <idle-dev@python.org>
Sent: Tuesday, September 03, 2002 6:00 PM
Subject: Re: [Idle-dev] DS_RPC_BRANCH


> "Stephen M. Gava" <elguavas@python.net> writes:
>
> > On Tue, 2002-09-03 at 07:47, Kurt B. Kaiser wrote:
> > > I was unable to test the Unicode fix in the branch (though I assume it
> > > works); the branch is broken for me because loader.py, which is
> > > apparently necessary for DS_RPC to function, was removed and also
> > > because the merge of Autoindent.py into EditorWindow.py needs some
> > > work.  (AutoIndent is still a required extension in PyShell.py, but
> > > the module has been removed.)
>
> [...]
>
> > If there are problems, this whole situation only goes to reinforce what
> > I've been saying about how we need to fold the branch back into main now
> > and continue all development there. The fact is, if we were both working
> > on the same branch (or the trunk) then problems of all these kinds
> > wouldn't arise; any breakages would be detected in a much more timely
> > fashion because we'd both be working on and testing the same code,
>
> We could not reasonably both work on the same branch, but that phase
> is ending.  See below.  That doesn't mean we don't test each other's
> code, though, at least occasionally.
>
> > and there would be no patches getting lost
>
> If you are talking about the Unicode patch, it didn't get lost.  I
> wiped it out by accident when I ripped out the DS_RPC code in
> OutputWindow.py.  Patrick O'Brien was kind enough to test GRPC and
> post the bug.
>
> > and no confusion for our users about exactly what they should check
> > out if they want to use cvs. These kinds of problems were exactly
> > why I argued against branching the development effort (of course
> > just tagging cvs itself causes no problem) in the first place.
>
> It is common practice to split off a branch when
>
> 1. Major changes are contemplated which should be isolated until the
>    design and the code are stable.  Then there's a merge.  RSN :)
>
> 2. A release is made and a bugfix branch is started which will get
>    only critical fixes.  Python and many other OS projects do this
>    often.  Most users have no trouble dealing with it, especially if
>    a packaged release of the branch is made periodically.  Eventually
>    the branch is left behind.
>
>    I continue to think we should have a final release of the DS RPC
>    version of Idlefork.  However, this is worth doing only if Sherwood
>    et. al. are interested in that happening.  (although I'd be
>    interested in one merely for closure's sake :) In the course of
>    working on GRPC I've come across couple of apparent bugs which
>    should be investigated, but only a couple.  It seems pretty solid,
>    and I would think they would want to avail themselves of all the
>    good work you've been putting into it over the past year.
>
> > When you and Guido convinced me to have work proceed on two branches
> > simultaneously in the first place it was with a couple of provisos;
> > one was that you volunteered to make regular (weekly or fortnightly)
> > merges of DS_RPC_BRANCH back to main, and the other was that it
> > would only be a short term temporary situation and that all
> > development would soon be able to continue on main.
>
> You seem to be telling me to hurry up and finish the conversion to
> GRPC so that you don't have to feel slighted by being "stuck" on a
> branch that doesn't have the tag "MAIN" :) Hey, it's only a name!
>
> It's not practical to do the kind of work I'm doing on the same
> branch with other development.  The changes I made were drastic and
> you couldn't work on your tasks with me continually pulling the rug
> out from under you by changing the whole design and internal code
> structure.  And I didn't want to tiptoe about worrying about screwing
> you up.  So the only question was, which branch is called "MAIN"?  And
> the reasonable answer was, the basic rpc design we were going to stay
> with long term, because that puts DS_RPC in a terminating bugfix
> side branch.  It's _much_ easier to merge you to me than vice-versa!
>
> There is no reason why you shouldn't charge ahead on DS_RPC_BRANCH.
> I'm not afraid of merges!
>
> But I'm almost done (I hope) with the rpc conversion.  The restart
> code is running.  One of the things I have yet to do is reload the
> subprocess debugger breakpoints during the restart.  But the overall
> structure has settled down and the code in CVS is quite usable.  (Has
> been all along from a user point of view, actually.  I hope people
> will try it and give me feedback.)
>
> Soon you can switch over to MAIN without having to worry that the
> whole design changed overnight (again) and your concept of a major
> portion of the codebase is (once more) obsolete.
>
> > So I'll repeat my question of a couple of weeks ago again, would you
> > be able do a merge soon, please, so that we can get things back on
> > track?  I realize the time you have available has all been taken up
> > working on the rpc stuff so you've had no time to do a merge yet,
> > but really, I think this is a priority.
>
> There is not all that much to merge, because some of the stripping you
> are doing tracks what I did.  As a matter of fact, I was looking into
> a merge, and I ran into the issues discussed in my previous post.
>
> Once I get DS_RPC running in my sandbox, I'll run my little test suite
> on it and then do a merge to MAIN right away so we can be "on track".
>
> Regards, KBK
>
>
> _______________________________________________
> IDLE-dev mailing list
> IDLE-dev@python.org
> http://mail.python.org/mailman/listinfo/idle-dev
>