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

[Don McMorris]

<!-- Wow... this was huge! -->
> 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 agree that revision control is critically important.  The notable
difference you mentioned though is THE difference.  There are 3 people
in PINES whom are dedicated pretty much solely to Evergreen 40 hours a
week.

One day in the future, it may be advantageous to lessen the strictness
of the Evergreen versioning system.  At this time though, given the
development style, the current system is probably best.  The model has
proven successful for many other large, enterprise-scale applications
(IE: Postgres, Linux [kernel]).

>
> 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).
Similar to that of the Linux kernel and Postgres, once a user have
proven themselves (by successfully coding several non-trivial portions
without breaking anything else), they may be granted commit privs to
CVS.  I have no doubt as to your coding ability and experience, but
Evergreen is a rapidly evolving animal which is quite fragile.

All I could suggest (again, as nothing more than a 3rd party fan of
Evergreen) is to master the code then submit (to the open-ils-dev
list) your changes in summary, packages, and/or patches.

>
> > 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 ;-).
I'm used to smaller communities too, and it took me a while to adjust
to the politics/procedures of this project.  However, given all the
variables and present situations, I think this way is the best.  As
has been said by me, Mike, and others, Community support is invited
and appreciated! All that is asked is that you prove yourself by
submitting (to this mailing list) your contributions.  If you "prove
yourself" (I hate the term, but it's appropriate) frequently
submitting fairly significant, non-trivial contribs, you may be
granted access to the Internal CVS to commit.



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

--Don McMorris (KC2QHO), Salem NY.
*Unaffiliated with Evergreen project in any other way other than being
a fan of the project