Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-22 Thread Jim Nasby

On Aug 17, 2006, at 3:40 PM, Alvaro Herrera wrote:
The searching capabilities in debbugs are, well, non-existent,  
which is

a real problem in my mind.


Well, we can set up our own indexing, like Oleg and Teodor have  
done in

http://www.pgsql.ru/


That seems like quite a hack for something that should be built-in...  
it also severely limits searchability. For example, it's very  
important to be able to do things like ignore closed bugs when you're  
searching.

--
Jim C. Nasby, Sr. Engineering Consultant  [EMAIL PROTECTED]
Pervasive Software  http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf   cell: 512-569-9461



---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-22 Thread Marko Kreen

On 8/17/06, Peter Eisentraut [EMAIL PROTECTED] wrote:

Alvaro Herrera wrote:
 Have you tried to use debbugs?

If you can find up-to-date source code for debbugs, we might continue
that line of thought.


http://www.mail-archive.com/debian-debbugs@lists.debian.org/msg01266.html

( bzr get http://bugs.debian.org/debbugs-source/mainline/ )


The searching capabilities in debbugs are, well, non-existent, which is
a real problem in my mind.


As its mail based, it delegates searching to mail archive search tools.

--
marko

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-22 Thread Andrew Dunstan

Marko Kreen wrote:

On 8/17/06, Peter Eisentraut [EMAIL PROTECTED] wrote:

Alvaro Herrera wrote:
 Have you tried to use debbugs?

If you can find up-to-date source code for debbugs, we might continue
that line of thought.


http://www.mail-archive.com/debian-debbugs@lists.debian.org/msg01266.html

( bzr get http://bugs.debian.org/debbugs-source/mainline/ )


The searching capabilities in debbugs are, well, non-existent, which is
a real problem in my mind.


As its mail based, it delegates searching to mail archive search tools.



Why are we even dabating a system when it has been reported that the 
authors believe it is completely unsuitable for use by the PostgreSQL 
project?


cheers

andrew

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-22 Thread Josh Berkus
Andrew,

 Why are we even dabating a system when it has been reported that the
 authors believe it is completely unsuitable for use by the PostgreSQL
 project?

Not *completely*.  More that it would take a couple dozen hours of work to 
make it good for us, and the resulting version then couldn't be synched 
with the Debian version.

Mind you, it would take an equal amount of time to add an e-mail-comment 
interface to Bugzilla, but BZ would then probably accept the patch.

-- 
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-19 Thread Gregory Stark
Josh Berkus josh@agliodbs.com writes:

 On the other hand, a lot of my personal dislike of BugZilla seems to be 
 based on being forced to use old versions.   A lot of the stuff I hate 
 about it has been fixed in the current version.

Does that include it being basically a web-only interface? 

I'm listed on various mozilla bugs and occasionally get notifications of
updates but I can't reply to those notifications and I'm not about to fire up
a browser and log in and search for the bug just to add comments.

I expect if you set up a web-based interface it won't be a matter of people
digging in heels so much as just being indifferent to it. And like most
projects the bugs will just accumulate and not get feedback.

Incidentally, does it also fix the issue with the database schema where the
entire set of comments is stored in a single field of a single record and so
when two people comment on a bug at the same time one stomps on the others
changes?

-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-19 Thread Joshua D. Drake


I expect if you set up a web-based interface it won't be a matter of people
digging in heels so much as just being indifferent to it. And like most
projects the bugs will just accumulate and not get feedback.

  


And which projects would these be? Oddly enough it might surprise you 
that the web has really matured.

All kinds of people use it now. You should really check it out.

;)

Sincerely,

Joshua D. Drake




Incidentally, does it also fix the issue with the database schema where the
entire set of comments is stored in a single field of a single record and so
when two people comment on a bug at the same time one stomps on the others
changes?

  



---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-19 Thread Tom Lane
Gregory Stark [EMAIL PROTECTED] writes:
 I'm listed on various mozilla bugs and occasionally get notifications of
 updates but I can't reply to those notifications and I'm not about to fire up
 a browser and log in and search for the bug just to add comments.

It's really not that painful: every email bugzilla sends includes the
URL of the bug page.  It's one click to visit the page, assuming your
mail and web tools are well enough integrated that you can readily visit
a URL given in text email.  (If not, consider joining the 21st century
;-))

I think actually the weak spot of bugzilla for our purposes will be the
problem of transferring original email reports into BZ entries.  The
volunteer(s) who do that work are probably going to want a tool better
adapted to that purpose than the standard BZ bug entry page ... but
we'll likely want to do some customization work on our BZ anyway, so
I don't see that as a fatal objection.

The bottom line here is that there will not be any tool that is perfect
for our purposes out-of-the-box.  Well, it's all open source, we can
scratch our own itch.  What we need more than any specific tool is a
commitment from someone to put effort into adapting the tool to our
needs.

(Given that reality, the quality of the tool's existing source code
needs to figure strongly in our decision.  If BZ is still as ugly
as Josh remembers it being, that'd be a strike against it.)

regards, tom lane

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-19 Thread Bruce Momjian
Gregory Stark wrote:
 Josh Berkus josh@agliodbs.com writes:
 
  On the other hand, a lot of my personal dislike of BugZilla seems to be 
  based on being forced to use old versions.   A lot of the stuff I hate 
  about it has been fixed in the current version.
 
 Does that include it being basically a web-only interface? 
 
 I'm listed on various mozilla bugs and occasionally get notifications of
 updates but I can't reply to those notifications and I'm not about to fire up
 a browser and log in and search for the bug just to add comments.
 
 I expect if you set up a web-based interface it won't be a matter of people
 digging in heels so much as just being indifferent to it. And like most
 projects the bugs will just accumulate and not get feedback.

Yea, I'm planning on ignoring the bug tracker until we decide I can stop
doing what I do already.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-19 Thread Andrew Dunstan



Tom Lane wrote:

Gregory Stark [EMAIL PROTECTED] writes:
  

I'm listed on various mozilla bugs and occasionally get notifications of
updates but I can't reply to those notifications and I'm not about to fire up
a browser and log in and search for the bug just to add comments.



It's really not that painful: every email bugzilla sends includes the
URL of the bug page.  It's one click to visit the page, assuming your
mail and web tools are well enough integrated that you can readily visit
a URL given in text email.  (If not, consider joining the 21st century
;-))

I think actually the weak spot of bugzilla for our purposes will be the
problem of transferring original email reports into BZ entries.  The
volunteer(s) who do that work are probably going to want a tool better
adapted to that purpose than the standard BZ bug entry page ... but
we'll likely want to do some customization work on our BZ anyway, so
I don't see that as a fatal objection.

The bottom line here is that there will not be any tool that is perfect
for our purposes out-of-the-box.  Well, it's all open source, we can
scratch our own itch.  What we need more than any specific tool is a
commitment from someone to put effort into adapting the tool to our
needs.

(Given that reality, the quality of the tool's existing source code
needs to figure strongly in our decision.  If BZ is still as ugly
as Josh remembers it being, that'd be a strike against it.)


  


It is a heck of a lot better then it was. For example, presentation 
logic is largely factored out and handed off to TT templates. Personally 
I'd like to see the SQL factored out too, but Bugzilla is hardly unique 
in having SQL littered across the code. Honestly, this is not your 
father's bugzilla. BTW, Josh's memory is of the 1.x series. The 2.x 
series is now at 2.22. The code has move a very long way.


There are also tools for email interaction, although they might need to 
be beefed up for the likes of some 20th century dwellers :-)


I will check about Greg's complaint about race conditions in updating 
comments. My initial impression is that this is no longer so, but I will 
get a definite answer.


We certainly have enough perl-heads on our community that we can surely 
make it do what we want with little difficulty.


Oh, it can also import some XML too. The DTD is in the source.

cheers

andrew

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-19 Thread Andrew Dunstan


I wrote:



I will check about Greg's complaint about race conditions in updating 
comments. My initial impression is that this is no longer so, but I 
will get a definite answer.





My impression was correct. Each comment on a bug gets its own row, 
marked by bug-id, commenter-id and timestamp.


BTW, there are undoubtedly some infelicities in the schema, but it's not 
too bad, and the way the bugzilla code works there is no danger of one 
underlying DB platform getting out of synch, as they are all generated 
from a single abstract schema.


cheers

andrew


---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-18 Thread Martijn van Oosterhout
On Thu, Aug 17, 2006 at 08:20:22PM -0400, Tom Lane wrote:
 Alvaro Herrera [EMAIL PROTECTED] writes:
  Have you tried to use debbugs?  I agree with Greg Stark that it's a
  better fit for our current procedure, while enabling better
  traceability.
 
 The principal strike against debbugs seems to be that the source code is
 not readily available and/or isn't updated regularly.  If we could get
 current sources we'd probably end up maintaining our own fork ... OTOH,
 given all the enthusiasm being expressed in this thread, somebody would
 volunteer to do that no?

Well, actually, you can get the currently running source whenever you
like:

http://bugs.debian.org/debbugs-source/

I got that from one of the bugs listed against debbugs:

http://bugs.debian.org/222077

The problem is that there is no recently packaged version that one can
just quickly install somewhere.

 Other than that not-small problem, I agree that debbugs seems like an
 excellent fit to our existing habits.

Yeah, debbugs is a really good fit here, like for Debian, because of
the overwhelming prevalence of email correspondence compared to any
other kind of communication. If we all used forums ofcourse, debbugs
would suck :)

Have a nice day,
-- 
Martijn van Oosterhout   kleptog@svana.org   http://svana.org/kleptog/
 From each according to his ability. To each according to his ability to 
 litigate.


signature.asc
Description: Digital signature


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-18 Thread Andrew Dunstan

Tom Lane wrote:

Alvaro Herrera [EMAIL PROTECTED] writes:
  

Have you tried to use debbugs?  I agree with Greg Stark that it's a
better fit for our current procedure, while enabling better
traceability.



The principal strike against debbugs seems to be that the source code is
not readily available and/or isn't updated regularly.  If we could get
current sources we'd probably end up maintaining our own fork ... OTOH,
given all the enthusiasm being expressed in this thread, somebody would
volunteer to do that no?

Other than that not-small problem, I agree that debbugs seems like an
excellent fit to our existing habits.


  


Well, the enthusiasm was for use, not for maintaining a fork :-)

I had a brief look at the code (literally less than 5 minutes). The good 
news is that it is admirably small. A fork isn't a bad idea, though, 
especially as a pgfoundry project. I can think of several excellent 
candidates for such a project (no names, no pack drill) ;-)


I should mention that it's a perl app.

cheers

andrew


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-18 Thread Josh Berkus
All,

I chatted some with some of the Debian folks who maintain Debbugs.  They 
thought it would take a significant amount of work to adapt it to 
PostgreSQL, in addition to the obvious needs to improve the web interface.

RT has some significant short comings for our project such as not having 
good support for tying bugs to versions etc.   As people have pointed out, 
it's a Request Tracker, not necessarily a Bug Tracker.

On the other hand, a lot of my personal dislike of BugZilla seems to be 
based on being forced to use old versions.   A lot of the stuff I hate 
about it has been fixed in the current version.

So, the question is whether any of our biggest bug-fixers would dig in 
their heels and scream No! if we gave BugZilla a try.   Comments?

-- 
--Josh

Josh Berkus
PostgreSQL @ Sun
San Francisco

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-18 Thread Joshua D. Drake


So, the question is whether any of our biggest bug-fixers would dig in 
their heels and scream No! if we gave BugZilla a try.   Comments?


  


I could have this setup this weekend should we vote YES :)

Joshua D. Drake




---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-17 Thread Bruce Momjian

Let me add that most entries that illict a quick patch or TODO item do
not come in through the bugs list, but are rather problems people post
to ther lists, or are the result of discussions.

---

Gregory Stark wrote:
 Andrew Dunstan [EMAIL PROTECTED] writes:
 
  What we are talking about here is bug triage. 
 
 Really? We have a problem with too many bug reports and need a tool to help
 triage them? That's the first I've heard of that.
 
 Think about what tasks you do now and what tool would make it easier. Don't
 try to invent problems to solve.
 
 The Debian system would be basically zero operational change. pgsql-bugs would
 continue to exist exactly as it does now except it would go through debbugs.
 Any message there would open a bug report. Anyone responding to say that's
 not a bug would just include the magic phrase to close the bug report too.
 
 Anyone responding with questions or data would just respond as normal. The net
 result would be exactly as it is now except that there would be a tool to view
 what bugs are still open and look at all the data accumulated on that bug. And
 you could look back at old bugs to see what version they were fixed in and
 what the bug looked like to see if it matched the problem a user is having.
 
 In short, it's just a tool to solve a problem we actually have (having a
 convenient archive of data about current and past bugs) without inventing
 problems to solve with extra process that we aren't already doing anyways.
 
 RT can be set up similarly but I'm not sure how much work it would take to
 make it as seamless. Debbugs has the advantage of working that way pretty much
 out of the box.
 
 
 -- 
   Gregory Stark
   EnterpriseDB  http://www.enterprisedb.com

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-17 Thread Josh Berkus

Greg,


In short, it's just a tool to solve a problem we actually have (having a
convenient archive of data about current and past bugs) without inventing
problems to solve with extra process that we aren't already doing anyways.

