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

[Joshua M. Ferraro]

----- Mike Rylander <mrylander at gmail.com> wrote:
> 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 didn't threaten a fork, nor did I require commit privs on a GPLS
server as a requirement for contributions. However, as you know,
revision control is a critical part of any software development and
as a result, it's just a natural progression that 'outside' developers
will be  maintaining their own revision control system if they aren't
allowed access to mainline. I can tell you that in the Koha community,
this wreaked havoc in a big way (we're recovering slowly) because 
ultimately, no-one had/has time to verify submissions and commit them
to the core project. Well, actually, more to the point, the developers
themselves didn't take the time to package up their changes and send
them to the core developers. One notable difference with EG is that 
there are full-time programmers hired by GPLS so you may have resources
available for that kind of overhead.

I will add that while this may be a common way to handle large-scale 
projects (like the linux kernel or postgres), it _might_ prove to be 
quite a lot of overhead for such a small project (small in terms of
number of developers).

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

> > 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.
Right ... whereas I'm used to smaller OSS communities like Koha where
there are only a few core developers and we hand out commit privs to
anyone who asks ;-).


-- 
Joshua Ferraro                       SUPPORT FOR OPEN-SOURCE SOFTWARE
President, Technology       migration, training, maintenance, support
LibLime                                Featuring Koha Open-Source ILS
jmf at liblime.com |Full Demos at http://liblime.com/koha |1(888)KohaILS