mlw wrote:
> 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)
Bug tracking software that doesn't use transactions and
referential integrity in a multiuser environment? Sounds like
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> If it was a sendmail issue, by all means, but it isn't so no :)
Both qmail and postfix radically outperform sendmail for large mailing
list delivery on identical hardware. It seems strange to me to say
that there is no sendmail issue when sendmai
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
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 probab
On Tue, 21 Aug 2001, 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..
>
> Solution..
>
> Is implementing yet another bugtool going to be the solution?
> Probably not. Do I want to go for number six
If it was a sendmail issue, by all means, but it isn't so no :)
On Tue, 21 Aug 2001, Vince Vielhaber wrote:
> On Tue, 21 Aug 2001, Marc G. Fournier wrote:
>
> >
> > Nope, but thanks for the offer ;)
>
> Pleeeze?
>
> You won't be sorry
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
Ian Lance Taylor <[EMAIL PROTECTED]> writes:
> 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 serve
> 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
> 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
On Tue, 21 Aug 2001, Marc G. Fournier wrote:
>
> Nope, but thanks for the offer ;)
Pleeeze?
You won't be sorry or disappointed!!
>
> On Tue, 21 Aug 2001, Vince Vielhaber wrote:
>
> > On Tue, 21 Aug 20
Nope, but thanks for the offer ;)
On Tue, 21 Aug 2001, Vince Vielhaber wrote:
> On Tue, 21 Aug 2001, Marc G. Fournier wrote:
>
> > On Tue, 21 Aug 2001, Lamar Owen wrote:
> >
> > > On Tuesday 21 August 2001 12:59, Serguei Mokhov wrote:
> > > > Looking at my message about the bug webpage and
> >
On Tue, 21 Aug 2001, Marc G. Fournier wrote:
> On Tue, 21 Aug 2001, Lamar Owen wrote:
>
> > 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 pos
"Marc G. Fournier" <[EMAIL PROTECTED]> writes:
> Huh? Two different machines altogether ...
Hmm. Maybe the problem is this:
$ nslookup -q=mx postgresql.org
Server: localhost
Address: 127.0.0.1
Non-authoritative answer:
postgresql.org preference = 0, mail exchanger = mail.postgresql.org
pos
Huh? Two different machines altogether ... but, I do have work to do once
the new server goes online ...
> nslookup postgresql.org
Server: localhost.hub.org
Address: 127.0.0.1
Name:postgresql.org
Address: 216.126.84.28
> nslookup webmail.postgresql.org
Server: localhost.hub.org
Addres
> > > > > 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 haven't heard t
Peter Eisentraut wrote:
>
> 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 us
Peter Eisentraut <[EMAIL PROTECTED]> writes:
> 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.
As long as locale has to be an initdb-time setting, a GUC var won't
help much.
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 workaroun
On Tue, 21 Aug 2001, Lamar Owen wrote:
> 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
>
> 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
> http://www.ca.postgresql.org/mh
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 bee
> 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 prominen
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 broadcast)--
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
http://www.ca.postgresql.org/mhonarc/pgsql-bugs/2
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: [HAC
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,
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
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 wa
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 clie
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 act
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
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
> applicatio
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 repo
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
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 report
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
> > > 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
-
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
> > 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
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
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 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
user.
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 any
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
> t
"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 runnin
> > 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
> 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
> b
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.
Looking
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 sta
> > 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 sy
"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
ma
> 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
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 u
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
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
> 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.
Hiroshi Inoue writes:
> 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
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.
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 accomo
> 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 the
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 ar
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
> oth
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 2001
> 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 follow
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.
S.
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
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 onl
> 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 hun
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 alre
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 th
> 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
k
> > > 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 us
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 alre
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 op
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".
- 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
On Tue, 21 Aug 2001, Lamar Owen wrote:
> 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
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
soluti
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
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, i
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 Mom
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 abou
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 someon
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, 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.
> 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 prob
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 _requi
> > 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? Se
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) user
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. Hopefull
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 b
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 ba
> > 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
On Tue, 21 Aug 2001, 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 partial
>
>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
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 de
> > 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 i
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.
--
> >
> >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 o
1 - 100 of 117 matches
Mail list logo