RT can be set up similarly but I'm not sure how much work it would take to
make it as seamless. Debbugs has the advantage of working that way pretty much
out of the box.


Debbugs would be good too.  I'll quiz the Debian folks here at the 
conference about what issues there are with the system.


FWIW, MySQL is pretty proud of their bug tracker, and Marten offered to 
open source it for us.  ;-)


--Josh Berkus

---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-17 Thread Tino Wildenhain

Josh Berkus schrieb:

Greg,


In short, it's just a tool to solve a problem we actually have (having a
convenient archive of data about current and past bugs) without inventing
problems to solve with extra process that we aren't already doing 
anyways.


RT can be set up similarly but I'm not sure how much work it would 
take to
make it as seamless. Debbugs has the advantage of working that way 
pretty much

out of the box.


Debbugs would be good too.  I'll quiz the Debian folks here at the 
conference about what issues there are with the system.


FWIW, MySQL is pretty proud of their bug tracker, and Marten offered to 
open source it for us.  ;-)


What is wrong with for example trac? (trac.edgewall.com) which actually
runs on postgres just fine...

Regards
Tino

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-17 Thread Magnus Hagander
 Well, you need to get some agreement on what the bug tracker 
 is for. Is
 it:
 
 a) a front-end to deal with complaints and bugs people have. 
 Is it something you expect end users to look at? This is how 
 Debian uses its bug-tracker, to make sure issues people bring 
 up don't get lost. You can always close the bug if it isn't a 
 real bug.

If we ask to take all complains, questions and bugs through a
bugtracker, then it's not a bugtracker. It's more of an anything goes
tracker, that usually ends up being a web based forum (with mail links)
without all the features that makes a web based forum at all usable.
(And I still think mailinglists are a lot more usable then a web based
forum that *does* have a lot of functionality) This is what IMHO you see
with a *lot* of OSS projects that use bugzilla or whatever. A bazillion
bugs that aren't bugs but discussions or questions etc. Can't speak
about the debian example, haven't checked theirs out.

We already have our mailinglist archives dealing with this. I really
can't see why we'd want to duplicate that and archive things in one more
place.


 Or:
 
 b) a private bug database only used by -hackers to track 
 known outstanding bugs and patches.

This, however, I would find very useful - both as a -hacker and as a
user. The point is that only confirmed things should be in there, so
only confirmed things should be returned on searches and whatevr.
(private not as in not visible to the public, but private as in
write-controlled)

As a user/admin/whatever, just listing all bugs affecting an
installation (8.0 branch after 8.0.4 for example) so I can evaluate if
I need to upgrade is a *very good* thing to be able to do. I realise
this adds a bit of overhead for the people doing commits, but it should
be possible to integrate that to a point where the overhead is
minimized. And it would be a big win.

As a -hacker, not needing to keep my own mailbox format or textfile
format bugtracker, and being able to easily find something that would
list all communications about a certain bug (*with* links to the
archives, where the actual information would still be) would definitly
be a win. 
Tom seems to be able to remember everything in his head and whip out the
old commit messages in no time, but I certainly can't ;-)


 If you want the latter, the approach would be to keep 
 pgsql-bugs and when a real issue comes up, bounce it to the 
 bug tracker. Any subsequent email discussion should then get 
 logged in the bug report.

IMHO, that's the best solution. Except the email discussion lives just
fine in the archives, and should be linked back into the tracker if
possible instead of copied there.

There's also the possibility of
c)
just using a bugtracker style interface as a presentation method over
whatever we have now. All our mails go into the archives. If we make
sure that all mails about a certain bug are flagged with that bug id
(easy enough if it's submitted through the bugs form, I'm sure there can
be some voodoo done in majordomo to have it send actual posts to the
lists through a script that would do a similar thing), then a tool could
fairly easy crawl the archives and pick up all emails related to that
bug, and present them separatly. Then if we can convince the committers
to always include the bug id when a commit is done for a bug, we'd have
the commit messages in the tracker as well... You'd still need someone
to fill out metadata like versions affected if we want that, but the
effort on the main developers would pretty much just be to remember to
keep the bug id around.


//Magnus

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-17 Thread Magnus Hagander
  I'm not sure I follow this, since currently anyone can 
 email the bugs 
  list or use the bugs - email form from the website.  Are 
 you looking 
  to increase the barrier for bug reporting?
 
 Any garbage (ie. spam) is generally filtered before it hits 
 the -bugs list itself

Spam: Yes.
Non-bug-reports: Absolutely not.

The majority of things on -bugs are *not* bug reports, from what I can
tell...

//Magnus

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-17 Thread Jim C. Nasby
On Thu, Aug 17, 2006 at 06:48:54PM +0200, Magnus Hagander wrote:
 This, however, I would find very useful - both as a -hacker and as a
 user. The point is that only confirmed things should be in there, so
 only confirmed things should be returned on searches and whatevr.
 (private not as in not visible to the public, but private as in
 write-controlled)

I've yet to see a bug tracker that doesn't make it trivial to identify
bugs that were marked as invalid (ie: not a real bug). The only
difference is that you actually have to mark them as such. Given the
fairly low volume of non-bugs that come in through the web form, I don't
think marking them will be a big issue (and as I mentioned previously,
it's something that doesn't have to be done by anyone who's a
committer). In fact, having such a system would probably save committers
time, because they could look only at bugs that had been confirmed as
valid by someone else. Right now, every time a non-bug gets filed dozens
of people end up reading the report before they hit delete.
-- 
Jim C. Nasby, Sr. Engineering Consultant  [EMAIL PROTECTED]
Pervasive Software  http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf   cell: 512-569-9461

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-17 Thread Bruce Momjian
Magnus Hagander wrote:
   I'm not sure I follow this, since currently anyone can 
  email the bugs 
   list or use the bugs - email form from the website.  Are 
  you looking 
   to increase the barrier for bug reporting?
  
  Any garbage (ie. spam) is generally filtered before it hits 
  the -bugs list itself
 
 Spam: Yes.
 Non-bug-reports: Absolutely not.
 
 The majority of things on -bugs are *not* bug reports, from what I can
 tell...

And many bugs appear on other lists, so again, it isn't just that the
bugs list isn't just bugs, but that bugs appear elsewhere.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-17 Thread Magnus Hagander
 These days I doubt there's anyone around the project who 
 refuses to use a web browser at all.  However, I still 
 personally find it much more convenient to read and respond 
 to mailing-list postings than to have to go and visit random 
 web pages to find out if there's something I need to know 
 about.  So my current take on this would be that the bug 
 tracker would have to have a reasonable output email 
 capability, but I'd not necessarily insist on being able to 
 input to it by mail.  Red Hat's present bugzilla system 
 could be described that way --- and while I can't say I'm in 
 love with it, I can deal with it.

Doesn't bugzilla insist on sending you the complete bug every time? Or
am I confusing it with the gforge/pgfoundry trackers? If so, then it's a
really bad idea, IMHO, since it sends new copies out all the time...


 Now the other side of the coin is that people are used to 
 being able to email problem reports to pgsql-bugs, and that's 
 not going to stop anytime soon.  If you don't mind having a 
 bug tracker that is clueless about some fair-size fraction of 
 what is going on, then you can set up a system that is 
 impervious to email input.  Just don't expect people to trust 
 it very far.

Whatever system is used (if one is), there definitly needs to be some
people looking over what comes in on the mailinglists (or on IRC, for
that matter) and pipe it off to the tracker in case it's not already
there. Unless we want to force everybody to use *just* a web interface
(which would be a horrible idea, btw), we won't get 100% coverage.

(btw, istm that people email at least as many bugs directly to -hackers,
or to -general or whatever, because the end user *does not know* when
it's a bug from when it's a misconfiguration, or misunderstanding of the
issue or whatnot)

//Magnus

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-17 Thread Magnus Hagander
  This, however, I would find very useful - both as a -hacker 
 and as a 
  user. The point is that only confirmed things should be in 
 there, so 
  only confirmed things should be returned on searches and whatevr.
  (private not as in not visible to the public, but private as in
  write-controlled)
 
 I've yet to see a bug tracker that doesn't make it trivial to 
 identify bugs that were marked as invalid (ie: not a real 
 bug). The only difference is that you actually have to mark 
 them as such. Given the fairly low volume of non-bugs that 
 come in through the web form, I don't think marking them will 
 be a big issue (and as I mentioned previously, it's something 
 that doesn't have to be done by anyone who's a committer). In 
 fact, having such a system would probably save committers 
 time, because they could look only at bugs that had been 
 confirmed as valid by someone else. Right now, every time a 
 non-bug gets filed dozens of people end up reading the report 
 before they hit delete.

Well, if it's invalid, it shouldn't be in there. But I guess you could
just go ahead and delete it at that point - but it's work that someone
has to do.

But when I look at a lot of OSS projects out there, I see hundreds (if
not thousands or tens of thousands for large projects) of bugs that are
just dangling. That likely aren't bugs, but they are listed as such.
Could definitly be that it's just that the system isn't maintained
properly, but if so many others have failed, there's definitly a
nontrivial risk that we would fail as well.

//Magnus

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-17 Thread Kenneth Marshall
On Wed, Aug 16, 2006 at 06:52:21AM +0200, Peter Eisentraut wrote:
 Tom Lane wrote:
  that the bug tracker would have to have a reasonable output email
  capability, but I'd not necessarily insist on being able to input
  to it by mail.  Red Hat's present bugzilla system could be described
  that way --- and while I can't say I'm in love with it, I can deal
  with it.
 
 Bugzilla is good in that you need to sign up to report anything (or at 
 least it can be configured that way, not sure), which might reduce the 
 amount of noise.  The other systems that have been mentioned have by 
 design little or no barrier of entry, which doesn't seem to be what we 
 want.
 
We put an anti-spam solution w/quarantine in front of our RT E-mail
instance (DSPAM) and it is very effective at keeping the cruft out of
the tracking system. You can also do basic processing on incoming
messages to weed out the non-bugs. We put them in a General start
queue and then move them to other working queues when they meet
whatever threshold you set. The General queue could also automatically
timeout/close tickets that stay in the queue for a certain period of
time.

Ken

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-17 Thread Kenneth Marshall
On Wed, Aug 16, 2006 at 01:22:43PM +0900, Michael Glaesemann wrote:
 
 On Aug 16, 2006, at 12:29 , Tom Lane wrote:
 
 So my current take on this would be that the bug tracker
 would have to have a reasonable output email capability, but I'd not
 necessarily insist on being able to input to it by mail.
 
 Setting aside the email in, how would people feel about Atom or RSS  
 feeds as an alternative for alerts of activity in the system?
 
 Michael Glaesemann
 grzm seespotcode net
 
 
RT has an RSS output. A particular set of criteria can be used to
populate it on an individual basis.

Ken

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-17 Thread Kenneth Marshall
RT has an E-mail interface. That was one of our considerations
when we used it to replace our aging trouble ticket system. What
does the interface need to do? RT's is pretty flexible.

Ken

