Обсуждение: Re: [CORE] Re: [Keystone Slip # 22] Some confusion with datetimedata type andtimezone
Re: [CORE] Re: [Keystone Slip # 22] Some confusion with datetimedata type andtimezone
От
Thomas Lockhart
Дата:
> > I have no problems with this...I heard an outcry for a bug-tracking
> > system, and this was the better known one, so installed it. If ya wanna
> > trash it, be my guest...I have no attachments to it :)
> If you're gonna trash it, let me know slightly in advance so I can remove
> the announcement and news entry (it's only a couple of mouse clicks).
We are not going to trash it, but we *must* evolve how it will be
used. (btw, I've taken this on-list per Tom Lane's suggestion; the
short summary is that the new bug tracking system is getting non-bug
bug reports and it is short-circuiting the highly successful mailing
list support process.)
Can you change the announcement to state something like:
We have installed a new bug tracking system. After reading
documentation, checking the tracking system, *and* asking for help on
the mailing lists, you may be directed to enter your problem statement
into the system. Please do *not* enter a new report unless it is a
confirmed bug or problem.
This wording should get us some breathing room. Comments?
- Thomas
--
Thomas Lockhart lockhart@alumni.caltech.edu
South Pasadena, California
Thomas Lockhart <lockhart@alumni.caltech.edu> writes: > (btw, I've taken this on-list per Tom Lane's suggestion; the > short summary is that the new bug tracking system is getting non-bug > bug reports and it is short-circuiting the highly successful mailing > list support process.) Just to give everyone else some context (and try to get a more useful title on the thread ;-)), this discussion concerns the Keystone bug tracking system that was recently installed on www.postgresql.org; see http://www.PostgreSQL.ORG/bugs/nbrowse.php3. There is some sketchy documentation about Keystone at http://www.stonekeep.com/ksonline/docs/docindex.html. Now that we've got the thing, we need to figure out an effective process for using it. The limited experience so far doesn't seem particularly productive. Here are some comments that I sent to the core group earlier today. Thomas Lockhart <lockhart@alumni.caltech.edu> writes: > We've got a *great* network of folks on the mailing lists who help > everyone with questions. That should be the first (and second, and > third) line of defense for anyone with a question or a possible bug > report, and imho we shouldn't have *anything* in the bug tracking > system which has not gone through that process first. > How do we accomplish this without having a completely closed bug > reporting system (which for me is one of the options; Bruce could use > this for his bug-related ToDo's...). Hmm, so you are thinking it should be a *tracking* system for acknowledged bugs, but not an initial reporting system, and we'd continue to rely on the mail lists for initial reporting. That might not be a bad idea. I've already noticed that people are failing to provide full bug reports (version, platform, etc) because the Keystone system doesn't give them a template to fill out. Seems like we were getting more complete reports via the email process. > Should we consider having a more limited number of folks with access > to the bug tracking system? Perhaps this could be a perk for long-time > contributors who go out of their way to help answer questions?? We want read-only access for everyone, I think, but limiting the number of people who can enter and update slips might be good. My reasons for pushing a BTS in the first place were that it would provide better *visibility* : has a bug been fixed, who is working on it, what is known about it, etc. Basically I was thinking of a TODO list with more detail per item than a one-line summary. (Also it should keep records of closed-out problems, so people could find out what version fixes a problem.) Cluttering the BTS database with random reports doesn't aid visibility of the important ones. We want to allow read-only access so that status is visible to everyone, but that doesn't mean we have to allow everyone to alter the database. This line of thought also suggests that we should immediately enter all the TODO items into the BTS as slips... Bruce could then generate the text TODO via a query from the DB ;-) Further comments, anyone? regards, tom lane
I wrote: > see http://www.PostgreSQL.ORG/bugs/nbrowse.php3. Er, make that http://www.PostgreSQL.ORG/bugs/visitor.php3 if you're not one of the people known to the Keystone system... regards, tom lane
On 27-Jul-99 Thomas Lockhart wrote:
>> > I have no problems with this...I heard an outcry for a bug-tracking
>> > system, and this was the better known one, so installed it. If ya wanna
>> > trash it, be my guest...I have no attachments to it :)
>> If you're gonna trash it, let me know slightly in advance so I can remove
>> the announcement and news entry (it's only a couple of mouse clicks).
>
> We are not going to trash it, but we *must* evolve how it will be
> used. (btw, I've taken this on-list per Tom Lane's suggestion; the
> short summary is that the new bug tracking system is getting non-bug
> bug reports and it is short-circuiting the highly successful mailing
> list support process.)
>
> Can you change the announcement to state something like:
>
>
> We have installed a new bug tracking system. After reading
> documentation, checking the tracking system, *and* asking for help on
> the mailing lists, you may be directed to enter your problem statement
> into the system. Please do *not* enter a new report unless it is a
> confirmed bug or problem.
>
>
> This wording should get us some breathing room. Comments?
Done.
Vince.
--
==========================================================================
Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null # include <std/disclaimers.h>
TEAM-OS2 Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore
http://www.cloudninegifts.com
==========================================================================
Just a thought, but we know *what* we want...why not build our own? Or, is there something else out there that would better serve what we need? Personally, my playing with Keystone leaves much to be desired, and the mailing list for it, quite frankly, is totally unresponsive. (ie. no questions asked have turned up an answer)...if someone has something better they would like to suggest, I have no problems setting it up and running through it. If someone thinks they have the time, energy and desire to work on one from scratch, tailoring it to our requirements, let me know that also...I'll provide you with an account and the resources... The idea is to come up with something clean, easy to use and fully functional...something that ppl *will* use. I don't think Keystone is that, but I haven't seen anything closer/better to what we require... On Tue, 27 Jul 1999, Tom Lane wrote: > Thomas Lockhart <lockhart@alumni.caltech.edu> writes: > > (btw, I've taken this on-list per Tom Lane's suggestion; the > > short summary is that the new bug tracking system is getting non-bug > > bug reports and it is short-circuiting the highly successful mailing > > list support process.) > > Just to give everyone else some context (and try to get a more useful > title on the thread ;-)), this discussion concerns the Keystone bug > tracking system that was recently installed on www.postgresql.org; > see http://www.PostgreSQL.ORG/bugs/nbrowse.php3. There is some > sketchy documentation about Keystone at > http://www.stonekeep.com/ksonline/docs/docindex.html. > > Now that we've got the thing, we need to figure out an effective process > for using it. The limited experience so far doesn't seem particularly > productive. Here are some comments that I sent to the core group > earlier today. > > > Thomas Lockhart <lockhart@alumni.caltech.edu> writes: > > We've got a *great* network of folks on the mailing lists who help > > everyone with questions. That should be the first (and second, and > > third) line of defense for anyone with a question or a possible bug > > report, and imho we shouldn't have *anything* in the bug tracking > > system which has not gone through that process first. > > > How do we accomplish this without having a completely closed bug > > reporting system (which for me is one of the options; Bruce could use > > this for his bug-related ToDo's...). > > Hmm, so you are thinking it should be a *tracking* system for > acknowledged bugs, but not an initial reporting system, and we'd > continue to rely on the mail lists for initial reporting. > > That might not be a bad idea. I've already noticed that people > are failing to provide full bug reports (version, platform, etc) > because the Keystone system doesn't give them a template to fill out. > Seems like we were getting more complete reports via the email process. > > > Should we consider having a more limited number of folks with access > > to the bug tracking system? Perhaps this could be a perk for long-time > > contributors who go out of their way to help answer questions?? > > We want read-only access for everyone, I think, but limiting the number > of people who can enter and update slips might be good. > > My reasons for pushing a BTS in the first place were that it would > provide better *visibility* : has a bug been fixed, who is working > on it, what is known about it, etc. Basically I was thinking of a > TODO list with more detail per item than a one-line summary. (Also > it should keep records of closed-out problems, so people could find > out what version fixes a problem.) > > Cluttering the BTS database with random reports doesn't aid visibility > of the important ones. We want to allow read-only access so that status > is visible to everyone, but that doesn't mean we have to allow everyone > to alter the database. > > This line of thought also suggests that we should immediately enter > all the TODO items into the BTS as slips... Bruce could then generate > the text TODO via a query from the DB ;-) > > Further comments, anyone? > > regards, tom lane > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
> > Just a thought, but we know *what* we want...why not build our own? Or, > is there something else out there that would better serve what we need? > > Personally, my playing with Keystone leaves much to be desired, and the > mailing list for it, quite frankly, is totally unresponsive. (ie. no > questions asked have turned up an answer)...if someone has something > better they would like to suggest, I have no problems setting it up and > running through it. They obviously need better bug tracking software. :-) -- Bruce Momjian | http://www.op.net/~candle maillist@candle.pha.pa.us | (610) 853-3000+ If your life is a hard drive, | 830 Blythe Avenue + Christ can be your backup. | Drexel Hill, Pennsylvania19026
On Tue, 27 Jul 1999, Bruce Momjian wrote:
> >
> > Just a thought, but we know *what* we want...why not build our own? Or,
> > is there something else out there that would better serve what we need?
> >
> > Personally, my playing with Keystone leaves much to be desired, and the
> > mailing list for it, quite frankly, is totally unresponsive. (ie. no
> > questions asked have turned up an answer)...if someone has something
> > better they would like to suggest, I have no problems setting it up and
> > running through it.
>
> They obviously need better bug tracking software. :-)
*grin*
Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy
Systems Administrator @ hub.org
primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org
Belay my last comment then...if this satisfies everyoen for now... On Tue, 27 Jul 1999, Vince Vielhaber wrote: > > On 27-Jul-99 Thomas Lockhart wrote: > >> > I have no problems with this...I heard an outcry for a bug-tracking > >> > system, and this was the better known one, so installed it. If ya wanna > >> > trash it, be my guest...I have no attachments to it :) > >> If you're gonna trash it, let me know slightly in advance so I can remove > >> the announcement and news entry (it's only a couple of mouse clicks). > > > > We are not going to trash it, but we *must* evolve how it will be > > used. (btw, I've taken this on-list per Tom Lane's suggestion; the > > short summary is that the new bug tracking system is getting non-bug > > bug reports and it is short-circuiting the highly successful mailing > > list support process.) > > > > Can you change the announcement to state something like: > > > > > > We have installed a new bug tracking system. After reading > > documentation, checking the tracking system, *and* asking for help on > > the mailing lists, you may be directed to enter your problem statement > > into the system. Please do *not* enter a new report unless it is a > > confirmed bug or problem. > > > > > > This wording should get us some breathing room. Comments? > > Done. > > Vince. > -- > ========================================================================== > Vince Vielhaber -- KA8CSH email: vev@michvhf.com flame-mail: /dev/null > # include <std/disclaimers.h> TEAM-OS2 > Online Campground Directory http://www.camping-usa.com > Online Giftshop Superstore http://www.cloudninegifts.com > ========================================================================== > > Marc G. Fournier ICQ#7615664 IRC Nick: Scrappy Systems Administrator @ hub.org primary: scrappy@hub.org secondary: scrappy@{freebsd|postgresql}.org