[Idle-dev] DS_RPC_BRANCH

[Kurt B. Kaiser]

"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