On Tue, Aug 15, 2006 at 04:59:46PM -0500, Jim C. Nasby wrote:
 On Tue, Aug 15, 2006 at 10:53:28AM -0500, Kenneth Marshall wrote:
  RT is easy to setup/configure/use and works well with PostgreSQL
  as the backend. CPAN uses it for their bug tracker. Was there a
  list of features and requirements?
  
 I don't know if we ever came up with one, but I know that the big deal
 killer for a bug tracker is that a lot of hackers don't want to be
 forced to use a web interface instead of email. So basically, to be
 accepted, a bug tracker would have to have an effective email interface;
 one that allowed for updates to an issue coming in via email. Sadly, I
 don't think such an animal exists.
 
  Ken
  
  On Tue, Aug 15, 2006 at 10:59:52AM -0300, Marc G. Fournier wrote:
   On Fri, 11 Aug 2006, Alvaro Herrera wrote:
   
   I am suggesting that.  I have heard all the old discussions about not 
   using a bugtracker, but in all fairness, I think some of us have to 
   create critical mass and get something started.
   
   I will install anything, and everything, if you can get some sort of 
   concensus on which one to try / go with ... so far, all discussions have 
   ended with nobody coming close to agreeing to anything :)
   
   
   Marc G. Fournier   Hub.Org Networking Services 
   (http://www.hub.org)
   Email . [EMAIL PROTECTED]  MSN . [EMAIL 
   PROTECTED]
   Yahoo . yscrappy   Skype: hub.orgICQ . 7615664
   
   ---(end of broadcast)---
   TIP 2: Don't 'kill -9' the postmaster
   
  
  ---(end of broadcast)---
  TIP 6: explain analyze is your friend
  
 
 -- 
 Jim C. Nasby, Sr. Engineering Consultant  [EMAIL PROTECTED]
 Pervasive Software  http://pervasive.comwork: 512-231-6117
 vcard: http://jim.nasby.net/pervasive.vcf   cell: 512-569-9461
 

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-17 Thread Jim C. Nasby
On Thu, Aug 17, 2006 at 07:00:21PM +0200, Magnus Hagander wrote:
  These days I doubt there's anyone around the project who 
  refuses to use a web browser at all.  However, I still 
  personally find it much more convenient to read and respond 
  to mailing-list postings than to have to go and visit random 
  web pages to find out if there's something I need to know 
  about.  So my current take on this would be that the bug 
  tracker would have to have a reasonable output email 
  capability, but I'd not necessarily insist on being able to 
  input to it by mail.  Red Hat's present bugzilla system 
  could be described that way --- and while I can't say I'm in 
  love with it, I can deal with it.
 
 Doesn't bugzilla insist on sending you the complete bug every time? Or
 am I confusing it with the gforge/pgfoundry trackers? If so, then it's a
 really bad idea, IMHO, since it sends new copies out all the time...
 
No. In fact, it's one of the few that doesn't do that. I agree that
sending the whole bug is a really dumb idea.
 
  Now the other side of the coin is that people are used to 
  being able to email problem reports to pgsql-bugs, and that's 
  not going to stop anytime soon.  If you don't mind having a 
  bug tracker that is clueless about some fair-size fraction of 
  what is going on, then you can set up a system that is 
  impervious to email input.  Just don't expect people to trust 
  it very far.
 
 Whatever system is used (if one is), there definitly needs to be some
 people looking over what comes in on the mailinglists (or on IRC, for
 that matter) and pipe it off to the tracker in case it's not already
 there. Unless we want to force everybody to use *just* a web interface
 (which would be a horrible idea, btw), we won't get 100% coverage.
 
 (btw, istm that people email at least as many bugs directly to -hackers,
 or to -general or whatever, because the end user *does not know* when
 it's a bug from when it's a misconfiguration, or misunderstanding of the
 issue or whatnot)

Yes, there will have to be cross-checking. However, in practice, I've
found that users will enter the bug themselves if you send them a reply
asking them to, so I don't think it should pose too much additional
burden.
-- 
Jim C. Nasby, Sr. Engineering Consultant  [EMAIL PROTECTED]
Pervasive Software  http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf   cell: 512-569-9461

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-17 Thread Jim C. Nasby
On Thu, Aug 17, 2006 at 07:05:17PM +0200, Magnus Hagander wrote:
  I've yet to see a bug tracker that doesn't make it trivial to 
  identify bugs that were marked as invalid (ie: not a real 
  bug). The only difference is that you actually have to mark 
 Well, if it's invalid, it shouldn't be in there. But I guess you could
 just go ahead and delete it at that point - but it's work that someone
 has to do.
 
 But when I look at a lot of OSS projects out there, I see hundreds (if
 not thousands or tens of thousands for large projects) of bugs that are
 just dangling. That likely aren't bugs, but they are listed as such.
 Could definitly be that it's just that the system isn't maintained
 properly, but if so many others have failed, there's definitly a
 nontrivial risk that we would fail as well.

I always see people getting bent out-of-shape about bug trackers that
contain a lot of invalid bug reports and I never understand why. Most of
the ones I've seen hide those by default, so it's not like you really
have to deal with them. And having them still exist is useful... for
example, if you keep seeing the same thing come up over and over you
know there's probably an issue of some kind (ie: documentation). Plus,
if users are encouraged to search for the bug they found before
reporting it and *that* search by default includes invalid bugs then
it's more likely that the user will find the question (and answer)
themselves.
-- 
Jim C. Nasby, Sr. Engineering Consultant  [EMAIL PROTECTED]
Pervasive Software  http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf   cell: 512-569-9461

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-17 Thread Tom Lane
Magnus Hagander [EMAIL PROTECTED] writes:
 ...  Red Hat's present bugzilla system 
 could be described that way --- and while I can't say I'm in 
 love with it, I can deal with it.

 Doesn't bugzilla insist on sending you the complete bug every time?

Nope, it just sends the changes/additions.  Other than the lack of a
direct email input method, I find BZ quite usable.  Josh was just
complaining that its source code is a mess (dunno, haven't looked)
but other than that I think it's a definite possibility, just because
so many people are already familiar with it.

 Whatever system is used (if one is), there definitly needs to be some
 people looking over what comes in on the mailinglists (or on IRC, for
 that matter) and pipe it off to the tracker in case it's not already
 there.

Sure; we'd need a few volunteers handling that, no matter what software
we pick.

regards, tom lane

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-17 Thread Andrew Dunstan

Jim C. Nasby wrote:

On Thu, Aug 17, 2006 at 07:05:17PM +0200, Magnus Hagander wrote:
  
I've yet to see a bug tracker that doesn't make it trivial to 
identify bugs that were marked as invalid (ie: not a real 
bug). The only difference is that you actually have to mark 
  

Well, if it's invalid, it shouldn't be in there. But I guess you could
just go ahead and delete it at that point - but it's work that someone
has to do.

But when I look at a lot of OSS projects out there, I see hundreds (if
not thousands or tens of thousands for large projects) of bugs that are
just dangling. That likely aren't bugs, but they are listed as such.
Could definitly be that it's just that the system isn't maintained
properly, but if so many others have failed, there's definitly a
nontrivial risk that we would fail as well.



I always see people getting bent out-of-shape about bug trackers that
contain a lot of invalid bug reports and I never understand why. Most of
the ones I've seen hide those by default, so it's not like you really
have to deal with them. And having them still exist is useful... for
example, if you keep seeing the same thing come up over and over you
know there's probably an issue of some kind (ie: documentation). Plus,
if users are encouraged to search for the bug they found before
reporting it and *that* search by default includes invalid bugs then
it's more likely that the user will find the question (and answer)
themselves.
  


If the crud isn't handled some way then the system isn't nearly as much 
use to you. That's why I believe some sort of process for keeping the 
bug tracking system reasonably clean is necessary.


cheers

andrew




---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-17 Thread Andrew Dunstan

Tom Lane wrote:

Doesn't bugzilla insist on sending you the complete bug every time?



Nope, it just sends the changes/additions.  Other than the lack of a
direct email input method, I find BZ quite usable.  Josh was just
complaining that its source code is a mess (dunno, haven't looked)
but other than that I think it's a definite possibility, just because
so many people are already familiar with it.

  
One other point about BZ - several community members (including me) put 
in some effort to make the trunk version run on postgres, which it now 
does, and quite well. So our using it would be a nice return compliment. 
The source code might well be a mess, but for the most part it can just 
be treated as a black box.

Whatever system is used (if one is), there definitly needs to be some
people looking over what comes in on the mailinglists (or on IRC, for
that matter) and pipe it off to the tracker in case it's not already
there.



Sure; we'd need a few volunteers handling that, no matter what software
we pick.


  


You betcha. I'm glad we agree about that.


cheers

andrew

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-17 Thread Alvaro Herrera
Tom Lane wrote:
 Magnus Hagander [EMAIL PROTECTED] writes:
  ...  Red Hat's present bugzilla system 
  could be described that way --- and while I can't say I'm in 
  love with it, I can deal with it.
 
  Doesn't bugzilla insist on sending you the complete bug every time?
 
 Nope, it just sends the changes/additions.  Other than the lack of a
 direct email input method, I find BZ quite usable.  Josh was just
 complaining that its source code is a mess (dunno, haven't looked)
 but other than that I think it's a definite possibility, just because
 so many people are already familiar with it.

Have you tried to use debbugs?  I agree with Greg Stark that it's a
better fit for our current procedure, while enabling better
traceability.

For an example, see http://bugs.debian.org.  There are three links there
pointing to pages on how to use the system.  Entering a bug number shows
detail; for example try entering 330514 which is a PostgreSQL bug.  You
can add more detail to a bug by mailing bug-number@bugs.debian.org.
You can close a bug by mailing bug-number[EMAIL PROTECTED]  You
can of course clone bugs, retarget to a different package, merge bugs,
etc.

It's controllable by email -- in fact, I think email is the only
controlling interface.  You can get reports using the web frontend.  You
can get an mbox via HTTP for a particular bug, which you can later open
with your email client if you like.  (And respond to it, etc).


We would have to determine what constitutes a package (probably one
for each contrib module, one for each interface, one for the backend,
etc; or we could have separate package for optimizer, rewriter,
transaction system, one for each access method, etc), what tags
there are, what versions, etc.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-17 Thread Peter Eisentraut
Alvaro Herrera wrote:
 Have you tried to use debbugs?

If you can find up-to-date source code for debbugs, we might continue 
that line of thought.

The searching capabilities in debbugs are, well, non-existent, which is 
a real problem in my mind.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-17 Thread Alvaro Herrera
Peter Eisentraut wrote:
 Alvaro Herrera wrote:
  Have you tried to use debbugs?
 
 If you can find up-to-date source code for debbugs, we might continue 
 that line of thought.

Josh Berkus said he'd try to talk to the Debian people at LinuxWorld --
let's see if something materializes from there.

 The searching capabilities in debbugs are, well, non-existent, which is 
 a real problem in my mind.

Well, we can set up our own indexing, like Oleg and Teodor have done in
http://www.pgsql.ru/

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-17 Thread Tom Lane
Alvaro Herrera [EMAIL PROTECTED] writes:
 Have you tried to use debbugs?  I agree with Greg Stark that it's a
 better fit for our current procedure, while enabling better
 traceability.

The principal strike against debbugs seems to be that the source code is
not readily available and/or isn't updated regularly.  If we could get
current sources we'd probably end up maintaining our own fork ... OTOH,
given all the enthusiasm being expressed in this thread, somebody would
volunteer to do that no?

Other than that not-small problem, I agree that debbugs seems like an
excellent fit to our existing habits.

regards, tom lane

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-16 Thread Peter Eisentraut
Am Mittwoch, 16. August 2006 14:10 schrieb Robert Treat:
 I'm not sure I follow this, since currently anyone can email the bugs list
 or use the bugs - email form from the website.  Are you looking to
 increase the barrier for bug reporting?

Only a small fraction of the new posts on pgsql-bugs are actually bugs.  Most 
are confused or misdirected users.  I don't want to raise that barrier.  But 
I want a higher barrier before something is recorded in the bug tracking 
system.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-16 Thread Robert Treat
On Wednesday 16 August 2006 00:52, Peter Eisentraut wrote:
 Tom Lane wrote:
  that the bug tracker would have to have a reasonable output email
  capability, but I'd not necessarily insist on being able to input
  to it by mail.  Red Hat's present bugzilla system could be described
  that way --- and while I can't say I'm in love with it, I can deal
  with it.

 Bugzilla is good in that you need to sign up to report anything (or at
 least it can be configured that way, not sure), which might reduce the
 amount of noise.  The other systems that have been mentioned have by
 design little or no barrier of entry, which doesn't seem to be what we
 want.

I'm not sure I follow this, since currently anyone can email the bugs list or 
use the bugs - email form from the website.  Are you looking to increase the 
barrier for bug reporting? 

-- 
Robert Treat
Build A Brighter LAMP :: Linux Apache {middleware} PostgreSQL

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-16 Thread Martijn van Oosterhout
On Wed, Aug 16, 2006 at 02:28:53PM +0200, Peter Eisentraut wrote:
 Am Mittwoch, 16. August 2006 14:10 schrieb Robert Treat:
  I'm not sure I follow this, since currently anyone can email the bugs list
  or use the bugs - email form from the website.  Are you looking to
  increase the barrier for bug reporting?
 
 Only a small fraction of the new posts on pgsql-bugs are actually bugs.  Most 
 are confused or misdirected users.  I don't want to raise that barrier.  But 
 I want a higher barrier before something is recorded in the bug tracking 
 system.

Well, you need to get some agreement on what the bug tracker is for. Is
it:

a) a front-end to deal with complaints and bugs people have. Is it
something you expect end users to look at? This is how Debian uses its
bug-tracker, to make sure issues people bring up don't get lost. You
can always close the bug if it isn't a real bug.

Or:

b) a private bug database only used by -hackers to track known
outstanding bugs and patches.

If you want the latter, the approach would be to keep pgsql-bugs and
when a real issue comes up, bounce it to the bug tracker. Any
subsequent email discussion should then get logged in the bug report.

Have a nice day,
-- 
Martijn van Oosterhout   kleptog@svana.org   http://svana.org/kleptog/
 From each according to his ability. To each according to his ability to 
 litigate.


signature.asc
Description: Digital signature


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-16 Thread Andrew Dunstan

Martijn van Oosterhout wrote:

On Wed, Aug 16, 2006 at 02:28:53PM +0200, Peter Eisentraut wrote:
  

Am Mittwoch, 16. August 2006 14:10 schrieb Robert Treat:


I'm not sure I follow this, since currently anyone can email the bugs list
or use the bugs - email form from the website.  Are you looking to
increase the barrier for bug reporting?
  
Only a small fraction of the new posts on pgsql-bugs are actually bugs.  Most 
are confused or misdirected users.  I don't want to raise that barrier.  But 
I want a higher barrier before something is recorded in the bug tracking 
system.



Well, you need to get some agreement on what the bug tracker is for. Is
it:

a) a front-end to deal with complaints and bugs people have. Is it
something you expect end users to look at? This is how Debian uses its
bug-tracker, to make sure issues people bring up don't get lost. You
can always close the bug if it isn't a real bug.

Or:

b) a private bug database only used by -hackers to track known
outstanding bugs and patches.

If you want the latter, the approach would be to keep pgsql-bugs and
when a real issue comes up, bounce it to the bug tracker. Any
subsequent email discussion should then get logged in the bug report.

Have a nice day,
  



What we are talking about here is bug triage. Weeding out misreports, 
duplicates etc. is a prime part of this function. It is essential to the 
health of any functioning bug tracking system. All it takes is 
resources. Is it worth it? Yes, IMNSHO, but it's a judgement call.


