[Grok-dev] BOUNTY! was: Next Step to Bug Resolution???

[Tim Cook]

Based on private responses I have received I would like to clarify some
things.  

I fully realize that people have their days jobs.  So do I.  I do not
get paid to work on this project. 

Secondly, I am a ZCA user.  I am a Python tinkerer, not a programmer.
It seems to me that it would take me days to contrive a mockup of this
situation so that there is a live demonstration of this error outside of
my project.  

I believe that it would take an experienced Python/Zope developer no ore
than 1-2 hours to install my application, see the problem and provide a
fix.

There is an explanation of how to exercise the problem as well as how to
apply my suggested fix here:  
http://www.openehr.org/mailarchives/ref_impl_python/msg00406.html 

The pertinent part is the last 4 paragraphs and it is copied below for
convenience.   

************************************************************************
I will later commit an update that fixes two errors he found.  I will
also include a new zope.schema._filed.py file that correctly processes
the multi-level Object field calls that we make.  I have no idea when
the Zope gurus will be updating zope.schema  But I know this fix works
for our needs.  It will be in the docs directory and named as
_field.py.oship

To see the problem that exists in the current _filed.py you can start
your server and verify that you can go to
http://localhost:8080/oship/archetypedetails and verify that you can see
the archetype details.  In your terminal window you should see that
there are no errors reported. 

Stop your server and go to
oship/km/openehr/ehr/cluster/checklist_item_general.py and around line
#75 and uncomment the self.parentArchetype assignment.  Now start your
server and go to the link above.  You will get a server error and in
your terminal window you'll see that you have a WrongContainedType
error.  

Stop your server.  Replace _field.py in you zope.schema egg directory
(rename your original first) with the _field.py.oship Restart your
server and you will see that it now correctly  processes the multi-level
Object fields.  If you want more details about this then please see the
bug report I filed on Launchpad
https://bugs.launchpad.net/bugs/301226 

************************************************************************

This issue is such a huge frustration for me that I am offering a bounty
of 100USD out of my personal pocket to the first person that solves the
issue, gets it committed to a published zope.schema egg and included in
the standard Grok distribution.

It seems to me to be a reasonable (though not extravagant) amount since
most of the trouble shooting has already been done.

Thanks,
Tim



On Thu, 2008-12-18 at 08:35 -0200, Tim Cook wrote:
> Hi All,
> 
> I have had an issue on the table for months.  I started a dialog about
> it here:  
> 
> http://mail.zope.org/pipermail/zope3-users/2008-October/008215.html
> 
> The thread was interesting, helpful and did lead me to find an error in
> some schema definitions because of a misunderstanding of the required
> attribute.  But that had nothing to do with the problem.
>  
> It was first thought that it was a nasty, empty error report.  After
> some investigation I discovered that it was an error that shouldn't be
> an error.  Once I determined what I thought was the cause and a possible
> fix I posted a bug report on Launchpad
> 
>  https://bugs.launchpad.net/zope3/+bug/301226 
> 
> So here we are.  I have a possible solution and the only comments I get
> from the Zope Community are private emails (yes plural) asking me if
> anyone is working on this issue.  I have to say that as far as I can
> tell; no.  At this point I would be happier if someone just told me why
> my fix might negatively affect the other schema field validations.
> 
> Now I realize that I must be the only person in the entire world to
> exercise zope.schema this way.  BUT! It should work or it should be WELL
> documented that you  cannot have cascading attribute=Object(IMySchema)
> definitions.
> 
> The description of the project is here:
> http://www.openehr.org/wiki/display/dev/OSHIP+Developer%27s+Wiki 
> 
> This is a rather major project.  See: http://www.ohloh.net/p/oship for
> some metrics.  We have just received three years of funding from the
> Brazilian government to complete the platform and develop an
> Epidemiological decision support system on top of it to improve the
> recognition of syndromic outbreaks.  
> 
> Right now the hardworking core open source team understands that we need
> to replace zope.schema._field.py with our own to make it work.  But when
> the project is ready, in a few months, for healthcare application
> developers worldwide to start using it.  It may be a hard sell to say;
> "Yeah we use the really cool, robust, well tested and trusted
> application server called the Zope Component Architecture because it
> really shows the strengths of the open source development process.  Oh,
> by the way, after everything is installed you have to replace a core ZCA
> file with the one we provide you in order to make it actually work."
> 
> Doesn't sound very professional to me and it should be embarrassing to
> the Zope Community if that has to happen.
> 
> Thank you for reading this long posting.  I hope someone delivers me a
> Holiday package in the form of a fixed zope.schema package.  :-)
>   
> Cheers,
> Tim
> 
> 
-- 
Timothy Cook, MSc
Health Informatics Research & Development Services
LinkedIn Profile:http://www.linkedin.com/in/timothywaynecook 
Skype ID == timothy.cook 
**************************************************************
*You may get my Public GPG key from  popular keyservers or   *
*from this link http://timothywayne.cook.googlepages.com/home*
**************************************************************
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : http://mail.zope.org/pipermail/grok-dev/attachments/20081218/7ed43c7d/attachment.bin