date:20090819

Build failed in Hudson: 3.HEAD-i386-OpenBSD-4.5 #1

2009-08-19 Thread noc

See 

--
Started by user admin
Building remotely on vobsd
ERROR: Failed to clone http://www.squid-cache.org/bzr/squid3/trunk/

Re: RFC: infrastructure product in bugzilla

2009-08-19 Thread Robert Collins

On Thu, 2009-08-20 at 11:33 +1200, Amos Jeffries wrote:
> On Thu, 20 Aug 2009 09:00:15 +1000, Robert Collins
>  wrote:
> > I think we should have an infrastructure product in bugzilla, for
> > tracking list/server/buildfarm etc issues.
> > 
> 
> What sort of extra issues exactly are you thinking need to be bug-tracked?
> 
> We already have websites as a separate 'product' for tracking content
> errors.

Oh hmm, perhaps just renaming websites -> infrastructure.

We have a bunch of services:
 - smtp
 - lists
 - backups?
 - user accounts on squid-cache.org machines (eu, us, test vms, others?)
 - VCS
 - code review

And a wide range of webbish services
 - the CDN
 - bugzilla (currently xlmrpc doesn't work)
 - the main site content
 - patch set generation
 - wiki

-Rob


signature.asc
Description: This is a digitally signed message part

Re: RFC: infrastructure product in bugzilla

2009-08-19 Thread Amos Jeffries

On Thu, 20 Aug 2009 09:00:15 +1000, Robert Collins
 wrote:
> I think we should have an infrastructure product in bugzilla, for
> tracking list/server/buildfarm etc issues.
> 

What sort of extra issues exactly are you thinking need to be bug-tracked?

We already have websites as a separate 'product' for tracking content
errors.

IMO, actual build failures can go in as regular FTBS (fail to build).
Against the 'test-suite' or 'other' sub-sections of the Squid product. We
would need to be careful of this so as not to add duplicates many times
over.

Amos

RFC: infrastructure product in bugzilla

2009-08-19 Thread Robert Collins

I think we should have an infrastructure product in bugzilla, for
tracking list/server/buildfarm etc issues.

-Rob

-- 


signature.asc
Description: This is a digitally signed message part

Re: assertion: new_mem_lo > 0

2009-08-19 Thread Henrik Nordstrom

ons 2009-08-19 klockan 19:20 +0200 skrev Henrik Nordstrom:
> ons 2009-08-19 klockan 16:15 +1200 skrev Amos Jeffries:
> > Henrik, this is the new memory-promotion patch dying.
> 
> Does not look like the patch, but I will look into it regardless.

In fact it was... For some reason I tried to optimize the caller which
exposed this fragile point of the cache_mem maintenance when dealing
with "private" objects.

Still thinks the assert should go, but that's another day when the
cache_mem maintenance is looked over, the current code has room for
improvement in both style & performance.

Regards
Henrik

Re: assertion: new_mem_lo > 0

2009-08-19 Thread Henrik Nordstrom

ons 2009-08-19 klockan 16:15 +1200 skrev Amos Jeffries:
> Henrik, this is the new memory-promotion patch dying.

Does not look like the patch, but I will look into it regardless.

My first reaction is "Why is that assert there?". May well be the case
that it should not be asserted.

Regards
Henrik