One sensible way to do this would be to have a group of suitably 
qualified volunteers who could perform this function on a roster basis, 
for, say, a week or a two at a time. That way we could the load off key 
personnel like Tom (I am in favor of anything which would reduce the 
demands we place on Tom ;-) )


cheers

andrew

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-16 Thread Jim C. Nasby
On Wed, Aug 16, 2006 at 09:14:47AM -0400, Andrew Dunstan wrote:
 What we are talking about here is bug triage. Weeding out misreports, 
 duplicates etc. is a prime part of this function. It is essential to the 
 health of any functioning bug tracking system. All it takes is 
 resources. Is it worth it? Yes, IMNSHO, but it's a judgement call.
 
 One sensible way to do this would be to have a group of suitably 
 qualified volunteers who could perform this function on a roster basis, 
 for, say, a week or a two at a time. That way we could the load off key 
 personnel like Tom (I am in favor of anything which would reduce the 
 demands we place on Tom ;-) )

Actually, I'd bet we don't need to put such a formal system in place. I
suspect that we'll have users actually looking at the incomming bugs and
commenting if they're not valid. As we notice folks who are doing a good
job of that, we can give them the privleges to mark bugs as invalid.

In the meantime, I'd be glad to help out with 'weeding' incomming bug
reports. Depending on the bug tracking system, you can even just let
people do this ad-hoc... bugzilla (for example) has an unconfirmed
status for new bugs; it would just take people looking at all
unconfirmed bugs and marking them appropriately.
-- 
Jim C. Nasby, Sr. Engineering Consultant  [EMAIL PROTECTED]
Pervasive Software  http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf   cell: 512-569-9461

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-16 Thread Jim C. Nasby
On Tue, Aug 15, 2006 at 10:43:12PM -0700, Josh Berkus wrote:
 Tom,
 
  These days I doubt there's anyone around the project who refuses to use
  a web browser at all.  However, I still personally find it much more
  convenient to read and respond to mailing-list postings than to have to
  go and visit random web pages to find out if there's something I need to
  know about.  So my current take on this would be that the bug tracker
  would have to have a reasonable output email capability, but I'd not
  necessarily insist on being able to input to it by mail.  Red Hat's
  present bugzilla system could be described that way --- and while I
  can't say I'm in love with it, I can deal with it.
 
 Actually, if that's the only objection it's solved.  RT will now allow you to 
 create, comment on, modify, and close bugs by e-mail.   And the RT team would 
 be thrilled to have us using it, in theory enough to provide some setup help.
 There's one thing that RT doesn't do by e-mail (can't remember offhand) but 
 that's a TODO for them so it should be fixed soon.
 
 So, if the only real requirement for a bug tracker is that we can handle it 
 100% by e-mail, and integrate it with the pgsql-bugs list, that is possible.

Does Trac have similar capability? Reason I'm asking is that I think
*eventually* it would be very useful to have trac's ability to link
bugs, version control, wiki, etc. all together. I know it'll probably be
quite some time before that happens, but I'm sure that if we go with RT
it'll never happen.
-- 
Jim C. Nasby, Sr. Engineering Consultant  [EMAIL PROTECTED]
Pervasive Software  http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf   cell: 512-569-9461

---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
   choose an index scan if your joining column's datatypes do not
   match


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-16 Thread mdean

Jim C. Nasby wrote:


On Tue, Aug 15, 2006 at 10:43:12PM -0700, Josh Berkus wrote:
 


Tom,

   


These days I doubt there's anyone around the project who refuses to use
a web browser at all.  However, I still personally find it much more
convenient to read and respond to mailing-list postings than to have to
go and visit random web pages to find out if there's something I need to
know about.  So my current take on this would be that the bug tracker
would have to have a reasonable output email capability, but I'd not
necessarily insist on being able to input to it by mail.  Red Hat's
present bugzilla system could be described that way --- and while I
can't say I'm in love with it, I can deal with it.
 

Actually, if that's the only objection it's solved.  RT will now allow you to 
create, comment on, modify, and close bugs by e-mail.   And the RT team would 
be thrilled to have us using it, in theory enough to provide some setup help.
There's one thing that RT doesn't do by e-mail (can't remember offhand) but 
that's a TODO for them so it should be fixed soon.


So, if the only real requirement for a bug tracker is that we can handle it 
100% by e-mail, and integrate it with the pgsql-bugs list, that is possible.
   



Does Trac have similar capability? Reason I'm asking is that I think
*eventually* it would be very useful to have trac's ability to link
bugs, version control, wiki, etc. all together. I know it'll probably be
quite some time before that happens, but I'm sure that if we go with RT
it'll never happen.
 

guys, just a sobering refrain from the troll audience -- establishing 
trac/subversion, as a formal mechanism within postgesql circles, would 
go a long way toward showing the real world out there that postgresql is 
professionalizing (I know) and systematizing, etc.ad infinitum.  Let 
everyone identify bugs (keeps novices busy), the more the merrier!  New 
classes of semi-programmers will arise,  lets call them buggers, and 
bugger watchers,  unless they know English very well, pretty soon, the 
system will get used by real programmers, because in the long run, it 
saves time, and gets results.  And folks, lets learn from the goofs of 
the Freebsd crowd, and maybe even from the Torvalds gang. Michael



--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.10/419 - Release Date: 8/15/2006


---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-16 Thread Marc G. Fournier

On Wed, 16 Aug 2006, Robert Treat wrote:

I'm not sure I follow this, since currently anyone can email the bugs 
list or use the bugs - email form from the website.  Are you looking to 
increase the barrier for bug reporting?


Any garbage (ie. spam) is generally filtered before it hits the -bugs list 
itself



Marc G. Fournier   Hub.Org Networking Services (http://www.hub.org)
Email . [EMAIL PROTECTED]  MSN . [EMAIL PROTECTED]
Yahoo . yscrappy   Skype: hub.orgICQ . 7615664

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-16 Thread Gregory Stark
Andrew Dunstan [EMAIL PROTECTED] writes:

 What we are talking about here is bug triage. 

Really? We have a problem with too many bug reports and need a tool to help
triage them? That's the first I've heard of that.

Think about what tasks you do now and what tool would make it easier. Don't
try to invent problems to solve.

The Debian system would be basically zero operational change. pgsql-bugs would
continue to exist exactly as it does now except it would go through debbugs.
Any message there would open a bug report. Anyone responding to say that's
not a bug would just include the magic phrase to close the bug report too.

Anyone responding with questions or data would just respond as normal. The net
result would be exactly as it is now except that there would be a tool to view
what bugs are still open and look at all the data accumulated on that bug. And
you could look back at old bugs to see what version they were fixed in and
what the bug looked like to see if it matched the problem a user is having.

In short, it's just a tool to solve a problem we actually have (having a
convenient archive of data about current and past bugs) without inventing
problems to solve with extra process that we aren't already doing anyways.

RT can be set up similarly but I'm not sure how much work it would take to
make it as seamless. Debbugs has the advantage of working that way pretty much
out of the box.


-- 
  Gregory Stark
  EnterpriseDB  http://www.enterprisedb.com


---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-16 Thread Peter Eisentraut
Gregory Stark wrote:
 The Debian system would be basically zero operational change.
 pgsql-bugs would continue to exist exactly as it does now except it
 would go through debbugs.

Debbugs is fine and all, but they don't seem to publish their code on a 
regular basis.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-16 Thread Peter Eisentraut
Andrew Dunstan wrote:
 What we are talking about here is bug triage.

I think we are actually talking about bug *tracking*.

 One sensible way to do this would be to have a group of suitably
 qualified volunteers who could perform this function on a roster
 basis, for, say, a week or a two at a time.

Organising a roster, a rotating roster at that, is probably the single 
most difficult thing you can do in this group. :-)

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-16 Thread Peter Eisentraut
Martijn van Oosterhout wrote:
 If you want the latter, the approach would be to keep pgsql-bugs and
 when a real issue comes up, bounce it to the bug tracker. Any
 subsequent email discussion should then get logged in the bug report.

That's what I want.  I don't want the bug tracking system to be the 
primary frontend to users off the street.  Because quite frankly most 
users are too confused to know what a real bug is.  That doesn't mean 
that I want a closed BTS, but a system that requires sign up and user 
accounts (like Bugzilla) imposes the right barrier to random abuse in 
my mind.

Note that RT stands for Request Tracker, which on its face is a 
different thing, namely a system to do tracking of requests by users 
off the street.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-15 Thread Marc G. Fournier

On Fri, 11 Aug 2006, Alvaro Herrera wrote:

I am suggesting that.  I have heard all the old discussions about not 
using a bugtracker, but in all fairness, I think some of us have to 
create critical mass and get something started.


I will install anything, and everything, if you can get some sort of 
concensus on which one to try / go with ... so far, all discussions have 
ended with nobody coming close to agreeing to anything :)



Marc G. Fournier   Hub.Org Networking Services (http://www.hub.org)
Email . [EMAIL PROTECTED]  MSN . [EMAIL PROTECTED]
Yahoo . yscrappy   Skype: hub.orgICQ . 7615664

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-15 Thread mdean

Marc G. Fournier wrote:


On Fri, 11 Aug 2006, Alvaro Herrera wrote:

I am suggesting that.  I have heard all the old discussions about not 
using a bugtracker, but in all fairness, I think some of us have to 
create critical mass and get something started.



I will install anything, and everything, if you can get some sort of 
concensus on which one to try / go with ... so far, all discussions 
have ended with nobody coming close to agreeing to anything :)



Marc G. Fournier   Hub.Org Networking Services 
(http://www.hub.org)
Email . [EMAIL PROTECTED]  MSN . 
[EMAIL PROTECTED]

Yahoo . yscrappy   Skype: hub.orgICQ . 7615664

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster

quite frankly, I think this group needs the same kind of consensus found 
in Torvalds kernel group.  Is anyone denying their approach gets better 
results!?  No flatline there. JMUASFANPWWMR!



--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.10/418 - Release Date: 8/14/2006


---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-15 Thread Kenneth Marshall
RT is easy to setup/configure/use and works well with PostgreSQL
as the backend. CPAN uses it for their bug tracker. Was there a
list of features and requirements?

Ken

On Tue, Aug 15, 2006 at 10:59:52AM -0300, Marc G. Fournier wrote:
 On Fri, 11 Aug 2006, Alvaro Herrera wrote:
 
 I am suggesting that.  I have heard all the old discussions about not 
 using a bugtracker, but in all fairness, I think some of us have to 
 create critical mass and get something started.
 
 I will install anything, and everything, if you can get some sort of 
 concensus on which one to try / go with ... so far, all discussions have 
 ended with nobody coming close to agreeing to anything :)
 
 
 Marc G. Fournier   Hub.Org Networking Services (http://www.hub.org)
 Email . [EMAIL PROTECTED]  MSN . [EMAIL PROTECTED]
 Yahoo . yscrappy   Skype: hub.orgICQ . 7615664
 
 ---(end of broadcast)---
 TIP 2: Don't 'kill -9' the postmaster
 

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-15 Thread Jim C. Nasby
On Tue, Aug 15, 2006 at 10:53:28AM -0500, Kenneth Marshall wrote:
 RT is easy to setup/configure/use and works well with PostgreSQL
 as the backend. CPAN uses it for their bug tracker. Was there a
 list of features and requirements?
 
I don't know if we ever came up with one, but I know that the big deal
killer for a bug tracker is that a lot of hackers don't want to be
forced to use a web interface instead of email. So basically, to be
accepted, a bug tracker would have to have an effective email interface;
one that allowed for updates to an issue coming in via email. Sadly, I
don't think such an animal exists.

 Ken
 
 On Tue, Aug 15, 2006 at 10:59:52AM -0300, Marc G. Fournier wrote:
  On Fri, 11 Aug 2006, Alvaro Herrera wrote:
  
  I am suggesting that.  I have heard all the old discussions about not 
  using a bugtracker, but in all fairness, I think some of us have to 
  create critical mass and get something started.
  
  I will install anything, and everything, if you can get some sort of 
  concensus on which one to try / go with ... so far, all discussions have 
  ended with nobody coming close to agreeing to anything :)
  
  
  Marc G. Fournier   Hub.Org Networking Services (http://www.hub.org)
  Email . [EMAIL PROTECTED]  MSN . [EMAIL 
  PROTECTED]
  Yahoo . yscrappy   Skype: hub.orgICQ . 7615664
  
  ---(end of broadcast)---
  TIP 2: Don't 'kill -9' the postmaster
  
 
 ---(end of broadcast)---
 TIP 6: explain analyze is your friend
 

-- 
Jim C. Nasby, Sr. Engineering Consultant  [EMAIL PROTECTED]
Pervasive Software  http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf   cell: 512-569-9461

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-15 Thread Marc G. Fournier

On Tue, 15 Aug 2006, Jim C. Nasby wrote:


On Tue, Aug 15, 2006 at 10:53:28AM -0500, Kenneth Marshall wrote:

RT is easy to setup/configure/use and works well with PostgreSQL
as the backend. CPAN uses it for their bug tracker. Was there a
list of features and requirements?


I don't know if we ever came up with one, but I know that the big deal
killer for a bug tracker is that a lot of hackers don't want to be
forced to use a web interface instead of email. So basically, to be
accepted, a bug tracker would have to have an effective email interface;
one that allowed for updates to an issue coming in via email. Sadly, I
don't think such an animal exists.


GnATs :)





