[Idle-dev] DS_RPC_BRANCH

[Stephen M. Gava]

On Wed, 2002-09-04 at 08:00, Kurt B. Kaiser wrote:
> We could not reasonably both work on the same branch, but that phase
> is ending.  

Well, from watching the state of both branches, I think that in reality,
with just a couple of short waits on my part, we could have coordinated
it fairly easily. *shrug*

> See below.  That doesn't mean we don't test each other's
> code, though, at least occasionally.

Sure, but it means maintaining two checkouts and spending time only
testing. This is the exactly kind of makework I had hoped to avoid in
the actual case, of two part time developers.

> > 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.

Well, I guess that's just semantics. ;^) I call that "getting lost" at
least temporarily, you call it "being wiped by accident then replaced".
The net result for cvs users was that the patch was lost from recent
checkouts.

> It is common practice to split off a branch when

I'm perfectly aware that it's "common practice"; I just don't happen to
believe that it was the best thing for us to have done in our actual
case here. I was worried that it might cause more problems for us than
it would solve, and I think it has.

>    I continue to think we should have a final release of the DS RPC
>    version of Idlefork.  

Please re-read my earlier detailed response to this suggestion. I guess
it sounds pretty simple to just pop out a release, but actually it's a
lot of work. Again I think we must avoid nice sounding in theory
makework that steals what little time we have between us away from what
we actually need to be focusing our limited energies on: getting out
some tarballs of 0.9x with all the new stuff in for people to test.

Let me try and explain myself. My focus in all of this has not been on
the most theoretically perfect way of proceeding, it has been purely on
managing a project with very limited resources in such a way that I hope
we will achieve the main desired result. Sometimes that approach does
not equal doing things the most theoretically perfect way. If you are
unhappy with my attempts to carry out my role with the project, which is
not only developer but manger and coordinator, then I am happy to drop
back to just being a developer if you want to take over that
coordinating role and move things in a different direction, honestly, I
could well do without the extra grief. 

> 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!

C'mon Kurt, why would I care about that? Man. My concern, which I've
restated several times, is that splitting active development over two
branches will be inefficient and not really in the best interests of the
project. I think that has proven to be the case. I reiterate that the
idea of tagging a branch with the old rpc code was a good one, but I
don't think dividing our developer effort was. 

> 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.  

Well as I've said already, this was why I agreed on two active
development streams, but only in the short term. From watching the state
of the checkins I feel that that stage passed quite early on, early
enough in fact for my recent work to have been happily on the same
branch. In fact I have a backlog of python idle patches to move over now
as well that should not be applied on the branch but also should not be
applied to the trunk before we merge back. So again, I think that if the
splitting of the active development effort had been much shorter, the
problems possibly caused would have been far outweighed by the problems
actually solved. Of course what's done is done and now we make the best
of it, but in retrospect I think that I should have just waited a little
while a couple of times for the dust to settle and then continued
working on the same branch as you, I believe the economies of scale were
in favour of this approach in the realities of our project. You don't,
so there you go.

> There is no reason why you shouldn't charge ahead on DS_RPC_BRANCH.
> I'm not afraid of merges!

The bigger they are the more time they waste. I'm not able to be so
cavalier with my limited free time and energies. I think the best merge
is no merge required. 

> 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.)

That's great. I've been following your work in commits and messages here
and it's really terrific. The quality of the future idle will owe you a
great debt. I'm sorry but I honestly haven't had the time to maintain a
separate checkout and do testing-only work on your branch as well. Like
the rest of the new stuff, your code will get the lion's share of it's
testing when we can include it in some tarball releases.

> There is not all that much to merge, because some of the stripping you
> are doing tracks what I did.  

I'm glad to hear that. Of course I wait til you are ready to spend time
on the merge. If I unintentionally sounded a little peeved in my last
message about "are we able to do this soon" it was probably because I
got no answer on that the first time, undoubtedly because you have been
so busy, so apologies for that.

> 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".

Yes, you may want to wait until I have a chance to sort out PyShell's
dirty AutoIndent code. I guess it doesn't matter though, as long as
those fixes are also propagated over to DS_RPC_BRANCH so that I'm not
knowingly leaving any major breakage there.

Ciao,
Stephen.
-- 
Stephen M. Gava <elguavas@python.net> http://python.net/crew/elguavas
IDLEfork http://idlefork.sourceforge.net "just like IDLE, only crunchy"