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

[Mike Rylander]

On 12/16/06, Don McMorris <don.mcmorris at gmail.com> wrote:
> <!--/me snips again... for those not fortunate enough to have gMail ;)-->

heh ... poor exchange users... ;)

[snip]

> >
> > One concern I have, expressed by others as well, is that while the
> > project's documentation can obviously be user-contributed, there's
> > currently no way for developers to contribute code with revision control
> > without forking the repository. Are there plans to start a project
> > repository at a third-party host (I'd recommend Savannah), maybe even
> > upgrading from CVS to SVN?

> Being an "outsider", this is just pure speculation... My thinking is
> that CVS will stay "in-house" for a while.  This allows slightly more
> lax security, and as such more freedom for the developers dedicated to
> it.  The 5 people working 8 hours a day (plus volunteer time) on
> virtually nothing but Evergreen need to use systems' they are most
> comfortable with.  When changes start slowing down (V2.2 I would
> guess), I would imagine more community involvement would be encouraged
> (including outside CVS or SVN check-ins).

All of those reasons are good ones (it's actually only 3 of us writing
code, but yeah), but I don't want to give the impression that we're
waiting until some arbitrary time to start handing out the commit bit.
 We're just not going to do it (no matter how well intentioned any
contributer is) until there is a (development) working rapport between
the current dev team and any new member, and we are of the opinion
that the new developer "gets" the full codebase.  At that point, we'd
put it to a vote.

I think an example (actually alluded to by Dan Scott, IIRC) would be
instructive here.  To start out, at the very least, we're going to
follow the Postgres community's process for integrating submitted
contributions to the code.  A basic overview of that process is
available here* in sections 1.1 - 1.7.  The core team will then, based
on the quality, style and vision similarity to existing code, size,
breadth of contributions and the ongoing support provided by the
contributer, invite individuals to join the core team and hand out the
commit bit.  There are 2 very good (IMHO) reasons for this:  EG is a
complex beast and we want to make sure that those with commit privs
have the required breadth of knowledge of the existing codebase; a
more strict commit procedure will make public discussion of new
features, as well as the best way to attack bugs or architectural
issues, an absolute requirement.

What this means is that everyone (core or not) will need to propose,
justify and defend their plan before getting the code into EG for
anything non-trivial.  Committers will have a slightly shorter path to
actual release, but no less rigorous a test before the acceptance of
the code.

(I'll address the fact that we don't currently do this by saying that,
well, the core team are the only ones writing code today.  As soon as
we have regular outside contributers it will be in our best interest
to follow that rule as well, to avoid stomping on others' development
efforts, and to make sure they don't step on ours.)

 * http://www.postgresql.org/docs/faqs.FAQ_DEV.html

Josh, we know you and we've seen a small amount of code from you
personally (related to this project), but we'd feel more comfortable
(as we would with anyone else who'd like to contribute to development)
if you'd start by sending patches instead of threatening a fork or
requiring commit privs on the GPLS servers in order do anything.

I'd also add that there's no reason whatsoever to fork anything.  All
we need is a patch -- diff(1) is your friend.  You can either add -P
to the diff command line to get new files, or send a tarball of files
that don't exist in the repo yet.

>
> For now, submissions should be sent to this (open-ils-dev) list for
> PINES to (potentially) integrate into the Evergreen product.
>

Exactly ... I didn't realize this was non-obvious, but then I'm used
to the Postgresql and Linux communities, where this is the norm.

> >
> > LibLime has a few contributions we'd like to make to the project in the
> > coming months, including:
> >
> > 1. Automake/Autoconf
> > 2. A Z39.50 Server
> > 3. NCIP Support (in addition to SIP2)
> This will be appreciated very much! For now, I think the best way is
> to either post to this list (open-ils-dev) the details, or post a link
> to a URL with details.  One of theGuys(tm) should link it up, check it
> in, and commit it for you (assuming it works, doesn't break anything,
> etc.).
>

Directly to the list would be best.  Keep things you want us to know
about in our work stream.  :)  In addition to code, we'd expect
pre-implementation discussion covering the plan and informed by the
entire community, and following that, acceptance of the consensus of
the existing dev team, who will be charged with maintaining any
incoming code.

> >
> > Any thoughts on how best to handle revision control of the project as
> > a development community forms around Evergreen?
> In the future (My guess: Late 2007/Early 2008), Evergreen will be
> "complete", and it will more-or-less be turned over to the community.
> There will, of course, be lots of support from theGuys(tm), but
> community involvement would likely become a significant portion of the
> products' evolution.
>

See above ... IMHO, EG won't ever be "done" ... I have FAR too many
evil schemes for extensions and additions.  ;)

I'll work on formalizing this on the wiki over the next few days/weeks
(vacation may interrupt...) so we can all work to nail this down
better.  Thanks, everyone, for the lively discussion!

>
> --Don
>

-- 
Mike Rylander
mrylander at gmail.com
GPLS -- PINES Development
Database Developer
http://open-ils.org