[OPEN-ILS-GENERAL] Ongoing conversion effort
jmorris at beau.org
Sun Mar 6 17:43:09 EST 2011
On Sun, 2011-03-06 at 08:41 -0500, Dan Scott wrote:
> On Sat, Mar 05, 2011 at 10:45:26PM -0600, John Morris wrote:
> > ARGH! Found it. You submitted a bug report (#727595) and someone
> > responded to the 'problem' by nuking the whole page from the docs! So
> > now how do I find that useful information again?
> If your use of quotes is an attempt to dismiss my concern that our
> project needs to properly attribute the provenance of its code, whether
> contained in the docs or in the code repository, well... I'm not sure
> how to respond. I am not a lawyer, but it seems to be a matter of basic
> legal hygiene.
Dunno, last night was more of a Winning The Future moment as what I
thought was a solved problem suddenly did a Charlie Brown & the
football. But I'm reading the bug again and, working from memory
(obviously) can't see the connection between the example in the 2.x
tarball or the one in the docuwiki compared to the one that was nuked.
The two remaining examples are close if not exact, but the one that was
in the manual was a very different animal. It used the crontab entry to
call out to a wrapper script that would make it trivial to manually
invoke a job if needed and know all of the options were being set
If there isn't any sort of revision control on the manual it might not
be possible to know who wrote it if the author(s) are somehow out of the
EG community now, but somebody put in a lot of hours getting that
written and debugged so it would be a shame to lose it. Destroying
knowledge should be a last resort, not a default. After all, are we not
> I suggested various methods to address the issue that I raised, none of
> which were the immediate removal of that page from the docs, but I
> assume the docs maintainer opted to take that approach as the most
> conservative method and most protective of the project. I can't fault
> him for that.
Wasn't blaming you for removing it. The better solution would have been
to MOVE the script into the source tree, not REMOVE it from existence.
And yes some nominally open source projects do descend into the overly
legalistic madness of requiring a perfect audit trail of every submitted
patch, no matter how small; some even require explicit copyright
assignment paperwork be on file from every single contributor including
a sign off from their employer. That usually only happens on projects
with a heavy corporate presence, like OO.o or Java.... or the FSF. One
can only hope EG doesn't end up there.
> As for what appeared to be an ancestor of that script, which also
> contains brief descriptions of each script along with suggested
> schedules for when they should be run, I pointed to it from the bug
> report in both the wiki and the relative directory within the source
> code. Presumably you found this wanting, or else you wouldn't have
> posted to the Evergreen General mailing list.
Which is what I'm going to be forced to use. It should work for now and
time has ran out, our spring all staff meeting is Monday and we are
going to attempt a roll out. The idea is to have EG running on a
scratch copy of the database and have everyone beat on it with every
task they are expected to do and yell if they hit a showstopper. If we
can't fix it tomorrow we open Tuesday on the old system, if nobody yells
stop I reload a clean copy and we are an Evergreen library Tuesday
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 198 bytes
Desc: This is a digitally signed message part
Url : http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20110306/089b4416/attachment.pgp
More information about the Open-ils-general