Ken

On Tue, Aug 15, 2006 at 10:59:52AM -0300, Marc G. Fournier wrote:

On Fri, 11 Aug 2006, Alvaro Herrera wrote:


I am suggesting that.  I have heard all the old discussions about not
using a bugtracker, but in all fairness, I think some of us have to
create critical mass and get something started.


I will install anything, and everything, if you can get some sort of
concensus on which one to try / go with ... so far, all discussions have
ended with nobody coming close to agreeing to anything :)


Marc G. Fournier   Hub.Org Networking Services (http://www.hub.org)
Email . [EMAIL PROTECTED]  MSN . [EMAIL PROTECTED]
Yahoo . yscrappy   Skype: hub.orgICQ . 7615664

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster



---(end of broadcast)---
TIP 6: explain analyze is your friend



--
Jim C. Nasby, Sr. Engineering Consultant  [EMAIL PROTECTED]
Pervasive Software  http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf   cell: 512-569-9461




Marc G. Fournier   Hub.Org Networking Services (http://www.hub.org)
Email . [EMAIL PROTECTED]  MSN . [EMAIL PROTECTED]
Yahoo . yscrappy   Skype: hub.orgICQ . 7615664

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-15 Thread Alvaro Herrera
Jim C. Nasby wrote:
 On Tue, Aug 15, 2006 at 10:53:28AM -0500, Kenneth Marshall wrote:
  RT is easy to setup/configure/use and works well with PostgreSQL
  as the backend. CPAN uses it for their bug tracker. Was there a
  list of features and requirements?
  
 I don't know if we ever came up with one, but I know that the big deal
 killer for a bug tracker is that a lot of hackers don't want to be
 forced to use a web interface instead of email. So basically, to be
 accepted, a bug tracker would have to have an effective email interface;
 one that allowed for updates to an issue coming in via email. Sadly, I
 don't think such an animal exists.

We have three candidates already -- debbugs, RT and Gnats.  The first
has the advantage that was written by hackers, for hackers, so it
doesn't have any of the insane for end users stuff which annoys so
many people around here ;-) (On the other hand it does have some web
stuff for generating reports, etc).

I haven't used RT much, and I don't know Gnats at all, but I kinda like
(the little I have played with) debbugs.  Apparently it's rather easy to
set up:

http://www.benham.net/debbugs/

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-15 Thread Larry Rosenman
I've used and use RT.  It is web based for admin, but all the transactions
are E-Mail based.

http://www.bestpractical.com

I can also make a test queue on my instance if someone wants to play.




-- 
Larry Rosenman http://www.lerctr.org/~ler
Phone: +1 512-248-2683 E-Mail: ler@lerctr.org
US Mail: 430 Valona Loop, Round Rock, TX 78681-3683 US



---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-15 Thread Christopher Kings-Lynne

We have three candidates already -- debbugs, RT and Gnats.  The first
has the advantage that was written by hackers, for hackers, so it
doesn't have any of the insane for end users stuff which annoys so
many people around here ;-) (On the other hand it does have some web
stuff for generating reports, etc).


Kill me now if I have to use GNATS :) Have you ever tried submitting a
bug to the FreeBSD project? *shudder*

That said, I'll live :)

I have recently totally falling in love with Trac and its complete
subversion integration.  I'm not sure it supports PostgreSQL, and
converting to subversion is probably a little too hardcore at the
moment :)

Chris

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-15 Thread mdean

Christopher Kings-Lynne wrote:


We have three candidates already -- debbugs, RT and Gnats.  The first
has the advantage that was written by hackers, for hackers, so it
doesn't have any of the insane for end users stuff which annoys so
many people around here ;-) (On the other hand it does have some web
stuff for generating reports, etc).



Kill me now if I have to use GNATS :) Have you ever tried submitting a
bug to the FreeBSD project? *shudder*

That said, I'll live :)

I have recently totally falling in love with Trac and its complete
subversion integration.  I'm not sure it supports PostgreSQL, and
converting to subversion is probably a little too hardcore at the
moment :)

Chris

---(end of broadcast)---
TIP 6: explain analyze is your friend


CVS users just rot away or are subverted.


--
No virus found in this outgoing message.
Checked by AVG Free Edition.
Version: 7.1.405 / Virus Database: 268.10.10/419 - Release Date: 8/15/2006


---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-15 Thread Tom Lane
Jim C. Nasby [EMAIL PROTECTED] writes:
 I don't know if we ever came up with one, but I know that the big deal
 killer for a bug tracker is that a lot of hackers don't want to be
 forced to use a web interface instead of email. So basically, to be
 accepted, a bug tracker would have to have an effective email interface;
 one that allowed for updates to an issue coming in via email. Sadly, I
 don't think such an animal exists.

That was the position that several of us took five-or-six years ago when
the issue first came up ;-)

These days I doubt there's anyone around the project who refuses to use
a web browser at all.  However, I still personally find it much more
convenient to read and respond to mailing-list postings than to have to
go and visit random web pages to find out if there's something I need to
know about.  So my current take on this would be that the bug tracker
would have to have a reasonable output email capability, but I'd not
necessarily insist on being able to input to it by mail.  Red Hat's
present bugzilla system could be described that way --- and while I
can't say I'm in love with it, I can deal with it.

Now the other side of the coin is that people are used to being able to
email problem reports to pgsql-bugs, and that's not going to stop
anytime soon.  If you don't mind having a bug tracker that is clueless
about some fair-size fraction of what is going on, then you can set up a
system that is impervious to email input.  Just don't expect people to
trust it very far.

regards, tom lane

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-15 Thread Michael Glaesemann


On Aug 16, 2006, at 12:29 , Tom Lane wrote:


So my current take on this would be that the bug tracker
would have to have a reasonable output email capability, but I'd not
necessarily insist on being able to input to it by mail.


Setting aside the email in, how would people feel about Atom or RSS  
feeds as an alternative for alerts of activity in the system?


Michael Glaesemann
grzm seespotcode net




---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-15 Thread Peter Eisentraut
Tom Lane wrote:
 that the bug tracker would have to have a reasonable output email
 capability, but I'd not necessarily insist on being able to input
 to it by mail.  Red Hat's present bugzilla system could be described
 that way --- and while I can't say I'm in love with it, I can deal
 with it.

Bugzilla is good in that you need to sign up to report anything (or at 
least it can be configured that way, not sure), which might reduce the 
amount of noise.  The other systems that have been mentioned have by 
design little or no barrier of entry, which doesn't seem to be what we 
want.

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: BugTracker (Was: Re: [HACKERS] 8.2 features status)

2006-08-15 Thread Josh Berkus
Tom,

 These days I doubt there's anyone around the project who refuses to use
 a web browser at all.  However, I still personally find it much more
 convenient to read and respond to mailing-list postings than to have to
 go and visit random web pages to find out if there's something I need to
 know about.  So my current take on this would be that the bug tracker
 would have to have a reasonable output email capability, but I'd not
 necessarily insist on being able to input to it by mail.  Red Hat's
 present bugzilla system could be described that way --- and while I
 can't say I'm in love with it, I can deal with it.

Actually, if that's the only objection it's solved.  RT will now allow you to 
create, comment on, modify, and close bugs by e-mail.   And the RT team would 
be thrilled to have us using it, in theory enough to provide some setup help.
There's one thing that RT doesn't do by e-mail (can't remember offhand) but 
that's a TODO for them so it should be fixed soon.

So, if the only real requirement for a bug tracker is that we can handle it 
100% by e-mail, and integrate it with the pgsql-bugs list, that is possible.

-- 
Josh Berkus
PostgreSQL @ Sun
San Francisco

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] 8.2 features status

2006-08-12 Thread Martijn van Oosterhout
On Fri, Aug 11, 2006 at 05:27:46PM -0400, Alvaro Herrera wrote:
  Does that rails thing also have a bug tracker that integrates with
  mailing lists? IIRC the show-stopper on a bug tracker was finding one
  that allowed people to still use mailing lists.
 
 AFAIU the showstopper was that people wanted to be able to _control_ the
 bugtracker using email only, i.e. not forcing you to open a web browser
 to do stuff like adding comments or attachments to a bug, or closing,
 etc.

The only bugtracker I know that allows that is debbugs, which a nice
system IMHO, but I'm sure people have differing opinions about that...

Have a nice day,
-- 
Martijn van Oosterhout   kleptog@svana.org   http://svana.org/kleptog/
 From each according to his ability. To each according to his ability to 
 litigate.


signature.asc
Description: Digital signature


Re: [HACKERS] 8.2 features status

2006-08-11 Thread Reinoud van Leeuwen
On Thu, Aug 10, 2006 at 09:02:36PM -0700, Joshua D. Drake wrote:

 I think it is a combination of the two. A wiki could be used to discuss 
 ideas for todos, it could be used to describe TODOs in actual detail, it 
 could used (in conjunction with Trac) to be able to document dependecies 
 for todos... etc.

A wiki for *discussion*? I thought email was for that. A wiki is nice to 
work toghether on a document (in some circumstances).

-- 
__
Nothing is as subjective as reality
Reinoud van Leeuwen[EMAIL PROTECTED]
http://www.xs4all.nl/~reinoud
__

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] 8.2 features status

2006-08-11 Thread Lukas Kahwe Smith

Reinoud van Leeuwen wrote:


On Thu, Aug 10, 2006 at 09:02:36PM -0700, Joshua D. Drake wrote:

I think it is a combination of the two. A wiki could be used to discuss 
ideas for todos, it could be used to describe TODOs in actual detail, it 
could used (in conjunction with Trac) to be able to document dependecies 
for todos... etc.


A wiki for *discussion*? I thought email was for that. A wiki is nice to 
work toghether on a document (in some circumstances).


I dont he meant that. A wiki is a good place to summarize an email 
discussion, not to actually hold a discussion on the wiki (I have seen 
it done though .. and its not pretty).


regards,
Lukas


---(end of broadcast)---
TIP 4: Have you searched our list archives?

  http://archives.postgresql.org


Re: [HACKERS] 8.2 features status

2006-08-11 Thread Zdenek Kotala

Neil Conway napsal(a):


However, is there a reason to use Trac beyond the fact that it is
already setup? ISTM we only need a wiki, and don't need the other
features of Trac, such as the bug tracker.


I do not agree. How you determine what release fixes the bug now? We 
have web page and mailing list for bug reporting but there is not any 
relation between bug, patch and release(s). I think bug tracking is 
necessary if we want move forward.


Zdenek

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] 8.2 features status

2006-08-11 Thread Alvaro Herrera
Joshua D. Drake wrote:
 Alvaro Herrera wrote:
 Jim Nasby wrote:
 First, +1 on Josh B.'s point about trying out Trac, since it's  
 already up and running. Josh D., can you just turn that on? (BTW, is  
 trac linked off http://commandprompt.com anywhere? I had to google to  
 find it yesterday...)
 
 I just noticed that the code repository on that Trac is broken in more
 ways than I had realized.  For starters it doesn't seem to have the 8.1
 branch or tags (apparently it's out of date).
 
 It doesn't?
 
 http://projects.commandprompt.com/public/pgsql/browser/tags/REL8_1_4/pgsql
 
 What are you looking at Alvaro?

Exactly that URL, but this wasn't there when I looked.  Maybe it was
being regenerated at that time?

But I don't know why you are ignoring my comments that it's broken.  For
an example, go here:

http://projects.commandprompt.com/public/pgsql/browser/branches/REL8_1_STABLE/pgsql/src

Note that the DEVELOPERS file shows a revision 5684, message Typo fix.
Click on that 5684.  It'll show you two items, revs 23689 and 5684.
First problem, where did that 23689 come from?  It wasn't there in the
parent dir.  Now open that changeset (click on the [23689]).  Look at
the list of files -- it only has errcodes.sgml in it.  No DEVELOPERS,
which is the file we want to track!  Furthermore, it doesn't show any
diff at all.

I have looked at it before and I've found these kinds of problems all
over the place.

If you mark follow copies in the box at the right and then click
Update, more broken revisions will appear.  It's impossible to actually
follow the history of a file, because all the entries are bogus.

I don't know what on earth is going on but I surely won't waste my time
checking that repo again since it seems pretty useless.

 Doesn't Trac have a CVS plugin? 
 
 No, like the rest of the world, Trac has moved on from CVS ;)

There are still a lot of projects using CVS.  We happen to be one of
them.

It's pretty damn useful to be able to use the Trac facilities to mark
tickets as fixed in revision such-and-such, which allows us to track
more carefully the bugs fixed and the features added.  But if the repo
is useless, then the rest of Trac loses a lot of its usefulness as well.

 And to be clear, I would only expect that this would be used as a 
 reference, that is all. The ability to link from the wiki directly to a 
 source file or changeset could be useful.

Precisely my point.  But if the reference doesn't work, then it's just a
plain Wiki like any other.  I wouldn't want to waste my time on that.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] 8.2 features status

2006-08-11 Thread Joshua D. Drake



http://projects.commandprompt.com/public/pgsql/browser/tags/REL8_1_4/pgsql

What are you looking at Alvaro?


Exactly that URL, but this wasn't there when I looked.  Maybe it was
being regenerated at that time?



Yeah it gets regenerated every 4 hours or so.


But I don't know why you are ignoring my comments that it's broken.  For
an example, go here:

