On Wed, 2008-10-15 at 16:25 +1300, Amos Jeffries wrote:
> Alex Rousskov wrote:
> > On Wed, 2008-10-15 at 14:15 +1300, Amos Jeffries wrote:
> >
> >>> IMO, if a user explicitly requested feature Foo and Foo cannot be
> >>> supported, we should fail rather than ignore the user request.
> >> That woul
On Wed, Oct 15, 2008 at 3:51 AM, Alex Rousskov
<[EMAIL PROTECTED]> wrote:
> On Wed, 2008-10-15 at 12:35 +1100, Robert Collins wrote:
>
>> > > IMO, if a user explicitly requested feature Foo and Foo cannot be
>> > > supported, we should fail rather than ignore the user request.
>>
>> I completely ag
On Wed, Oct 15, 2008 at 3:04 AM, Mark Nottingham <[EMAIL PROTECTED]> wrote:
> So I think we ended up:
>
> 1) change from cache_object:// to http://
> 2) configurable access path
> 3) drop authentication suffix (@password) from URL
> 4) enforce unique_hostname / visible_hostname / hostname_aliases a
Alex Rousskov wrote:
On Wed, 2008-10-15 at 14:15 +1300, Amos Jeffries wrote:
IMO, if a user explicitly requested feature Foo and Foo cannot be
supported, we should fail rather than ignore the user request.
That would not be a good idea either IMO. Rather have eCAP default on and
self-disable n
On Wed, 2008-10-15 at 14:15 +1300, Amos Jeffries wrote:
> > IMO, if a user explicitly requested feature Foo and Foo cannot be
> > supported, we should fail rather than ignore the user request.
>
> That would not be a good idea either IMO. Rather have eCAP default on and
> self-disable noisily on
On Wed, 2008-10-15 at 12:35 +1100, Robert Collins wrote:
> > > IMO, if a user explicitly requested feature Foo and Foo cannot be
> > > supported, we should fail rather than ignore the user request.
>
> I completely agree with this. The usual behaviour I see that works well
> is:
>
> no-parameter
On Wed, 2008-10-15 at 14:15 +1300, Amos Jeffries wrote:
>
> >
> > IMO, if a user explicitly requested feature Foo and Foo cannot be
> > supported, we should fail rather than ignore the user request.
I completely agree with this. The usual behaviour I see that works well
is:
no-parameter supplied
> tis 2008-10-14 klockan 16:28 +0200 skrev Kinkie:
>
>> I agree.
>> What about restructuring to
>> - core
>
> Instead of core I would use "general", for everything not having a
> explicit component.
>
>> - authentication and authorization
>> - docs
>> - content adaptation
>> - testsuite
>
> Looks g
> On Tue, 2008-10-14 at 22:06 +1300, Amos Jeffries wrote:
>
>> On the eCAP side. I've found an issue with its configure tests. Seems to
>> me that the MSG_ERROR and MSG_FATAL are the wrong way around.
>
> I did not find MSG_FATAL in autoconf documentation. The code is using
> AC_MSG_ERROR and AC_MS
So I think we ended up:
1) change from cache_object:// to http://
2) configurable access path
3) drop authentication suffix (@password) from URL
4) enforce unique_hostname / visible_hostname / hostname_aliases as
the URI authority
5) still pay attention to global_internal_static
6) modify mana
tis 2008-10-14 klockan 16:28 +0200 skrev Kinkie:
> I agree.
> What about restructuring to
> - core
Instead of core I would use "general", for everything not having a
explicit component.
> - authentication and authorization
> - docs
> - content adaptation
> - testsuite
Looks good.
Regards
Henri
On Tue, Oct 14, 2008 at 12:43 PM, Henrik Nordstrom
<[EMAIL PROTECTED]> wrote:
> On tis, 2008-10-14 at 12:17 +0200, Kinkie wrote:
>> Hi all,
>> IMVHO Bugzilla is missing a couple of component specifiers:
>> - for the squid project, it misses a possibility of reporting bugs to
>> the unit tests sui
On Tue, 2008-10-14 at 22:06 +1300, Amos Jeffries wrote:
> On the eCAP side. I've found an issue with its configure tests. Seems to
> me that the MSG_ERROR and MSG_FATAL are the wrong way around.
I did not find MSG_FATAL in autoconf documentation. The code is using
AC_MSG_ERROR and AC_MSG_FAILURE
On tis, 2008-10-14 at 12:17 +0200, Kinkie wrote:
> Hi all,
> IMVHO Bugzilla is missing a couple of component specifiers:
> - for the squid project, it misses a possibility of reporting bugs to
> the unit tests suite
> - for the website, the missing component is bugzilla itself.
>
> If there's ag
Hi all,
IMVHO Bugzilla is missing a couple of component specifiers:
- for the squid project, it misses a possibility of reporting bugs to
the unit tests suite
- for the website, the missing component is bugzilla itself.
If there's agreement, could a bugzilla admin add those?
Thanks
--
/kin
Alex Rousskov wrote:
On Sun, 2008-10-12 at 00:56 +1300, Amos Jeffries wrote:
Well, we are on the countdown for 3.1.0.1
19 bugs and dropping.
What features are you folks thinking we should turn on by
default in 3.1?
My votes:
* IPv6
* error localization
* Null store (already on)
* connection pi
16 matches
Mail list logo