SPAM: Re: [OPEN-ILS-DEV] Getting there -- bootstrapping OpenSRF Client problem

[Jonathan Rochkind]

At 4:55 AM -0500 12/17/06, Mike Rylander wrote:
>If I'm misunderstanding your intended use for a "local repository"
>(entirely possible, since you haven't stated why it's necessary) and
>you're talking about direct development effort as opposed to customer
>customizations, then, well, I still don't get why you need this.  I
>mean (in a nutshell), you submit a proposal for everyone to comment
>on, get feedback, check out the code, develop against it and then
>submit the patch.

I believe Joshua is suggesting that the 'develop against it' step, 
for any significant project such as some he has envisioned (which he 
has indeed mentioned at least to name them, but not outlined in any 
detail), requires local access to version control in order to do that 
development. This makes sense to me; I don't like to develop more 
than a couple hundred lines at most without version control (I'm not 
saying I don't do it, just that I don't like it!).

[In large open source projects that do not give all developers commit 
rights, do developers generally NOT have their own local revision 
control?  That would surprise me, but I've never participated in such 
a project, so maybe I'm confused.]

Figuring out how to work collaboratively on this kind of project is a 
new thing for many of us that we aren't sure how to navigate. I can't 
speak for Joshua, but it's new for me and it's unclear to me how 
these sorts of things work. It wasn't obvious to me that "submit a 
proposal for everyone to comment on; get feedback" was a necessary 
set of first steps to 'develop against it', when I had an idea for 
something I wanted to add to the codebase.

I would like to see you two somehow on the same page, I'm not sure 
why you keep ending up on different trains (Ah, mixed metaphors). I 
think you are both well intentioned.

I think we all need to be less sure of what's "obvious" about how a 
collaborative distributed development process (like I think everyone 
wants to EG to turn into) works---I'm not sure every such project 
works the same (I'm honestly not sure, because I'm new to 
collaborative open source development), but I am sure that everyone 
doesn't seem to be on the same page with how this process should 
work. I think both Joshua and Mike are assuming the other party 
shares some of their basic assumptions about how this kind of 
development works, that the other party does not in fact share.  This 
doesn't mean either one is necessarily 'right' or 'wrong', although 
perhaps EG gets to _choose_ how it should work for this project., in 
the end.

I would like to see this developing rift between Mike and Joshua 
repaired instead of deepened, because it would be good for all of us. 
What is really at the root of what's going on?  Let's talk about 
what's actually going on---Mike, are you intending to say "Hey, we're 
actually really not READY for you to be doing the kind of development 
you are talking about, and would prefer that you NOT start it yet." 
Because I think that's what Joshua is picking up, intended or not by 
you,  and reacting defensively to.  Even though we're computer geeks, 
we're allowed to talk about our, um, 'emotional reaction'.   What _I_ 
see (perhaps completely incorrect) is the EG team feeling 
uncomfortable about loss of control of their project with Joshua 
threatening to do things without coordination; and Joshua feeling 
like he's being excluded from meaningful participation with 
unreasonable barriers, but also being a bit too prematurely 
aggressive in making sure everyone knows he's not going to be 
stopped.   I think maybe you actually need to talk about the 
underlying dynamics in order to solve it, not just pretend that it's 
all about technical disagreements.  I would, again, like to see an 
understanding reached, and I don't think it's impossible, although it 
soon will be if you both continue going on as you both have and turn 
into lifelong enemies (unless you already are due to some past 
history I don't know about, in which case it's probably a lost cause. 
:) ).

I also think that Joshua going into some detail about the first such 
project(s) he envisions would help get people on the same page on the 
technical end, then people can talk about the social/organizational 
processes appropriate/necessary for Joshua to get started on those 
projects he envisions.

Jonathan


>The first step, of course, is to install the system and become
>familiar with the architecture and code -- both functionally and
>stylisticly.  If there is some particular and strong reasons why,
>after having done this, you don't see this idea as viable at all we
>would love to hear why.  Perhaps we can all work together to fix the
>issues, or, in the alternative, you may be able to convince us that
>another option is a better choice at this time.
>
>>I'm also fine with maintaining a LibLime EG version control system (as
>>I'm sure GPLS does for production EG).
>
>Actually, you'd be wrong about that.  PINES runs on the code you see
>in CVS (the rel_1_0 branch), with the ONLY difference being the site
>specific configuration files that define IP addresses, database setup
>and the like, and the delay of some staff client additions due to
>testing requirements.  That's eating our own dog food.
>
>Obviously, local updates to templates and such should be retained on
>upgrade, and that will be part of the proposal I will be introducing
>for installation and deployment.  To state unequivocally that you will
>need to keep what amounts to a full fork in order to do any work seems
>a bit hyperbolic, IMHO.
>
>Lastly, I certainly don't want to sound dictatorial or to issue any
>ultimatums, and it is not the intention of GPLS (or myself) to stymie
>the growth of any component of this fledgling community, but I think
>we're really going to need more detailed thoughts on these issues if
>you expect us to understand why all this is a requirement for you,
>Josh.
>
>--
>Mike Rylander
>mrylander at gmail.com
>GPLS -- PINES Development
>Database Developer
>http://open-ils.org