http://projects.commandprompt.com/public/pgsql/browser/branches/REL8_1_STABLE/pgsql/src


No one is ignoring you.



Note that the DEVELOPERS file shows a revision 5684, message Typo fix.
Click on that 5684.  It'll show you two items, revs 23689 and 5684.
First problem, where did that 23689 come from?  It wasn't there in the
parent dir.  Now open that changeset (click on the [23689]).  Look at
the list of files -- it only has errcodes.sgml in it.  No DEVELOPERS,
which is the file we want to track!  Furthermore, it doesn't show any
diff at all.


O.k. So it isn't perfect. It isn't like I expected to be. However many 
people find it useful, myself included.



I don't know what on earth is going on but I surely won't waste my time
checking that repo again since it seems pretty useless.


O.k., I am not sure who put oil in your pudding, but nobody is asking 
you to use it. Use the CVSWeb from PostgreSQL.Org, which is actually 
what *you* should be using.


I would expect that if the SVN/Trac repo were determined to be used it 
would be used as an entry point and that explicit instructions would 
also be made that the authoritative source of the code is the CVSWeb 
repository.


Doesn't Trac have a CVS plugin? 

No, like the rest of the world, Trac has moved on from CVS ;)


There are still a lot of projects using CVS.  We happen to be one of
them.


Unfortunately that is true.


It's pretty damn useful to be able to use the Trac facilities to mark
tickets as fixed in revision such-and-such, which allows us to track
more carefully the bugs fixed and the features added.  But if the repo
is useless, then the rest of Trac loses a lot of its usefulness as well.


O.k. but no one is suggesting that we use Trac as a bug tracker, or at 
least I wasn't. All I was suggesting was the ability to help viewing of 
specific files as listed dependencies.




Precisely my point.  But if the reference doesn't work, then it's just a
plain Wiki like any other.  I wouldn't want to waste my time on that.



I just threw the trac out there because it was already setup. I don't 
care if anyone uses it or not. Nor am I suggesting that it *should* be used.


Lastly if you review this thread you would see that Andrew and I had 
already decided to wait until after Linux World to actually propose 
something.


It may be Trac it may be something else. For example, I am also looking 
at Launchpad. There is also something very similar to trac that is built

on ruby on rails that also integrates with mailing lists.

Sincerely,

Joshua D. Drake


--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] 8.2 features status

2006-08-11 Thread Joshua D. Drake


I do not agree. How you determine what release fixes the bug now? We 
have web page and mailing list for bug reporting but there is not any 
relation between bug, patch and release(s). I think bug tracking is 
necessary if we want move forward.


You can completely forget the idea of having an actual bug tracking 
system. It has been beaten to death over the years. The developers have 
very specific requirements that no bug tracker currently adheres to.


If you are in the mood for a long, never ending soap opera on the topic 
I suggest you review the archives :)


Sincerely,

Joshua D. Drake





Zdenek

---(end of broadcast)---
TIP 6: explain analyze is your friend




--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match


Re: [HACKERS] 8.2 features status

2006-08-11 Thread Andrew Dunstan

Joshua D. Drake wrote:


Lastly if you review this thread you would see that Andrew and I had 
already decided to wait until after Linux World to actually propose 
something.





It is perhaps not surprising, but most of the discussion has been 
focused on technologies (mailing lists, wikis, bugtrackers, trac, SCM 
systems, etc.). My view is that these things are at best enablers of 
good process, but they should not define the processes used. I am trying 
to spend what little time I can devote to this topic to thinking about 
the issues I see in human rather than technological terms.


cheers

andrew


---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] 8.2 features status

2006-08-11 Thread Alvaro Herrera
Joshua D. Drake wrote:
 
 http://projects.commandprompt.com/public/pgsql/browser/tags/REL8_1_4/pgsql
 
 What are you looking at Alvaro?
 
 Exactly that URL, but this wasn't there when I looked.  Maybe it was
 being regenerated at that time?
 
 Yeah it gets regenerated every 4 hours or so.

Suggestion -- have it create the new copy in a separate directory and
when it's complete, rename the new one to the original name.  That way
the update is atomic and users don't get to see an incomplete repo.


 I don't know what on earth is going on but I surely won't waste my time
 checking that repo again since it seems pretty useless.
 
 O.k., I am not sure who put oil in your pudding, but nobody is asking 
 you to use it. Use the CVSWeb from PostgreSQL.Org, which is actually 
 what *you* should be using.

Actually I'd *like* to use something better than CVSWeb, because you
know what?  It sucks and I'd love to have something better.  I'd also
like to have a decent bugtracker as well.  If both repo and bugtracker
are integrated it could be very useful.  We almost have that with Trac
but since it doesn't work, it's so close as to instill hope but because
of the bugs it's useless so it brings frustration instead, which is
much worse than if it didn't do either.


 It's pretty damn useful to be able to use the Trac facilities to mark
 tickets as fixed in revision such-and-such, which allows us to track
 more carefully the bugs fixed and the features added.  But if the repo
 is useless, then the rest of Trac loses a lot of its usefulness as well.
 
 O.k. but no one is suggesting that we use Trac as a bug tracker, or at 
 least I wasn't. All I was suggesting was the ability to help viewing of 
 specific files as listed dependencies.

I am suggesting that.  I have heard all the old discussions about not
using a bugtracker, but in all fairness, I think some of us have to
create critical mass and get something started.  Those who don't want to
use it can choose not to use it, or they can eventually find that yeah,
maybe it's a good idea after all.  If no one does anything, nothing will
happen.

I think the devel version of Trac contains some stuff to be able to
handle multiple SCMs.  I know there's a Monotone plugin for it at least.
Maybe somebody has already written a CVS plugin as well -- I'll have a
look.

 It may be Trac it may be something else. For example, I am also looking 
 at Launchpad. There is also something very similar to trac that is built
 on ruby on rails that also integrates with mailing lists.

Launchpad is proprietary.  I don't know about the RoR tool you mention,
it may be worth having a look at.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] 8.2 features status

2006-08-11 Thread Bruce Momjian
Alvaro Herrera wrote:
  O.k. but no one is suggesting that we use Trac as a bug tracker, or at 
  least I wasn't. All I was suggesting was the ability to help viewing of 
  specific files as listed dependencies.
 
 I am suggesting that.  I have heard all the old discussions about not
 using a bugtracker, but in all fairness, I think some of us have to
 create critical mass and get something started.  Those who don't want to
 use it can choose not to use it, or they can eventually find that yeah,
 maybe it's a good idea after all.  If no one does anything, nothing will
 happen.

Agreed.  Seems enough people are interested that even if I don't think
it will work, it is worth a try.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] 8.2 features status

2006-08-11 Thread Joshua D. Drake



Actually I'd *like* to use something better than CVSWeb, because you
know what?  It sucks and I'd love to have something better.  I'd also


I am not opposed to actually using taylor or something to do the 
conversion instead. I just couldn't get it to work.



I think the devel version of Trac contains some stuff to be able to
handle multiple SCMs.  I know there's a Monotone plugin for it at least.
Maybe somebody has already written a CVS plugin as well -- I'll have a
look.


Well that would make life ALOT easier.


Launchpad is proprietary.  I don't know about the RoR tool you mention,
it may be worth having a look at.


Launchpad is supposedly releasing their source 10/2006 I believe.

Sincerely,

Joshua D. Drake



--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match


Re: [HACKERS] 8.2 features status

2006-08-11 Thread Jim C. Nasby
On Fri, Aug 11, 2006 at 08:16:19AM -0700, Joshua D. Drake wrote:
 I just threw the trac out there because it was already setup. I don't 
 care if anyone uses it or not. Nor am I suggesting that it *should* be used.
 
 Lastly if you review this thread you would see that Andrew and I had 
 already decided to wait until after Linux World to actually propose 
 something.
 
 It may be Trac it may be something else. For example, I am also looking 
 at Launchpad. There is also something very similar to trac that is built
 on ruby on rails that also integrates with mailing lists.

Does that rails thing also have a bug tracker that integrates with
mailing lists? IIRC the show-stopper on a bug tracker was finding one
that allowed people to still use mailing lists.
-- 
Jim C. Nasby, Sr. Engineering Consultant  [EMAIL PROTECTED]
Pervasive Software  http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf   cell: 512-569-9461

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] 8.2 features status

2006-08-11 Thread Alvaro Herrera
Jim C. Nasby wrote:
 On Fri, Aug 11, 2006 at 08:16:19AM -0700, Joshua D. Drake wrote:
  I just threw the trac out there because it was already setup. I don't 
  care if anyone uses it or not. Nor am I suggesting that it *should* be used.
  
  Lastly if you review this thread you would see that Andrew and I had 
  already decided to wait until after Linux World to actually propose 
  something.
  
  It may be Trac it may be something else. For example, I am also looking 
  at Launchpad. There is also something very similar to trac that is built
  on ruby on rails that also integrates with mailing lists.
 
 Does that rails thing also have a bug tracker that integrates with
 mailing lists? IIRC the show-stopper on a bug tracker was finding one
 that allowed people to still use mailing lists.

AFAIU the showstopper was that people wanted to be able to _control_ the
bugtracker using email only, i.e. not forcing you to open a web browser
to do stuff like adding comments or attachments to a bug, or closing,
etc.

I'm not sure what you have in mind about integration between the
mailing lists and the bugtracker, because nothing else I can think of
makes much sense.  I'm always happy to be illuminated :-)

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] 8.2 features status

2006-08-10 Thread Lukas Smith

Tom Lane wrote:


Yeah, the main problem I have with TODO-on-a-wiki is the question of
quality control.  I've been heard to complain that the TODO list
consists of everything Bruce thinks is a good idea, but for the most
part things don't get onto TODO without some rough consensus on the
mailing lists --- at least about the nature of the problem, if not
the exact shape of the solution.  I'm worried about a wiki having pages
that have not been peer-reviewed at all.  In some respects that wouldn't
matter, but what of our hypothetical newbie developer coming along and
taking entries at face value?  If you don't know the project well enough
to recognize bogus entries, you could still end up wasting your time
on silly ideas that will get rejected once seen by a wider audience.


To bring up PHP again:
http://oss.backendmedia.com/PhP52

This is the todo list for the upcoming 5.2.0 release that is currently 
in RC1. Most of the todo items in PHP do not need much detail, so this 
list does not carry much more information than Bruce's list. The wiki 
has support for ACL's, so I have given various trusted people direct 
access. Some developers however rely on me for updating the items.


As you can see there is a confirmed (as in the release manager has oked 
the todo) and an under discussion as well as a future 5.x release 
section. We already have a separate todo list for php 6.


A todo list that illustrates the ability to attach more information for 
a given todo item is my PEAR::MDB2 list in the same wiki:

http://oss.backendmedia.com/MDB2/ToDo

regards,
Lukas

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [HACKERS] 8.2 features status

2006-08-10 Thread Dave Page


-Original Message-
From: Marc G. Fournier [EMAIL PROTECTED]
To: Dave Page dpage@vale-housing.co.uk
Cc: Jim C. Nasby [EMAIL PROTECTED]; Bruce Momjian [EMAIL PROTECTED]; 
Josh Berkus josh@agliodbs.com; Christopher Browne [EMAIL PROTECTED]; 
pgsql-hackers@postgresql.org pgsql-hackers@postgresql.org
Sent: 10/08/06 05:30
Subject: RE: [HACKERS] 8.2 features status

 Two words: House Hunting ...

Yeuch. Toronto?

 ... will post something to -www as 
soon as I have something up and running ...

Ok, cool.

/D

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] 8.2 features status

2006-08-10 Thread Josh Berkus
Marc,

  ... will post something to -www as

 soon as I have something up and running ...

Given that JD is already pulling something into a Trac instance, why don't we 
just try using that?  It has both an issue tracker and a wiki, and it's up 
and running now.   When we have a firmer idea what we want, we may move to 
different software, but why spend extra effort now?

-- 
Josh Berkus
PostgreSQL @ Sun
San Francisco

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] 8.2 features status

2006-08-10 Thread Merlin Moncure

On 8/9/06, Bruce Momjian [EMAIL PROTECTED] wrote:

Joshua D. Drake wrote:
 
  Until you have used this, it seems strange. After you start it doesn't ;-)
 
  Sure, but with openness comes cruft, which can be a problem too.  Do we
  want everyone's idea of a useful feature listed?  I don't.

 Why not as long as we have someone who can actually make approved
 todos versus wishlist type stuff.

So you want a wish-list wiki?  Great idea, I can link to it from the
TODO list.  Is that all people want?


just jumping in here but have you considered doing the todo list on a
wiki? fwiw, i find the todo list links to be pretty neat and helpful.
even for non-developers its a good way to get the feel about whats
going on with certain features so they can plan strategies around
them.

merlin

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq


Re: [HACKERS] 8.2 features status

2006-08-10 Thread Jim Nasby
First, +1 on Josh B.'s point about trying out Trac, since it's  
already up and running. Josh D., can you just turn that on? (BTW, is  
trac linked off http://commandprompt.com anywhere? I had to google to  
find it yesterday...)


On Aug 9, 2006, at 11:34 PM, Tom Lane wrote:

Mark Kirkwood [EMAIL PROTECTED] writes:

Robert Treat wrote:
Wouldn't a thread reply saying something like Bruce, can we add  
this as a

