At 09:39 AM 20-08-2001 -0700, Mikheev, Vadim wrote:
If it does then one of the things I'd use it for is to insert
unique data without having to lock the table or rollback on
failed insert (unique index still kept as a guarantee).
(Classic example how could be used SAVEPOINTs -:))
I guess so.
On Tue, Aug 21, 2001 at 10:00:50AM +0900, Tatsuo Ishii wrote:
I found some other things:
- why database encoding for new DB check 'createdb' script and not
CREATE DATABASE statement? (means client only encodings, like BIG5)?
Bug?
Oh, that must be a bug. Do yo want to take
On Tue, Aug 21, 2001 at 10:00:21AM +0900, Hiroshi Inoue wrote:
Karel Zak wrote:
I found some other things:
- ODBC -- here is some multibyte stuff too. Why ODBC code don't use
pg_wchar.h where is all defined? In odbc/multibyte.h is again defined
all encoding identificators.
Hi all,
I'm currently trying to develop a log analyzer for PostgreSQL logs and at
the first
stage I'm finding a little problem with the postgresql.conf option
log_timestamp.
The problem is that if this option is set to false we have no idea of when
the backend
is started:
DEBUG: database
On Tue, Aug 21, 2001 at 10:00:50AM +0900, Tatsuo Ishii wrote:
I found some other things:
- why database encoding for new DB check 'createdb' script and not
CREATE DATABASE statement? (means client only encodings, like BIG5)?
Bug?
Oh, that must be a bug. Do yo want
Tom Lane wrote:
Tatsuo Ishii [EMAIL PROTECTED] writes:
NOTICE: ctid (0,5) xmin 645188 xmax 645190 cmin 2 cmax 2
This is odd too, since xmax 0 or cmax 0 should never happen with
visible tuples, in my understanding.
That's what the docs presently say, but they're in error --- nonzero
If anyone was concerned about our bug database being visible and giving
the impression we don't fix any bugs, see this URL:
http://www.isthisthingon.org/nisca/postgres.html
Not only does it show the problems he had with PostgreSQL, he uses our
bug list as an example of how PostgreSQL
Thus spake Bruce Momjian
If anyone was concerned about our bug database being visible and giving
the impression we don't fix any bugs, see this URL:
http://www.isthisthingon.org/nisca/postgres.html
Jeez, Louise. Talk about a blaming the tools because you don't know
anything about
We better remove that web page soon:
http://www.ca.postgresql.org/bugs/bugs.php?2
Do we have any pages to alter the status of bugs, or assign them? There are
a number of bugs in the list that I know are fixed.
Philip
On Tue, 21 Aug 2001, Bruce Momjian wrote:
If anyone was concerned about our bug database being visible and giving
the impression we don't fix any bugs, see this URL:
http://www.isthisthingon.org/nisca/postgres.html
Not only does it show the problems he had with PostgreSQL, he uses
At 08:32 21/08/01 -0400, Vince Vielhaber wrote:
Yes but noone was interested in it. It's still there but you're really
the first to show interest in about a year.
That's good (and depressing); where are they?
Philip Warner
On Tue, 21 Aug 2001, Philip Warner wrote:
We better remove that web page soon:
http://www.ca.postgresql.org/bugs/bugs.php?2
Do we have any pages to alter the status of bugs, or assign them? There are
a number of bugs in the list that I know are fixed.
Yes but noone was
On Tue, 21 Aug 2001, Bruce Momjian wrote:
If anyone was concerned about our bug database being visible and giving
the impression we don't fix any bugs, see this URL:
http://www.isthisthingon.org/nisca/postgres.html
Not only does it show the problems he had with PostgreSQL, he uses
At 08:22 21/08/01 -0400, Vince Vielhaber wrote:
I removed the link to the page a few days ago. I guess I should disable
it as well. Woulda been a whole lot easier if the database was just
updated periodically.
I don't think this is a good solution. We really do need a list of bugs. We
Ok the functionality as well as the menu item are gone. You do realize
it's going to give the impression that we're trying to hide something,
don't you?
Uh, what choices do we have? Do we want to update that database, seeing
as only a small percentage of bug reports come in
On Tue, 21 Aug 2001, Bruce Momjian wrote:
On Tue, 21 Aug 2001, Bruce Momjian wrote:
If anyone was concerned about our bug database being visible and giving
the impression we don't fix any bugs, see this URL:
http://www.isthisthingon.org/nisca/postgres.html
Not only does
We could install the Postgres version of Bugzilla.
Yes, there's a version that runs on Postgres rather than MySQL.
That way we don't have to maintain the bug system.
Ok the functionality as well as the menu item are gone. You do realize
it's going to give the impression that we're trying to
On Tue, 21 Aug 2001, Bruce Momjian wrote:
If anyone was concerned about our bug database being visible and giving
the impression we don't fix any bugs, see this URL:
http://www.isthisthingon.org/nisca/postgres.html
Not only does it show the problems he had with PostgreSQL, he
It's up to the group to decide. If we have a database of bugs, I think
it has to be complete. I think a partial list is worse than no list at
all.
I disagree. Unless you are omniscient, we will only ever have a partial list.
Perhaps more importantly, the more common ones will be
On Tue, 21 Aug 2001, Colin 't Hart wrote:
We could install the Postgres version of Bugzilla.
Yes, there's a version that runs on Postgres rather than MySQL.
That way we don't have to maintain the bug system.
And how does it know when bugs are fixed?
Vince.
--
Philip Warner wrote:
I don't think this is a good solution. We really do need a list of bugs.
We
probably need to list status and the releases they apply to.
Bugzilla can do this -- it has the concept of a Milestone and a Version.
I don't think anybody but the most naieve (or biased) users
Can someone point me to a bug that is _not_ on the TODO list? If not,
what does a complete bug database do for us except list reported bugs
and possible workarounds.
Do you actually expect someone to go thru the 400+ items in the database
and compare them to the TODO list? Seems to
On Tuesday 21 August 2001 05:30, Andy wrote:
Where is the MX RPM ? I didn't see this in the 7.1.3 RPM, for RH 7.1 and
also Mdk 8.0. And by the way, it was asked when I tried to install the
PostgreSQL Python module. I know 7.1.2 RH 7.1 has this MX RPM.
The 7.1 DB-API 2.0 Python client
Bruce Momjian [EMAIL PROTECTED] writes:
We could try going the other way, attaching URL's to the TODO items so
people can get more information about an existing bug.
That might be worth doing, but I think it's mostly orthogonal to the
question of a bug database. The set of problems that
On Tue, 21 Aug 2001, Bruce Momjian wrote:
Yes, but we have to add items that don't come in through the database,
and mark them as done/duplicates if we want it to be useful.
Not necessarily. If someone discovers one that's not in the database
they'll add it. If it's already
How about we trial it, but with the understanding that bugs we fix will
be marked as such?
After all, every bug is given an ID, so whomever fixes the bug with that
ID should also mark it off.
Looking at the present situation, it seems we began a good idea, but
never really followed through with
On Tue, 21 Aug 2001, Tom Lane wrote:
Vince Vielhaber [EMAIL PROTECTED] writes:
That is the real question. Do we want to rely more heavily on a bug
database rather than the email lists? I haven't heard many say they
want that.
The database keeps track of it. When someone uses the
A web-based interface allows people to submit bug reports they might
otherwise not be able to report. Not everyone is able/willing to
sign-up to a mailing list, nor have newsfeed access.
The one we have (had) allows the reporting, but has the flaw of not
showing when something has been done
MySQL has to first add some features in order to have some bugs, don't they?
:-)
Some people crack me up in their opinions.. If it took him 6 hours to figure
out int8 then I'm not really interested in anything else he has to say...
Lord...
-Mitch
- Original Message -
From: Bruce
On Tue, 21 Aug 2001, Bruce Momjian wrote:
How about we trial it, but with the understanding that bugs we fix will
be marked as such?
After all, every bug is given an ID, so whomever fixes the bug with that
ID should also mark it off.
Looking at the present situation, it seems we
Yes, but we have to add items that don't come in through the database,
and mark them as done/duplicates if we want it to be useful.
Not necessarily. If someone discovers one that's not in the database
they'll add it. If it's already fixed it'll get closed out but will
still be in the
Vince Vielhaber [EMAIL PROTECTED] writes:
That is the real question. Do we want to rely more heavily on a bug
database rather than the email lists? I haven't heard many say they
want that.
The database keeps track of it. When someone uses the bugtool to
report a bug it's mailed to the
Bruce Momjian writes:
OK, what value does a bug database have over a TODO list?
The former is a database, the latter is a flat-text file. The former is
mult-user, the latter is single-user. You figure out the rest. ;-)
Seriously, IMHO a real bug database would be useful. A number of
- Original Message -
From: Bruce Momjian [EMAIL PROTECTED]
Sent: Tuesday, August 21, 2001 8:48 AM
On Tue, 21 Aug 2001, Bruce Momjian wrote:
Not only does it show the problems he had with PostgreSQL, he uses our
bug list as an example of how PostgreSQL isn't advancing or
Vince Vielhaber [EMAIL PROTECTED] writes:
Some of the discussions could go on for weeks. Are you saying that
wading thru a few hundred posts to find out what a solution was is
better than a quick searchable summary?
Given a threaded index, you aren't wading through a few hundred posts.
Hiroshi Inoue writes:
I would object even if there's such a way.
People in Japan have hardly noticed that the strange
behabior is due to the strange locale(LC_COLLATE).
I don't think we should design our systems in a way that inconveniences
many users because some users are using broken
On Tue, 21 Aug 2001, Bruce Momjian wrote:
Yes, but we have to add items that don't come in through the database,
and mark them as done/duplicates if we want it to be useful.
Not necessarily. If someone discovers one that's not in the database
they'll add it. If it's already fixed
Do you actually expect someone to go thru the 400+ items in the database
and compare them to the TODO list? Seems to me that's something the
maintainer of the TODO list would be doing. Can you point me to the form
that gets something on the TODO list that the average user can use?
yep:
lock tablename.colname.val=1
select count(*) from tablename where colname=1
If no rows, insert, else update.
(dunno if the locks would scale to a scenario with hundreds
of concurrent inserts - how many user locks max?).
I don't see problem here - just a few bytes in shmem for
key.
On Tue, 21 Aug 2001, Bruce Momjian wrote:
Can someone point me to a bug that is _not_ on the TODO list? If not,
what does a complete bug database do for us except list reported bugs
and possible workarounds.
Do you actually expect someone to go thru the 400+ items in the database
Tom Lane wrote:
Hannu Krosing [EMAIL PROTECTED] writes:
Tom Lane wrote:
That's what the docs presently say, but they're in error --- nonzero
xmax could represent a not-yet-committed deleting xact (or one that
did commit, but not in your snapshot); or it could be from a deleting
xact
It's up to the group to decide. If we have a database of bugs, I think
it has to be complete. I think a partial list is worse than no list at
all.
I disagree. Unless you are omniscient, we will only ever have a partial list.
Perhaps more importantly, the more common ones will be in the
That is the real question. Do we want to rely more heavily on a bug
database rather than the email lists? I haven't heard many say they
want that.
The database keeps track of it. When someone uses the bugtool to
report a bug it's mailed to the bugs list.
Yes, but we have to add
Hannu Krosing [EMAIL PROTECTED] writes:
Tom Lane wrote:
That's what the docs presently say, but they're in error --- nonzero
xmax could represent a not-yet-committed deleting xact (or one that
did commit, but not in your snapshot); or it could be from a deleting
xact that rolled back.
or
On Tue, 21 Aug 2001, Bruce Momjian wrote:
That is the real question. Do we want to rely more heavily on a bug
database rather than the email lists? I haven't heard many say they
want that.
The database keeps track of it. When someone uses the bugtool to
report a bug it's mailed
Philip Warner [EMAIL PROTECTED] writes:
Please reinstate the page, and allow some facility to edit them. I will try
to work through them *slowly* to verify they are reproducible/not
reproducible in 7.1.3 and in the current CVS, then mark them as fixed in
the appropriate release. Hopefully
On Tue, 21 Aug 2001, Bruce Momjian wrote:
Yes, but we have to add items that don't come in through the database,
and mark them as done/duplicates if we want it to be useful.
Not necessarily. If someone discovers one that's not in the database
they'll add it. If it's already fixed
Vince Vielhaber [EMAIL PROTECTED] writes:
Some of the discussions could go on for weeks. Are you saying that
wading thru a few hundred posts to find out what a solution was is
better than a quick searchable summary?
Given a threaded index, you aren't wading through a few hundred posts.
On Tue, Aug 21, 2001 at 09:51:29AM -0400, Bruce Momjian wrote:
It's up to the group to decide. If we have a database of bugs, I think
it has to be complete. I think a partial list is worse than no list at
all.
I disagree. Unless you are omniscient, we will only ever have a
On Tuesday 21 August 2001 11:59, Vince Vielhaber wrote:
On Tue, 21 Aug 2001, Lamar Owen wrote:
Red Hat makes mission-critical use of bugzilla running on Oracle. See
bugzilla.redhat.com. And ask the Red Hat people on these lists their
opinions of bugzilla.
What who thinks of what has
Hi All,
Looking at my message about the bug webpage and
some other posts, I see that it was delayed for
about 2h and a half. Some of the post were
delayed for days... Why is that? Looks like
the list has problems of some sort which cause
these irregular delays.
Just an annoying observation.
gcc -g -Wall -Wmissing-prototypes -Wmissing-declarations -I../../../src/include
-c -o auth.o auth.c
In file included from auth.c:22:
/usr/include/sys/ucred.h:50: `NGROUPS' undeclared here (not in a function)
% uname -a
FreeBSD xor 4.3-STABLE FreeBSD 4.3-STABLE #2: Thu May 24 14:05:34 MSD
Regarding the licencing of the code, I always release my code
under GPL, which is the licence I prefer, but my code in the
backend is obviously released under the original postgres
licence. Since the module is loaded dynamically and not linked
into the backend I don't see a problem here.
On Tue, 21 Aug 2001, Lamar Owen wrote:
[...]
What who thinks of what has actually become irrelevant. The following
is clear:
o No tool will replace the mailing lists
o The mailing lists are where discussion will be held
o Many/most maintainers have no desire to update
Hi;
I am reverse engineering a PostgreSQL database by querying catalog
tables. I have run into a problem where I can not determine the exact
info used in i.e. the CREATE TABLE statement. For example; how to
determine the exact precision/length and scale used in a NUMERIC(p,s)
column def.
Peter Harvey [EMAIL PROTECTED] writes:
Is this information availible somewhere in the catalog tables?
Yes, in the atttypmod column of pg_attribute.
I'd recommend looking at psql's \d commands (describe.c), or at
pg_dump, to see the approved way to retrieve catalog info. Those
are kept up to
Justin Clift [EMAIL PROTECTED] writes:
After all, every bug is given an ID, so whomever fixes the bug with that
ID should also mark it off.
Oh? I've never seen a bug ID. Certainly the traffic in pgsql-bugs
doesn't show any such thing.
This isn't going to happen unless there's some fairly
Gilles DAROLD writes:
Is it possible to have it into the last line as we have the information of
the database
shutdown timestamp in the first line ?
We not just turn time stamping on?
Also, an other question is why using timestamp into the other log instead of
the value
of time in
I know I am not on the kernel team, but I have been a software developer for
almost 20 years. ;-)
A bug database is a useful tool IF it has been setup to be so. If it is a
bare bones repository for bug reports it will not work. People won't use it.
A good bug database, i.e. one which will be
Ross J. Reedstrom [EMAIL PROTECTED] writes:
The project is outgrowing its infrastructure.
Perhaps so. I think what's *really* needed here is someone who is
willing to take responsibility for maintaining a bug database, ie,
removing cruft (non-bug messages), making sure that old bugs are
marked
I would object even if there's such a way.
People in Japan have hardly noticed that the strange
behabior is due to the strange locale(LC_COLLATE).
I don't think we should design our systems in a way that
inconveniences
many users because some users are using broken operating systems.
On Tuesday 21 August 2001 11:06, Mitch Vincent wrote:
Some people crack me up in their opinions.. If it took him 6 hours to
figure out int8 then I'm not really interested in anything else he has to
say... Lord...
Hmmm...
Let's look at the guy's bulleted list.
The first item he can't stand
Face it, everything has locale support these day. PostgreSQL is one
of
the few packages that even has it as an option to turn it off. Users
of
binary packages of PostgreSQL are all invariably faced with locale
features. So it's not like sudden unasked-for locale support is going
to
be a
How about we trial it, but with the understanding that bugs we fix will
be marked as such?
After all, every bug is given an ID, so whomever fixes the bug with that
ID should also mark it off.
Looking at the present situation, it seems we began a good idea, but
never really followed
If your solution is short-lived, your change would be not
only useless but also harmful. So I expect locale-aware
people to confirm that we are in the right direction.
I am a bit confused here. We have tinkered with LIKE indexing at
least a
year. Now that a solution is found that
Mikheev, Vadim [EMAIL PROTECTED] writes:
(dunno if the locks would scale to a scenario with hundreds
of concurrent inserts - how many user locks max?).
I don't see problem here - just a few bytes in shmem for
key. Auxiliary table would keep refcounters for keys.
I think that running out of
On Tuesday 21 August 2001 12:59, Serguei Mokhov wrote:
Looking at my message about the bug webpage and
some other posts, I see that it was delayed for
about 2h and a half. Some of the post were
delayed for days... Why is that? Looks like
the list has problems of some sort which cause
these
Zeugswetter Andreas SB SD writes:
I am a bit confused here. We have tinkered with LIKE indexing at
least a
year. Now that a solution is found that *works*, it is claimed that
it is
harmful because LIKE was doing the wrong thing in the first place.
OTOH,
I have not seen anyone
I need to manage a large number of various databases, some assigned to
different people, others only internal to the company I work for. I would
like to be able to update the pg_hba.conf file from inside a psql console
connection but only if I an connected to template1 AND the main postgres
Has anyone thought of using Bugzilla? (It is MySQL based, of course) but it
might answer the bug database issues. (If you guys want a bug database)
RedHat has a version which can use Oracle, but it seems there is a file:
ftp://people.redhat.com/dkl/pgzilla-latest.tar.gz that my be interesting.
I don't see problem here - just a few bytes in shmem for
key. Auxiliary table would keep refcounters for keys.
I think that running out of shmem *would* be a problem for such a
facility. We have a hard enough time now sizing the lock table for
Auxiliary table would have fixed size and
On Tuesday 21 August 2001 12:47, Bruce Momjian wrote:
Justin Clift [EMAIL PROTECTED] writes:
After all, every bug is given an ID, so whomever fixes the bug with
that ID should also mark it off.
That would be pretty cool, using the mailing list archives as an
_answer_ to the bug report.
I disagree. Unless you are omniscient, we will only ever have a partial
list.
but there wasn't enough interest for someone to take on
the maintenance.
We need someone willing to be a kibo. Or is that too arcane a reference?
--
Lamar Owen
WGCR Internet Radio
1 Peter 4:11
Vince Vielhaber wrote:
What who thinks of what has actually become irrelevant. The following
is clear:
o No tool will replace the mailing lists
o The mailing lists are where discussion will be held
o Many/most maintainers have no desire to update bug reports
If
Lamar Owen [EMAIL PROTECTED] writes:
The best thing to do is simply to expect propagation delay.
Actually, I just sent a gripe off to Marc about this. I've been
noticing large and variable propagation delay for a few months now,
but I just today realized that the problem is entirely local to
Lamar Owen [EMAIL PROTECTED] writes:
Let's look at the guy's bulleted list.
The first item he can't stand is that you can't add a column after any
arbitrary column, that it goes at the end. Well, this is really
clueless, as you order the columns when you SELECT or when the
application
Tatsuo Ishii writes:
Tatsuo Ishii writes:
I wouldn't object it if there is a way to disable locale support.
export LC_ALL=C
It's not a solution. My point is people should not be troubled by the
useless feature (at least for Japanese) even if they set their locale
other than C.
If
Bruce Momjian [EMAIL PROTECTED] writes:
We could try going the other way, attaching URL's to the TODO items so
people can get more information about an existing bug.
That might be worth doing, but I think it's mostly orthogonal to the
question of a bug database. The set of problems that are
Justin Clift [EMAIL PROTECTED] writes:
After all, every bug is given an ID, so whomever fixes the bug with that
ID should also mark it off.
Oh? I've never seen a bug ID. Certainly the traffic in pgsql-bugs
doesn't show any such thing.
This isn't going to happen unless there's some
On Tuesday 21 August 2001 11:11, Bruce Momjian wrote:
OK, what value does a bug database have over a TODO list?
The TODO list isn't just a list of bugs that need fixing.
A bug database is just that -- a list of bugs in existing features. While
Requests of Enhancements certainly can be
Bruce Momjian [EMAIL PROTECTED] writes:
OK, what value does a bug database have over a TODO list?
A TODO list is forward-looking. Many of the entries in a bug database
would be backward-looking (already fixed). We shouldn't try to make
either one serve the purpose of the other.
Lamar Owen [EMAIL PROTECTED] writes:
Mailing lists don't scale well to large numbers of subscribers. I see this
delay constantly,on multiple lists. The bigger the list gets, the slower the
list gets (and the more loaded the server gets, right Marc? :-)).
Note that the postgresql.org mail
Tom Lane [EMAIL PROTECTED] writes:
All the delay seems to be in transferring the message from
postgresql.org to webmail.postgresql.org ... which are the same
machine, or at least the same IP address. What's up with that?
You are seeing sendmail's poorly designed queuing behaviour in action.
Hi,
fortunately the problems with a malfunctioning client during
the authentication don't cause the v7.2 postmaster to hang
any more (thanks to Peter and Tom). The client authentication
is moved into the forked off process.
Now one little problem remains. If a bogus
Peter Eisentraut wrote:
We've had some problem reports that the current practice of initdb
assigning to the postgres user the same usesysid as the user id of the
Unix user running initdb has caused some clashes.
...
I think the simplest fix would be to assign a fixed usesysid of 1.
I was
On Tue, 21 Aug 2001, Lamar Owen wrote:
I disagree. Unless you are omniscient, we will only ever have a partial
list.
but there wasn't enough interest for someone to take on
the maintenance.
We need someone willing to be a kibo. Or is that too arcane a reference?
Gotta admit, I
On 21 Aug 2001, Ian Lance Taylor wrote:
Lamar Owen [EMAIL PROTECTED] writes:
Mailing lists don't scale well to large numbers of subscribers. I see this
delay constantly,on multiple lists. The bigger the list gets, the slower the
list gets (and the more loaded the server gets, right
I've had great luck with Postfix as well.
-Mitch
- Original Message -
From: Ian Lance Taylor [EMAIL PROTECTED]
To: Lamar Owen [EMAIL PROTECTED]
Cc: Serguei Mokhov [EMAIL PROTECTED]; PostgreSQL Hackers
[EMAIL PROTECTED]
Sent: Tuesday, August 21, 2001 4:24 PM
Subject: [HACKERS] Re: List
Hi all,
Here is a first draft generated by a log analyzer for postgres I've wrote today:
http://www.samse.fr/GPL/log_report/
In all this html report there is what I'm able to extract minus the statistics.
I need to know what people want to see reported to have a powerfull log analyzer,
I
Gilles DAROLD wrote:
Hi all,
Here is a first draft generated by a log analyzer for postgres I've wrote today:
http://www.samse.fr/GPL/log_report/
In all this html report there is what I'm able to extract minus the statistics.
I need to know what people want to see reported to
Bruce Momjian writes:
Can someone point me to a bug that is _not_ on the TODO list?
Just looking through pgsql-bugs of the last two weeks, the following all
look reasonable.
http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00088.html
Zeugswetter Andreas SB SD writes:
What makes you so opposed to a GUC for disabling locale support ?
Nothing. It may in fact be the best solution.
--
Peter Eisentraut [EMAIL PROTECTED] http://funkturm.homeip.net/~peter
---(end of
I see no evidence that this guy wants to learn about or contribute to
Postgres development at all; he's just looking for things to rag on.
(And not even doing very well at that --- I could name ten worse
problems than these without taking a breath...) The TODO list is
mentioned prominently
Jan Wieck [EMAIL PROTECTED] writes:
Now one little problem remains. If a bogus client causes a
child to hang before becoming a real backend, this child is
in the backend list of the postmaster, but has all signals
blocked. Thus, preventing the postmaster from beeing
Bruce Momjian writes:
Can someone point me to a bug that is _not_ on the TODO list?
Just looking through pgsql-bugs of the last two weeks, the following all
look reasonable.
http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2001-08/msg00088.html
In the seemingly hundreds of thousands of messages on the bug database
topic I think I've come up with the following..
Needs
---
easy reporting of bugs - sent to bugs list
easy lookup of previous bugs
summary of fix or
Vince Vielhaber [EMAIL PROTECTED] writes:
Now some history.. Over the last couple of years we've tried a
number (5 I think) of bug tracking packages. Either Marc or me
or both have had to learn it, install it, get it going and the
result has been the same - the maintainers don't want to
At 20:08 21/08/01 -0400, Vince Vielhaber wrote:
In the seemingly hundreds of thousands of messages on the bug database
topic I think I've come up with the following..
Your first pass needs to have a simple mail and web based ssystem for
developers to at least close bugs. The CC idea is probably
Vince Vielhaber [EMAIL PROTECTED] writes:
Needs
easy reporting of bugs - sent to bugs list
easy lookup of previous bugs
summary of fix or workaround
detail of fix or work around
little to no intervention of
developers
ability of developer to add
comments
That should sum it up.
If people set their locale to something other than C they have evidently
judged that locale is not useless. Why would they set it otherwise?
As Hiroshi pointed out, the broken thing is the LC_COLLATE, other
things in the local are working.
I
don't think hiding away a feature because you
1 - 100 of 113 matches
Mail list logo
