[Zope-dev] release checker bot results.

[Chris McDonough]

I have taken down the zope.app.publisher 3.5.0a2 release from the  
cheese shop after being punished with the appropriate access. ;-)  I  
suspect that will bite someone, but I think it will bite "the right"  
people.

We'll see how this works out during the bot run tonight (an  
interactive test of installing zope.tal was promising).

- C


On Nov 16, 2007, at 10:49 AM, Chris McDonough wrote:

>
> On Nov 16, 2007, at 9:25 AM, Jim Fulton wrote:
>
>>
>> On Nov 14, 2007, at 8:23 AM, Chris McDonough wrote:
>>
>>> Attempting to easy_install all 'zope'-related releases using the  
>>> script at http://svn.repoze.org/playground/trunk/chris/zopesvnchecker/releasechecker.py 
>>>  , the results were:
>>>
>>> 122 failures, 67 successes.
>>
>> I guess most of these can be fixed by unscrewing the  
>> zope.traversing problem. Has anyone done that? Is anyone going  
>> to? :) If not, I will just cause I'm tired of reading about it. :(
>
> I would, but I don't have access.  I think we just need to take down  
> the bogus zope.app.publisher 3.5.0a2 release.
>
> I hate the idea of removing releases (because it "changes  
> history").  But I suspect it's a better solution than releasing  
> zope.app.publisher 3.5.0  and zope.traversing 3.5.0, where  
> zope.app.publisher 3.5.0 depends on 'zope.traversing' instead of  
> 'zope.traversing>=3.5.0a1.dev-r78730'.  That would mean we're  
> positing that that release actually works with everything else and I  
> don't know if it does or doesn't.
>
>> Some of these errors are spurious.  For example, ZODB4 shows up as  
>> a failure even though there are no distributions.  I think the test  
>> script needs to check for this case.
>
> I think the metadata on the cheeseshop needs to get cleaned up:
>
> >>> import xmlrpclib
> >>> s = xmlrpclib.ServerProxy('http://www.python.org/pypi')
> >>> s.package_releases('ZODB4')
> ['4.0a2']
>
> http://pypi.python.org/pypi/ZODB4/4.0a2
>
>> I also think you should not list as failures anything that failes  
>> due to a gcc error. Often this will be due to the absense of  
>> libraries (e.g. spread).
>
> Yep.  I'll have to maintain the exclude list manually I think,  
> because the failure output isn't necessarily regular.
>
> - C
>