TODO with the following wording: blah blah blah  likely suffice?


That's pretty much how it's done now ...


Robert missed the point I was making... there is value in keeping  
track of ideas that may not have enough consensus to be a valid TODO  
yet, but could still be useful.


Yeah - and/or a patch to TODO or the relevant TODO.detail (I can't  
see
why that is hard or onerous). Plus it is seen by a wide audience,  
some

of whom might not be tracking any wiki (very likely if there end up
being several wiki's)


Yeah, the main problem I have with TODO-on-a-wiki is the question of
quality control.  I've been heard to complain that the TODO list
consists of everything Bruce thinks is a good idea, but for the most
part things don't get onto TODO without some rough consensus on the
mailing lists --- at least about the nature of the problem, if not
the exact shape of the solution.  I'm worried about a wiki having  
pages
that have not been peer-reviewed at all.  In some respects that  
wouldn't

matter, but what of our hypothetical newbie developer coming along and
taking entries at face value?  If you don't know the project well  
enough

to recognize bogus entries, you could still end up wasting your time
on silly ideas that will get rejected once seen by a wider audience.


Agreed... there needs to be enough consensus and 'critical mass'  
before something becomes an official TODO. Because of that, we  
shouldn't allow anyone to edit the TODO wiki (though I do think we  
shouldn't put the entire responsibility on Bruce).


A nice thing about a wiki is it makes it easy for people to  
collectively work on a use-case and design for a TODO item. One thing  
that could come out of this is the expectation that TODO items that  
aren't inherently obvious (however you define that) must come with  
X amount of documentation (use cases, design, what-have-you). This  
isn't something that should replace discussion on the mailing lists,  
but I think that being able to point to a wiki page with the  
finalized info about a TODO item is a lot better than pointing at  
list archives that are spread all over.

--
Jim C. Nasby, Sr. Engineering Consultant  [EMAIL PROTECTED]
Pervasive Software  http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf   cell: 512-569-9461



---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [HACKERS] 8.2 features status

2006-08-10 Thread Alvaro Herrera
Jim Nasby wrote:
 First, +1 on Josh B.'s point about trying out Trac, since it's  
 already up and running. Josh D., can you just turn that on? (BTW, is  
 trac linked off http://commandprompt.com anywhere? I had to google to  
 find it yesterday...)

I just noticed that the code repository on that Trac is broken in more
ways than I had realized.  For starters it doesn't seem to have the 8.1
branch or tags (apparently it's out of date).

Doesn't Trac have a CVS plugin?  It will just cause confusion to have a
SVN repo that doesn't reflect reality -- which it wouldn't even if it
weren't broken.

-- 
Alvaro Herrerahttp://www.CommandPrompt.com/
PostgreSQL Replication, Consulting, Custom Development, 24x7 support

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] 8.2 features status

2006-08-10 Thread Joshua D. Drake

Alvaro Herrera wrote:

Jim Nasby wrote:
First, +1 on Josh B.'s point about trying out Trac, since it's  
already up and running. Josh D., can you just turn that on? (BTW, is  
trac linked off http://commandprompt.com anywhere? I had to google to  
find it yesterday...)


I just noticed that the code repository on that Trac is broken in more
ways than I had realized.  For starters it doesn't seem to have the 8.1
branch or tags (apparently it's out of date).


It doesn't?

http://projects.commandprompt.com/public/pgsql/browser/tags/REL8_1_4/pgsql

What are you looking at Alvaro?



Doesn't Trac have a CVS plugin? 


No, like the rest of the world, Trac has moved on from CVS ;)


It will just cause confusion to have a
SVN repo that doesn't reflect reality


Well sure... but again... what are you looking at, because it looks fine 
to me?


And to be clear, I would only expect that this would be used as a 
reference, that is all. The ability to link from the wiki directly to a 
source file or changeset could be useful.


Sincerely,

Joshua D. Drake



--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 9: In versions below 8.0, the planner will ignore your desire to
  choose an index scan if your joining column's datatypes do not
  match


Re: [HACKERS] 8.2 features status

2006-08-10 Thread Joshua D. Drake

Alvaro Herrera wrote:

Jim Nasby wrote:
First, +1 on Josh B.'s point about trying out Trac, since it's  
already up and running. Josh D., can you just turn that on? (BTW, is  
trac linked off http://commandprompt.com anywhere? I had to google to  
find it yesterday...)


Oh and answer Jim's question. No isn't linked of www.cmd... why? I have 
no idea ;) It should be on our /community page.




I just noticed that the code repository on that Trac is broken in more
ways than I had realized.  For starters it doesn't seem to have the 8.1
branch or tags (apparently it's out of date).

Doesn't Trac have a CVS plugin?  It will just cause confusion to have a
SVN repo that doesn't reflect reality -- which it wouldn't even if it
weren't broken.




--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] 8.2 features status

2006-08-10 Thread Neil Conway
On Thu, 2006-08-10 at 17:33 -0700, Joshua D. Drake wrote:
 No, like the rest of the world, Trac has moved on from CVS ;)

There is CVSTrac (www.cvstrac.org), which actually predates Trac.

However, is there a reason to use Trac beyond the fact that it is
already setup? ISTM we only need a wiki, and don't need the other
features of Trac, such as the bug tracker.

-Neil



---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] 8.2 features status

2006-08-10 Thread Joshua D. Drake

Neil Conway wrote:

On Thu, 2006-08-10 at 17:33 -0700, Joshua D. Drake wrote:

No, like the rest of the world, Trac has moved on from CVS ;)


There is CVSTrac (www.cvstrac.org), which actually predates Trac.

However, is there a reason to use Trac beyond the fact that it is
already setup? ISTM we only need a wiki, and don't need the other
features of Trac, such as the bug tracker.


Well that is certainly the question but the bug tracker could easily 
turn into a todo list as well. It is a very powerful tool that is 
relatively flexible.


Joshua D. Drake




-Neil



---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq




--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [HACKERS] 8.2 features status

2006-08-10 Thread Bruce Momjian
Merlin Moncure wrote:
 On 8/9/06, Bruce Momjian [EMAIL PROTECTED] wrote:
  Joshua D. Drake wrote:
   
Until you have used this, it seems strange. After you start it doesn't 
;-)
   
Sure, but with openness comes cruft, which can be a problem too.  Do we
want everyone's idea of a useful feature listed?  I don't.
  
   Why not as long as we have someone who can actually make approved
   todos versus wishlist type stuff.
 
  So you want a wish-list wiki?  Great idea, I can link to it from the
  TODO list.  Is that all people want?
 
 just jumping in here but have you considered doing the todo list on a
 wiki? fwiw, i find the todo list links to be pretty neat and helpful.
 even for non-developers its a good way to get the feel about whats
 going on with certain features so they can plan strategies around
 them.

I don't see what a wiki would do for the TODO list except make it take
longer for me to update.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] 8.2 features status

2006-08-10 Thread Bruce Momjian
Jim Nasby wrote:
 First, +1 on Josh B.'s point about trying out Trac, since it's  
 already up and running. Josh D., can you just turn that on? (BTW, is  
 trac linked off http://commandprompt.com anywhere? I had to google to  
 find it yesterday...)
 
 On Aug 9, 2006, at 11:34 PM, Tom Lane wrote:
  Mark Kirkwood [EMAIL PROTECTED] writes:
  Robert Treat wrote:
  Wouldn't a thread reply saying something like Bruce, can we add  
  this as a
  TODO with the following wording: blah blah blah  likely suffice?
 
  That's pretty much how it's done now ...
 
 Robert missed the point I was making... there is value in keeping  
 track of ideas that may not have enough consensus to be a valid TODO  
 yet, but could still be useful.

It seems some people like the authoritative TODO list, and others want a
TODO wiki that they can add stuff to without having to get community
buy-in.  I have trouble seeing how the wiki doesn't just end up being a
blog of ideas, but I see no harm in it as long as it is clear the items
haven't passed community review.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] 8.2 features status

2006-08-10 Thread Joshua D. Drake


It seems some people like the authoritative TODO list, and others want a
TODO wiki that they can add stuff to without having to get community
buy-in.  I have trouble seeing how the wiki doesn't just end up being a
blog of ideas, but I see no harm in it as long as it is clear the items
haven't passed community review.


I think it is a combination of the two. A wiki could be used to discuss 
ideas for todos, it could be used to describe TODOs in actual detail, it 
could used (in conjunction with Trac) to be able to document dependecies 
for todos... etc.


Joshua D. Drake




--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [HACKERS] 8.2 features status

2006-08-10 Thread Bruce Momjian
Joshua D. Drake wrote:
  
  It seems some people like the authoritative TODO list, and others want a
  TODO wiki that they can add stuff to without having to get community
  buy-in.  I have trouble seeing how the wiki doesn't just end up being a
  blog of ideas, but I see no harm in it as long as it is clear the items
  haven't passed community review.
 
 I think it is a combination of the two. A wiki could be used to discuss 
 ideas for todos, it could be used to describe TODOs in actual detail, it 
 could used (in conjunction with Trac) to be able to document dependecies 
 for todos... etc.

But what is it likely to do?  I don't think much, but if we can shut it
down if we decide it isn't of value (unlike gborg which can't be shut
down), I think it is fine to try.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 4: Have you searched our list archives?

   http://archives.postgresql.org


Re: [HACKERS] 8.2 features status

2006-08-09 Thread Christopher Browne
Quoth [EMAIL PROTECTED] (Joshua D. Drake):
 Josh Berkus wrote:
 Bruce,

 What happens now is that someone says they want to work on X, and the
 community tells them that Y might be working on it, and Y gives us a
 status.

 What happens now is:
 A starts working on X.
 3 months pass
 B comes to hackers, spends hours reading the archives, doesn't find
 X (because they know it by a different name), comes to -hackers and
 asks Is anyone working on X?
 B waits for 2 weeks without an answer and repeats the question.
 Hackers E, F and G reply yes, someone is but I don't remember who,
 search the archives for keyword X

 I would bet, right about here we loose a whole lot of would be
 contributors.

 Just the the questions I had about two todos this year was enough
 basically give up on doing any work on them.

So I'm to take it that if nobody had *ever* pestered you about those
items, you would have been certain (or significantly more likely) to
get them done in time for 8.2?

I don't see this being a huge force for evil...  If people are so
easily discouraged that any attempt to account for what has been
promised will lead to its loss, then it seems to me that they
shouldn't have promised anything in the first place.

It's not a matter of having to send in weekly status reports; I would
think that pestering about status more than once every other month
is more than could be done.

And in terms of the community contract for taking on TODO items, it
does not strike me as unreasonable to be expected to report back on
status once every couple months.  That's not a heavy bureaucratic
burden.
-- 
output = (cbbrowne @ linuxfinances.info)
http://linuxfinances.info/info/wp.html
Rules of the  Evil Overlord #223. I will  install a fire extinguisher
in  every room  --  three, if  the  room contains  vital equipment  or
volatile chemicals. http://www.eviloverlord.com/

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] 8.2 features status

2006-08-09 Thread Joshua D. Drake

Christopher Browne wrote:

Quoth [EMAIL PROTECTED] (Joshua D. Drake):

Josh Berkus wrote:

Bruce,


What happens now is that someone says they want to work on X, and the
community tells them that Y might be working on it, and Y gives us a
status.


What happens now is:
A starts working on X.
3 months pass
B comes to hackers, spends hours reading the archives, doesn't find
X (because they know it by a different name), comes to -hackers and
asks Is anyone working on X?
B waits for 2 weeks without an answer and repeats the question.
Hackers E, F and G reply yes, someone is but I don't remember who,
search the archives for keyword X

I would bet, right about here we loose a whole lot of would be
contributors.

Just the the questions I had about two todos this year was enough
basically give up on doing any work on them.


So I'm to take it that if nobody had *ever* pestered you about those
items, you would have been certain (or significantly more likely) to
get them done in time for 8.2?


I think you are misreading my comment. I said:


I would bet, right about here we loose a whole lot of would be
contributors.

Just the the questions I had about two todos this year was enough
basically give up on doing any work on them.


Which was a positive reinforcement to:

 A starts working on X.
 3 months pass
 B comes to hackers, spends hours reading the archives, doesn't find
 X (because they know it by a different name), comes to -hackers and
 asks Is anyone working on X?
 B waits for 2 weeks without an answer and repeats the question.
 Hackers E, F and G reply yes, someone is but I don't remember who,
 search the archives for keyword X

My point was, I was going to work on some todos before feature freeze. I 
asked about two specific todos. One of them was badly worded and one of 
them did not represent (except in the smallest of ways) what it actually 
was.


The first one I bailed out of because it was entirely too much for me to 
do in terms of expertise.


The second one turned into a huge debate about not only what the todo 
was, but how it was to be implemented and it turned out the todo was all 
about pg_dump. Here is that todo:


%Add pg_get_acldef(), pg_get_typedefault(), pg_get_attrdef(), 
pg_get_tabledef(), pg_get_domaindef(), pg_get_functiondef()


I was under the impression that I would be writing some C or SQL 
functions to create some useful tidbits.


It took a couple of days just to get enough information to find out I 
was wrong. I was then going to think about possibly sponsoring the todo 
instead as it was out of my realm.


I decided to forget about it after waiting for everyone to figure out 
what they wanted.



Sincerely,

Joshua D. Drake


