Обсуждение: bugs - lets call an exterminator!
In the seemingly hundreds of thousands of messages on the bug database topic I think I've come up with the following.. Needs ----------------------------------------------------------------------- easy reporting of bugs - sent to bugs list easy lookup of previous bugs summary of fix or workaround detail of fix or work around little to no intervention of developers ability of developer to add comments That should sum it up. Now some history.. Over the last couple of years we've tried a number (5 I think) of bug tracking packages. Either Marc or me or both have had to learn it, install it, get it going and the result has been the same - the maintainers don't want to update it, it's a pain in the ass to administrator, set up, etc. The current bugtool. After a bunch of these failures I asked for input on what was needed in a tool. Web input interface, ability to track the bug report, email notification to the bug list, email notification to the reporter of the bug. The current bugtool does this, however the maintainers don't want to close the reports. I'm not faulting them, they're doing their jobs by fixing the bugs and reporting them to the bugs list. Updating the database. We've had a couple of volunteers to keep the database up to date. Is it enough? I dunno, if I were to guess I'd have to look at previous experience and say probably not. But I don't want that to discourage anything or anyone. Realities PostgreSQL is growing by leaps and bounds. Ross pointed out this fact earlier today. A solution has to happen and it has to happen now. If a tool is to be adapted to this task it will be the one I'm most familiar with - the current one. Solution.. Is implementing yet another bugtool going to be the solution? Probably not. Do I want to go for number six? No. Of the ideas posted, these stick out: o Web inputo Minimal staff involvemento Maximal mailing list reportingo Historyo Searchability Here's what I propose. The current tool has a form - we keep it. The current tool mails to the bugs list - we keep it. Rather than searching the bugs list for open bugs that may not even be open, the search tool will need to search not only the database but it needs to also search the archives. For now (until the 400+ are classified) the search should/will search the bugs mailing list rather than the database. Recruit more than two people to help update the bugs database. After the database is somewhat up to date, include it into the normal search mechanism. Now then.. The folks that actually fix things, will this suffice as a start to our shortcomingss? If not, what is missing?? If so, let me know and I'll implement this in the short term. Silence at this time is definitely NOT A GOOD THING!!! Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
Vince Vielhaber <vev@michvhf.com> writes: > Now some history.. Over the last couple of years we've tried a > number (5 I think) of bug tracking packages. Either Marc or me > or both have had to learn it, install it, get it going and the > result has been the same - the maintainers don't want to update > it, it's a pain in the ass to administrator, set up, etc. > > The current bugtool. > > After a bunch of these failures I asked for input on what was > needed in a tool. Web input interface, ability to track the > bug report, email notification to the bug list, email notification > to the reporter of the bug. FTR, we're using bugzilla for this and it works great. We're working on porting it PostgreSQL. ftp://people.redhat.com/dkl/ should contain a recent state -- Trond Eivind Glomsrød Red Hat, Inc.
On Tue, 21 Aug 2001, Vince Vielhaber wrote: > > In the seemingly hundreds of thousands of messages on the bug database > topic I think I've come up with the following.. > > Solution.. > > Is implementing yet another bugtool going to be the solution? > Probably not. Do I want to go for number six? No. > > > The current tool has a form - we keep it. > The current tool mails to the bugs list - we keep it. You are correct on implementing another bug reporting tool - why re-invent the wheel? Why not use the bugzilla project for bug tracking? I do believe it has a postgresql backend by now and if it doesn't - I am sure it will soon or would be trivial to make a backend and contribute it back. This tool has been popularized by Mozilla and RedHat ... saying that I am sure the couple of RedHat employees on the list wouldn't mind giving a hand with setup and what not (though they will have to speak for themselves on this issues). -- //========================================================\\ || D. Hageman <dhageman@dracken.com> || \\========================================================//
At 20:08 21/08/01 -0400, Vince Vielhaber wrote: > >In the seemingly hundreds of thousands of messages on the bug database >topic I think I've come up with the following.. Your first pass needs to have a simple mail and web based ssystem for developers to at least close bugs. The CC idea is probably fine. You might even want to put an X-header in the mail message, then for each bugs list message automatically generate a footer with a web link to close the bug, or some such - a bit like the TIPs we get all the time. This way, a developer can go to any message relating to the bug, click on the link & close it. This should also send off a message to the list etc. Also, to make the jobs of the volunteers easier, it would be good for each bug details page sho show a list of bugs mailing list trafic relating to the bug, sorted by inverse date order (or, better, sub-threads). Then we can look in the most recent two or three to check the status... ---------------------------------------------------------------- Philip Warner | __---_____ Albatross Consulting Pty. Ltd. |----/ - \ (A.B.N. 75 008 659 498) | /(@) ______---_ Tel: (+61) 0500 83 82 81 | _________ \ Fax: (+61) 0500 83 82 82 | ___________ | Http://www.rhyme.com.au | / \| | --________-- PGP key available upon request, | / and from pgp5.ai.mit.edu:11371 |/
Vince Vielhaber <vev@michvhf.com> writes:
> Needs
> easy reporting of bugs - sent to bugs list
> easy lookup of previous bugs
> summary of fix or workaround
> detail of fix or work around
> little to no intervention of
> developers
> ability of developer to add
> comments
> That should sum it up.
Check.
> We've had a couple of volunteers to keep the database up to date.
> Is it enough? I dunno, if I were to guess I'd have to look at
> previous experience and say probably not.
AFAIR, we had *zero* people paying any attention to the state of the
bug database up to now. A couple of people ought to make a big
difference.
> Is implementing yet another bugtool going to be the solution?
> Probably not. Do I want to go for number six? No.
If you're the man maintaining it then I'm certainly not going to tell
you how to do your job. OTOH --- it does seem like a lot of people
like Bugzilla. Might be worth at least a cursory look.
> Here's what I propose.
> The current tool has a form - we keep it.
> The current tool mails to the bugs list - we keep it.
Those are both fine. How do we get feedback in the other direction,
ie mailing lists to bug database? That's the $64 question in my mind
at the moment.
regards, tom lane
I think it'd be not so difficult to extend our mailware (fts.postgresql.org) to handle bug-list. Actually, mailware has much more features, it's already has search/read, track features. Adding post is trivial. Developers (who actually fix a bugs) usually read mailing lists and reply's to BUG, which should be automatically go to corresponding bug-thread. Oleg On Tue, 21 Aug 2001, Tom Lane wrote: > Vince Vielhaber <vev@michvhf.com> writes: > > Needs > > > easy reporting of bugs - sent to bugs list > > easy lookup of previous bugs > > summary of fix or workaround > > detail of fix or work around > > little to no intervention of > > developers > > ability of developer to add > > comments > > > That should sum it up. > > Check. > > > We've had a couple of volunteers to keep the database up to date. > > Is it enough? I dunno, if I were to guess I'd have to look at > > previous experience and say probably not. > > AFAIR, we had *zero* people paying any attention to the state of the > bug database up to now. A couple of people ought to make a big > difference. > > > Is implementing yet another bugtool going to be the solution? > > Probably not. Do I want to go for number six? No. > > If you're the man maintaining it then I'm certainly not going to tell > you how to do your job. OTOH --- it does seem like a lot of people > like Bugzilla. Might be worth at least a cursory look. > > > Here's what I propose. > > > The current tool has a form - we keep it. > > The current tool mails to the bugs list - we keep it. > > Those are both fine. How do we get feedback in the other direction, > ie mailing lists to bug database? That's the $64 question in my mind > at the moment. > > regards, tom lane > > ---------------------------(end of broadcast)--------------------------- > TIP 3: if posting/reading through Usenet, please send an appropriate > subscribe-nomail command to majordomo@postgresql.org so that your > message can get through to the mailing list cleanly > Regards, Oleg _____________________________________________________________ Oleg Bartunov, sci.researcher, hostmaster of AstroNet, Sternberg Astronomical Institute, Moscow University (Russia) Internet: oleg@sai.msu.su, http://www.sai.msu.su/~megera/ phone: +007(095)939-16-83, +007(095)939-23-83
On Tue, 21 Aug 2001, D. Hageman wrote: > On Tue, 21 Aug 2001, Vince Vielhaber wrote: > > > > > In the seemingly hundreds of thousands of messages on the bug database > > topic I think I've come up with the following.. > > > > Solution.. > > > > Is implementing yet another bugtool going to be the solution? > > Probably not. Do I want to go for number six? No. > > > > > > The current tool has a form - we keep it. > > The current tool mails to the bugs list - we keep it. > > You are correct on implementing another bug reporting tool - why re-invent > the wheel? Why not use the bugzilla project for bug tracking? I do > believe it has a postgresql backend by now and if it doesn't - I am sure > it will soon or would be trivial to make a backend and contribute it back. > This tool has been popularized by Mozilla and RedHat ... saying that I am > sure the couple of RedHat employees on the list wouldn't mind giving a > hand with setup and what not (though they will have to speak for > themselves on this issues). Everybody keeps saying bugzilla. What EXACTLY will bugzilla do for us that would make me want to learn it and install it? BTW, the current wheel was invented a year ago 'cuze nothing really fit what we needed. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
Vince asks: > Everybody keeps saying bugzilla. What EXACTLY will bugzilla do for us > that would make me want to learn it and install it? BTW, the current > wheel was invented a year ago 'cuze nothing really fit what we needed. The reasons I would choose Bugzilla: 1. It's *not* written by us so (in theory) we don't have to waste time developing yet another bug tracking solution. 2. It sends email to people involved with a bug whenever the detail associated with that bug is modified. This includes the reporter, who often will feedback that it now works, at which time the fixer or the reporter can mark the bug as fixed. 3. It complains when a NEW bug hasn't been looked at for /n/ days -- this means that any not-a-bug's will be closed, while any that are really bugs will be accepted. 4. Good query facilities, if a little complex to use. 5. I think Bugzilla's concepts of products, components and versions fit the way we work. I envisage that 'Postgres', 'Interfaces', 'Languages' might be products that we would have. Within 'Postgres' we would have the various subsystems that make up the core. Within 'Interfaces' we would have 'JDBC', 'ODBC' etc. Within 'Languages' we would have 'PL/pgSQL' etc. Arguments accepted. There are other tools the Mozilla project uses that we could also use: Tinderbox -- continuous automated builds, including subsequent regression tests (useful for seeing who broke CVS). Bonsai -- CVS integration for Bugzilla Cheers, Colin
On Thu, 23 Aug 2001, Colin 't Hart wrote: > Vince asks: > > > Everybody keeps saying bugzilla. What EXACTLY will bugzilla do for us > > that would make me want to learn it and install it? BTW, the current > > wheel was invented a year ago 'cuze nothing really fit what we needed. > > The reasons I would choose Bugzilla: > > 1. It's *not* written by us so (in theory) we don't have to waste time > developing yet another bug tracking solution. What we have is already developed and refining it isn't a problem. > 2. It sends email to people involved with a bug whenever the detail > associated with that bug is modified. This includes the reporter, who > often will feedback that it now works, at which time the fixer or the > reporter can mark the bug as fixed. What we have already does this, but noone was using it. > 3. It complains when a NEW bug hasn't been looked at for /n/ days -- > this means that any not-a-bug's will be closed, while any that are > really bugs will be accepted. This would piss off the developers. > 4. Good query facilities, if a little complex to use. Please elaborate. > 5. I think Bugzilla's concepts of products, components and versions fit > the way we work. > I envisage that 'Postgres', 'Interfaces', 'Languages' might be products > that we would have. > Within 'Postgres' we would have the various subsystems that make up the > core. > Within 'Interfaces' we would have 'JDBC', 'ODBC' etc. > Within 'Languages' we would have 'PL/pgSQL' etc. I can see a little benefit to this, but for the most part the same people that are working on the core pieces of PostgreSQL are also working on the interfaces and languages. Vince. -- ========================================================================== Vince Vielhaber -- KA8CSH email: vev@michvhf.com http://www.pop4.net 56K Nationwide Dialup from $16.00/mo atPop4 Networking Online Campground Directory http://www.camping-usa.com Online Giftshop Superstore http://www.cloudninegifts.com ==========================================================================
Vince Vielhaber <vev@michvhf.com> writes:
> On Thu, 23 Aug 2001, Colin 't Hart wrote:
>> 5. I think Bugzilla's concepts of products, components and versions fit
>> the way we work.
>> I envisage that 'Postgres', 'Interfaces', 'Languages' might be products
>> that we would have.
>> Within 'Postgres' we would have the various subsystems that make up the
>> core.
>> Within 'Interfaces' we would have 'JDBC', 'ODBC' etc.
>> Within 'Languages' we would have 'PL/pgSQL' etc.
> I can see a little benefit to this, but for the most part the same
> people that are working on the core pieces of PostgreSQL are also
> working on the interfaces and languages.
I would argue against subdividing a bug database at all. I don't think
the project is large enough to require it (we are in no danger of
becoming the size of Mozilla anytime soon). But more importantly,
subdivision introduces the risk of misclassification of a bug --- and
in my experience the initial reporter of a bug *very* frequently
misidentifies where the problem is. So unless additional effort is
expended to reclassify bugs (is that even possible in Bugzilla?), the
classification will degenerate to the point of being a hindrance rather
than a help in locating things. Overall I just don't see that much
benefit from a classification system.
regards, tom lane
Tom Lane wrote: > it does seem like a lot of people > like Bugzilla. Might be worth at least a cursory look. We do use Bugzilla and I believe is a very good tool, which should fit nicely with the open development style of PostgreSQL community. New version is due in a few weeks and it's been already noted that a PostgreSQL backend is almost ready. The Bugzilla community is growing fast, BTW. -- Alessio F. Bragadini alessio@albourne.com APL Financial Services http://village.albourne.com Nicosia, Cyprus phone: +357-2-755750 "It is more complicated than you think" -- The Eighth Networking Truth from RFC 1925
Vince Vielhaber wrote: > Everybody keeps saying bugzilla. What EXACTLY will bugzilla do for us > that would make me want to learn it and install it? BTW, the current > wheel was invented a year ago 'cuze nothing really fit what we needed. I believe the greatest advantage for the PostgreSQL is that a Bugzilla installation would allow end-users as well as developers to check if a bug has already been reported, look for existing bugs, submit patches, add comments, see progress in development. This is very similar to the open-development style of the core development team. -- Alessio F. Bragadini alessio@albourne.com APL Financial Services http://village.albourne.com Nicosia, Cyprus phone: +357-2-755750 "It is more complicated than you think" -- The Eighth Networking Truth from RFC 1925
Tom Lane wrote:<br /><blockquote cite="mid:520.998573151@sss.pgh.pa.us" type="cite"><pre wrap="">Vince Vielhaber <a class="moz-txt-link-rfc2396E"href="mailto:vev@michvhf.com"><vev@michvhf.com></a> writes:<br /></pre><blockquote type="cite"><prewrap="">On Thu, 23 Aug 2001, Colin 't Hart wrote:<br /></pre><blockquote type="cite"><pre wrap="">5. I thinkBugzilla's concepts of products, components and versions fit<br />the way we work.<br />I envisage that 'Postgres','Interfaces', 'Languages' might be products<br />that we would have.<br />Within 'Postgres' we would have thevarious subsystems that make up the<br />core.<br />Within 'Interfaces' we would have 'JDBC', 'ODBC' etc.<br />Within'Languages' we would have 'PL/pgSQL' etc.<br /></pre></blockquote></blockquote><pre wrap=""><br /></pre><blockquotetype="cite"><pre wrap="">I can see a little benefit to this, but for the most part the same<br />peoplethat are working on the core pieces of PostgreSQL are also<br />working on the interfaces and languages.<br /></pre></blockquote><prewrap=""><br />I would argue against subdividing a bug database at all. I don't think<br />the projectis large enough to require it (we are in no danger of<br />becoming the size of Mozilla anytime soon). But more importantly,<br/>subdivision introduces the risk of misclassification of a bug --- and<br />in my experience the initialreporter of a bug *very* frequently<br />misidentifies where the problem is. So unless additional effort is<br />expendedto reclassify bugs (is that even possible in Bugzilla?), the<br />classification will degenerate to the point ofbeing a hindrance rather<br />than a help in locating things. Overall I just don't see that much<br />benefit from a classificationsystem.<br /></pre></blockquote> Bugzilla does provide for the reclassification bugs. I have misidentifiedwhere bugs were in Mozilla and have had them reclassified into different areas/components of that project.<br/><br />