--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] 8.2 features status

2006-08-09 Thread [EMAIL PROTECTED]






 There's a LOT of unnecessary overhead in that process: having a  
 simple web app that lists who claimed what todo and when, any  
 status updates if they've voluntarily provided them, and links to  
 archive discussions, we could reduce the above to a 3-step process  
 making it vastly easier for new hackers to get started.

A developers' wiki with links into the list archives would be great.



My thoughts exactly...





--
 Korry Douglas [EMAIL PROTECTED]
 EnterpriseDB http://www.enterprisedb.com







Re: [HACKERS] 8.2 features status

2006-08-09 Thread Tom Lane
Joshua D. Drake [EMAIL PROTECTED] writes:
 My point was, I was going to work on some todos before feature freeze. I 
 asked about two specific todos. One of them was badly worded and one of 
 them did not represent (except in the smallest of ways) what it actually 
 was.

Well, it's certainly the case that some of the TODO items are vaguely
defined (because part of the TODO item is to figure out what to do)
and many of them are too complicated to explain well in one sentence.
But surely that's a different complaint from what's being discussed
in this thread?

What this story does do for me is reinforce the notion that it's
critical for newbie developers to work in the open, getting feedback
from the lists at an early stage about what they are doing.  If you go
off in a corner and develop a patch for a TODO item, you risk having it
rejected because you misunderstood what the TODO item was about.

Maybe the connection is that while thinking about processes, we need
to take into account the need to encourage people to get early
feedback about what they are considering doing.

regards, tom lane

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] 8.2 features status

2006-08-09 Thread Bruce Momjian
Tom Lane wrote:
 Joshua D. Drake [EMAIL PROTECTED] writes:
  My point was, I was going to work on some todos before feature freeze. I 
  asked about two specific todos. One of them was badly worded and one of 
  them did not represent (except in the smallest of ways) what it actually 
  was.
 
 Well, it's certainly the case that some of the TODO items are vaguely
 defined (because part of the TODO item is to figure out what to do)
 and many of them are too complicated to explain well in one sentence.
 But surely that's a different complaint from what's being discussed
 in this thread?

I have started adding URLs to the TODO items, which helps.

 What this story does do for me is reinforce the notion that it's
 critical for newbie developers to work in the open, getting feedback
 from the lists at an early stage about what they are doing.  If you go
 off in a corner and develop a patch for a TODO item, you risk having it
 rejected because you misunderstood what the TODO item was about.

Right, and the TODO items change over time as the system improves in
other ways.

 Maybe the connection is that while thinking about processes, we need
 to take into account the need to encourage people to get early
 feedback about what they are considering doing.

We say that clearly in the developer's FAQ, but it seems it is not
enough.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] 8.2 features status

2006-08-09 Thread Joshua D. Drake



What this story does do for me is reinforce the notion that it's
critical for newbie developers to work in the open, getting feedback
from the lists at an early stage about what they are doing.  If you go
off in a corner and develop a patch for a TODO item, you risk having it
rejected because you misunderstood what the TODO item was about.


I 100% agree with this. Newbie developers should be in the open and it 
kind of lends itself to my Mentors idea that I mentioned previously.


The problem I see is that even if they are in the open we make it fairly 
difficult to get the information they need to get started.




Maybe the connection is that while thinking about processes, we need
to take into account the need to encourage people to get early
feedback about what they are considering doing.


Agreed.

Sincerely,

Joshua D. Drake




regards, tom lane




--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

  http://www.postgresql.org/docs/faq


Re: [HACKERS] 8.2 features status

2006-08-09 Thread Joshua D. Drake



Maybe the connection is that while thinking about processes, we need
to take into account the need to encourage people to get early
feedback about what they are considering doing.


We say that clearly in the developer's FAQ, but it seems it is not
enough.


I just read the developer's FAQ, and just so were all honest I never had 
before. :). The developers FAQ is actually quite useful, and helpful 
except for this one part:



Outstanding features are detailed in the TODO list. This is located in 
doc/TODO in the source distribution or at 
http://www.postgresql.org/docs/faqs.TODO.html.


You can learn more about these features by consulting the archives, the 
SQL standards and the recommend texts (see 1.10).


No one wants to consult the archives. Nor do I believe they should have 
to. I want a link, directly off the TODO line item that states specific 
references on one page of what is requested. This is where the wiki 
comes in.


It would also be useful to have possible dependencies. I recently saw
a patch come across from Sun, that Tom commented on, something about 
increase the size of some value to 64bit. I don't recall exactly.


Tom's comments although valid (as usual :)) were that the person missed
a bunch of stuff having to do with the planner.

Some of us may think... well of course that is obvious...

Well either the Sun guy was just lazy, or it isn't obvious. I prefer to 
think it is not obvious.


From Bruce's perspective this actually doesn't add too much to the 
workload. Generate the link, possibly paste some archive urls into the 
wiki and then someone can come behind and clean up.


Of course, who is the clean up guy is always a question.

Sincerely,

Joshua D. Drake


--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 5: don't forget to increase your free space map settings


Re: [HACKERS] 8.2 features status

2006-08-09 Thread Bruce Momjian
Joshua D. Drake wrote:
 
  Maybe the connection is that while thinking about processes, we need
  to take into account the need to encourage people to get early
  feedback about what they are considering doing.
  
  We say that clearly in the developer's FAQ, but it seems it is not
  enough.
 
 I just read the developer's FAQ, and just so were all honest I never had 
 before. :). The developers FAQ is actually quite useful, and helpful 
 except for this one part:
 
 
 Outstanding features are detailed in the TODO list. This is located in 
 doc/TODO in the source distribution or at 
 http://www.postgresql.org/docs/faqs.TODO.html.
 
 You can learn more about these features by consulting the archives, the 
 SQL standards and the recommend texts (see 1.10).
 
 No one wants to consult the archives. Nor do I believe they should have 
 to. I want a link, directly off the TODO line item that states specific 
 references on one page of what is requested. This is where the wiki 
 comes in.

We now have URLs on the TODO list to the archives, and the next FAQ item
is:

H3 id=item1.41.4) What do I do after choosing an item to
work on?/H3

PSend an email to pgsql-hackers with a proposal for what you want
to do (assuming your contribution is not trivial). Working in

so it is clear what we want people to do.

 It would also be useful to have possible dependencies. I recently saw
 a patch come across from Sun, that Tom commented on, something about 
 increase the size of some value to 64bit. I don't recall exactly.
 
 Tom's comments although valid (as usual :)) were that the person missed
 a bunch of stuff having to do with the planner.
 
 Some of us may think... well of course that is obvious...
 
 Well either the Sun guy was just lazy, or it isn't obvious. I prefer to 
 think it is not obvious.
 
 From Bruce's perspective this actually doesn't add too much to the 
 workload. Generate the link, possibly paste some archive urls into the 
 wiki and then someone can come behind and clean up.

I am keeping URLs in the TODO list.  Why don't people submit
improvements to the TODO list, rather than adding more complexity by
making a separate wiki for every TODO item?  If no one updates the TODO
item, what makes you think they are going to do somethin in a wiki?

I think the big conclusion we made long ago is that We are never going
to have enough detail anywhere that someone is going to be able to work
on an item without asking the community.

-- 
  Bruce Momjian   [EMAIL PROTECTED]
  EnterpriseDBhttp://www.enterprisedb.com

  + If your life is a hard drive, Christ can be your backup. +

---(end of broadcast)---
TIP 2: Don't 'kill -9' the postmaster


Re: [HACKERS] 8.2 features status

2006-08-09 Thread Jim C. Nasby
On Wed, Aug 09, 2006 at 08:21:41AM -0700, Joshua D. Drake wrote:
 From Bruce's perspective this actually doesn't add too much to the 
 workload. Generate the link, possibly paste some archive urls into the 
 wiki and then someone can come behind and clean up.

Or better yet, if editing the TODO is more accessible then we're not
dependent on one person to maintain it.
-- 
Jim C. Nasby, Sr. Engineering Consultant  [EMAIL PROTECTED]
Pervasive Software  http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf   cell: 512-569-9461

---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
   subscribe-nomail command to [EMAIL PROTECTED] so that your
   message can get through to the mailing list cleanly


Re: [HACKERS] 8.2 features status

2006-08-09 Thread Joshua D. Drake



We now have URLs on the TODO list to the archives, and the next FAQ item
is:

H3 id=item1.41.4) What do I do after choosing an item to
work on?/H3

PSend an email to pgsql-hackers with a proposal for what you want
to do (assuming your contribution is not trivial). Working in

so it is clear what we want people to do.


what we want my be part of the problem :)




It would also be useful to have possible dependencies. I recently saw
a patch come across from Sun, that Tom commented on, something about 
increase the size of some value to 64bit. I don't recall exactly.


I am keeping URLs in the TODO list.  Why don't people submit
improvements to the TODO list, rather than adding more complexity by
making a separate wiki for every TODO item?  If no one updates the TODO
item, what makes you think they are going to do somethin in a wiki?


Do you want a todo list with 4 paragraphs (minimum) for each todo item?



I think the big conclusion we made long ago is that We are never going
to have enough detail anywhere that someone is going to be able to work
on an item without asking the community.


I don't think anyone is expecting that. I think that what we are 
expecting is that they can ask knowledgeable questions.


Would you prefer:

Hi, I am a C developer, PostgreSQL Rocks... I want to implement Enums..

Or:

Hi, I am a C developer, PostgreSQL Rocks... I would like to take the 
Enums todo. Here are my specific questions regarding your feature 
requirements at URL ---


Joshua D. Drake







--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 6: explain analyze is your friend


Re: [HACKERS] 8.2 features status

2006-08-09 Thread Joshua D. Drake

Jim C. Nasby wrote:

On Wed, Aug 09, 2006 at 08:21:41AM -0700, Joshua D. Drake wrote:
From Bruce's perspective this actually doesn't add too much to the 
workload. Generate the link, possibly paste some archive urls into the 
wiki and then someone can come behind and clean up.


Or better yet, if editing the TODO is more accessible then we're not
dependent on one person to maintain it.


To be fair, Bruce has offered to allow that to happen even on his home 
machine (Bruce that is a bad idea btw) and ANYONE can submit a patch. It 
may not be a web interface that people could log into but it is entirely 
possible to contribute back with it.


Joshua D. Drake


--

   === The PostgreSQL Company: Command Prompt, Inc. ===
Sales/Support: +1.503.667.4564 || 24x7/Emergency: +1.800.492.2240
   Providing the most comprehensive  PostgreSQL solutions since 1997
 http://www.commandprompt.com/



---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


Re: [HACKERS] 8.2 features status

2006-08-09 Thread Jim C. Nasby
On Tue, Aug 08, 2006 at 10:31:00PM -0400, Bruce Momjian wrote:
 bruce wrote:
  bruce wrote:
   
   OK, seems this should be a separate application, not done in the TODO
   list, and I am not willing to take on that additional workload.
  
  Let me add that anyone who has CVS commit access or wants to submit
  TODO patches can keep the TODO updated in this way.
 
 I can also give someone ssh access to my server with the ability to
 modify only the TODO list.

I've never submitted patches for the TODO because it seems pretty silly
to go through that much work just to add one line to a file, but being
able to change it directly would be a good compromise. I'd be happy to
help.

Something else that bugs me about the current TODO process is there's a
lot of ideas that get brought up but never make it on there. Certainly
a lot of them aren't worth putting on there, but there's plenty of items
that get left on the floor. It would be nice if there was a better way
to deal with these ideas.

One possibility: have a 'holding area' (perhaps on a Wiki) where users
could add use-cases for these ideas. If there's 'enough demand' (however
one defines that), they get promoted to the TODO. Note that this is
something geared towards users... things that are obviously useful to
-hackers tend to get on the list.
-- 
Jim C. Nasby, Sr. Engineering Consultant  [EMAIL PROTECTED]
Pervasive Software  http://pervasive.comwork: 512-231-6117
vcard: http://jim.nasby.net/pervasive.vcf   cell: 512-569-9461

---(end of broadcast)---
TIP 3: Have you checked our extensive FAQ?

   http://www.postgresql.org/docs/faq


Re: [HACKERS] 8.2 features status

2006-08-09 Thread Andrew Dunstan

Bruce Momjian wrote:



I am keeping URLs in the TODO list.  Why don't people submit
improvements to the TODO list, rather than adding more complexity by
making a separate wiki for every TODO item?  If no one updates the TODO
item, what makes you think they are going to do somethin in a wiki?
  


You can update a wiki instantly. Unless you are a committer, updating 
the TODO list involves sending in a patch.


It should be added that the idea that the TODO list has much authority 
has been decried in the past.



I think the big conclusion we made long ago is that We are never going
to have enough detail anywhere that someone is going to be able to work
on an item without asking the community.
  


Wikis take a tiny bit of getting used to. But they are extremely useful  
- they can be used like a kind of online notebook. I find it much easier 
to make progress notes, reminders, etc in a wiki than in a notebook that 
I forget to take with me half the time. And they are thus also a great 
place to record progress.


Until you have used this, it seems strange. After you start it doesn't ;-)

cheers

andrew



---(end of broadcast)---
TIP 1: if posting/reading through Usenet, please send an appropriate
  subscribe-nomail command to [EMAIL PROTECTED] so that your
  message can get through to the mailing list cleanly


  1   2   3   >