# bug tracker planning - Thread: https://externals.io/message/44782 - Original archive: https://news-web.php.net/php.internals/44782 - Started by Philip Olson on 2009-07-07T17:54:38+00:00 - Messages: 17 - Reply by email to internals@lists.php.net - More for agents: search with https://externals.io/search.md?q={query} · JSON API at https://externals.io/api · documentation at https://externals.io/llms.txt --- ## #44782 — Philip Olson — 2009-07-07T17:54:38+00:00 URL: https://externals.io/message/44782#44782 The bug system today works fine but improvements are being made. I've gone through the lists and details from past attempts and will list ideas here. Please do not vote, but if a particular item appears like a bad idea then please explain. Or, discuss additional (or modified) ideas that will be useful to the PHP project. The new system[1] is based off the pear.php.net bug system (via Jani), which long ago was a fork of our current (bugs.php.net). Because of this, some of these items are already available via the pear geeks. The plan is to have one bug tracker that includes PEAR+PECL+Core+GTK +Etc. It's also planning to go live after Stage #1 is completed, and also Jani and 2009 GSoC student Felipe Ribeiro are working on this project. Soonish a test system will be setup for all to break. Yes, this really is happening. Most people like the current system because it's simple, and I don't foresee this changing. First stage: - Cleanup code (in progress) - Attachments : For a diff, test, backtrace, screenshot, whatever. (done) - Package/Type separation : Packages (like extensions) and Bug Types (like feature requests) are separate (done) - Defined/Documented permissions : For example, so we all know if a random person can comment on a bogus bug - Preview button, instead of only submit (almost done) - Deal with bug id clashes from current PECL/PEAR/PHP bug trackers, and associated links - Importing - Testing Second stage: - Additional history : When a bug was opened/closed etc. Currently we don't log this except in emails - Reclassification : Discuss how we handle this, like should old/new lists both receive emails? - Consider different captcha (like reCaptcha) for anonymous users - Voting : Do we use or care about this? Improve? - nofeedback improvements : People assume this means closed, when it does not Third stage: - Subscriptions : Allow people to subscribe to RSS and/or receive emails per bug/package - Tagging : Allow people to optionally attach tags to bugs - IRC integration : Allow bot integration to an IRC channel, like a #php.bugs resurrection - Optional milestones (in pearweb today) - Integrate with VCS. Research this, KISS. Ex. A commit containing "PHP Bug #42" automagically appends info to the bugs db - Befriend systems like http://bts-link.alioth.debian.org/ - OpenID support, see also http://wiki.php.net/ideas/phpnetauth - Username finder for the 'assigned' boxes, see also http://people.php.net/ And as always, additional volunteers are welcome. Regards, Philip [1] http://cvs.php.net/viewvc.cgi/pear/Bugtracker/ --- ## #44831 — Jani Taskinen — 2009-07-08T12:00:57+00:00 URL: https://externals.io/message/44782#44831 · In reply to: #44782 Philip Olson wrote: > The new system[1] is based off the pear.php.net bug system (via Jani), > which long ago was a fork of our current (bugs.php.net). Because of Pear folks forked it for http://pear.php.net/bugs/ and pecl folks took the same at some point..(?). > this, some of these items are already available via the pear geeks. The Patches, roadmap, etc. > plan is to have one bug tracker that includes PEAR+PECL+Core+GTK+Etc. At #1 stage it's was supposed to be separate installation for each using same codebase but different templates. > First stage: [cut] > - Deal with bug id clashes from current PECL/PEAR/PHP bug trackers, and > associated links This belongs in #2 stage since there won't be any clashes when each have their separate installation and database. > - Importing Of what..? > Second stage: > - Additional history : When a bug was opened/closed etc. Currently we > don't log this except in emails > - Reclassification : Discuss how we handle this, like should old/new > lists both receive emails? > - Consider different captcha (like reCaptcha) for anonymous users > - Voting : Do we use or care about this? Improve? Not used, but would be useful as indicator whether lot of people have same problem. Should be improved and used for search / listings as some sort of "weighting". (more votes -> higher on list..or something :) > - nofeedback improvements : People assume this means closed, when it > does not Like what improvements..? Note in the email / report ? > Third stage: > - Subscriptions : Allow people to subscribe to RSS and/or receive emails > per bug/package RSS feeds already exists, AFAICT: http://cvs.php.net/viewvc.cgi/pear/Bugtracker/bugs/rss/ Just needs to be extended to have feeds per package / project / etc. > - Tagging : Allow people to optionally attach tags to bugs What tags..? > And as always, additional volunteers are welcome. Yup. More than welcome. All the stuff is in cvs with README containing info how to setup it yourselves. :) --Jani --- ## #44832 — Hannes Magnusson — 2009-07-08T12:08:58+00:00 URL: https://externals.io/message/44782#44832 · In reply to: #44831 > Philip Olson wrote: > > […] > > Of what..? Existing bugs from php/pecl/php/gtk > > […] > > What tags..? I assume web2.0 tagging (as in gmail labels for example, or blog entry tags..) -Hannes --- ## #44833 — Jani Taskinen — 2009-07-08T12:13:25+00:00 URL: https://externals.io/message/44782#44833 · In reply to: #44832 Hannes Magnusson wrote: > > > […] > > Existing bugs from php/pecl/php/gtk Ah yes, that's 3rd stage stuff, when (if?) there's single installation handling all bugs for all our projects.. > > […] > > I assume web2.0 tagging (as in gmail labels for example, or blog entry tags..) Just useless "chrome" IMO.. --Jani --- ## #44839 — Richard Lynch — 2009-07-08T17:30:35+00:00 URL: https://externals.io/message/44782#44839 · In reply to: #44782 > - Reclassification : Discuss how we handle this, like should old/new > lists both receive emails? Both lists should receive reclassifaction notification, and nothing more, imho. > - Consider different captcha (like reCaptcha) for anonymous users Yes, please. The current one takes 3 tries to get right, for me. -- Some people ask for gifts here. I just want you to buy an Indie CD for yourself: http://cdbaby.com/search/from/lynch --- ## #44853 — Greg Beaver — 2009-07-09T02:50:33+00:00 URL: https://externals.io/message/44782#44853 · In reply to: #44839 Richard Lynch wrote: > > > […] > > Both lists should receive reclassifaction notification, and nothing > more, imho. > > > […] > > Yes, please. The current one takes 3 tries to get right, for me. The PEAR bugtracker has been using a no-captcha-necessary method that to catch spam, and it is working great now. The only caveat was that it took a little while to work out the kinks. It works by creating named user accounts and requests a password after you click a link in an email sent to you. Bugs that don't get confirmed by the user within 2 weeks get purged, and unvalidated bugs can be viewed by folks logged into the tracker with their pear accounts. This tends to cut down on both spam and poorly thought-out bug reports. The disadvantages are obvious: everyone has to have an account and give their email address to report a bug. The advantages are also obvious: much more disability-friendly, tracking reports by users is easy, and upgrading a frequent reporter to a developer is also easier, no captchas ever again and easy per-reporter statistics. We use this in PEAR just to see who is active reporting and fixing bugs. Greg --- ## #44854 — Hannes Magnusson — 2009-07-09T07:39:55+00:00 URL: https://externals.io/message/44782#44854 · In reply to: #44853 >  The disadvantages are obvious: everyone has to have an account and give > their email address to report a bug.  The advantages are also obvious: I *hate* when I am required to signup and do all sorts of weird validation crap before I can file bug reports. Things get even worse when projects hide the "new bug report" links for not-logged in users. I tend to drop out of the process midway and get to the conclusion "apparently they don't want me to report bugs". Also, there is no reason to maintain user system for bugs. Just outsource the login to openid or a "captcha" questions ("Are you a zombie?" don't know/yes/no). -Hannes --- ## #44871 — Greg Beaver — 2009-07-09T14:44:10+00:00 URL: https://externals.io/message/44782#44871 · In reply to: #44854 Hannes Magnusson wrote: > > > > […] > > I *hate* when I am required to signup and do all sorts of weird > validation crap before I can file bug reports. > > Things get even worse when projects hide the "new bug report" links > for not-logged in users. > I tend to drop out of the process midway and get to the conclusion > "apparently they don't want me to report bugs". > > Also, there is no reason to maintain user system for bugs. Just > outsource the login to openid or a "captcha" questions ("Are you a > zombie?" don't know/yes/no). Hi, Actually, I hate requiring to do weird crap before filing too, and PEAR's system was designed for people who hate doing crap prior to filing. That's why the system PEAR uses is (1) file bug (2) verify email. Incidentally, I may have been unclear: the "new bug report" link is not hidden, just bugs from unverified users are not included in the public list of bugs (about 60-80% of new bugs are ads for manly drugs, so this is a good thing). signed in developers can see them and can also manually mark them as "spam" which causes them to be purged daily. The feeling of using it is infinitely friendlier than that used by trackers such as Bugzilla where clicking "report bug" goes to a blank page with a user/pass prompt. Greg P.S. the first time I sent this, the words "manly drugs" were a 6 letter word starting with "v" and the mail server rejected it with: 550 550 we're manly enough already (state 18). Nice :). --- ## #44884 — Sriram Natarajan — 2009-07-09T21:44:03+00:00 URL: https://externals.io/message/44782#44884 · In reply to: #44782 Hi I very much miss the ability to add my email address to the bugs that I am interested in. This used to allow to me to track its progress. I wasn't not sure, if that is what you meant within Subscriptions.. - sriram Philip Olson wrote: > > The bug system today works fine but improvements are being made. I've > gone through the lists and details from past attempts and will list > ideas here. Please do not vote, but if a particular item appears like > a bad idea then please explain. Or, discuss additional (or modified) > ideas that will be useful to the PHP project. > > The new system[1] is based off the pear.php.net bug system (via Jani), > which long ago was a fork of our current (bugs.php.net). Because of > this, some of these items are already available via the pear geeks. > The plan is to have one bug tracker that includes > PEAR+PECL+Core+GTK+Etc. It's also planning to go live after Stage #1 > is completed, and also Jani and 2009 GSoC student Felipe Ribeiro are > working on this project. Soonish a test system will be setup for all > to break. Yes, this really is happening. > > Most people like the current system because it's simple, and I don't > foresee this changing. > > First stage: > - Cleanup code (in progress) > - Attachments : For a diff, test, backtrace, screenshot, whatever. (done) > - Package/Type separation : Packages (like extensions) and Bug Types > (like feature requests) are separate (done) > - Defined/Documented permissions : For example, so we all know if a > random person can comment on a bogus bug > - Preview button, instead of only submit (almost done) > - Deal with bug id clashes from current PECL/PEAR/PHP bug trackers, > and associated links > - Importing > - Testing > > Second stage: > - Additional history : When a bug was opened/closed etc. Currently we > don't log this except in emails > - Reclassification : Discuss how we handle this, like should old/new > lists both receive emails? > - Consider different captcha (like reCaptcha) for anonymous users > - Voting : Do we use or care about this? Improve? > - nofeedback improvements : People assume this means closed, when it > does not > > Third stage: > - Subscriptions : Allow people to subscribe to RSS and/or receive > emails per bug/package > - Tagging : Allow people to optionally attach tags to bugs > - IRC integration : Allow bot integration to an IRC channel, like a > #php.bugs resurrection > - Optional milestones (in pearweb today) > - Integrate with VCS. Research this, KISS. Ex. A commit containing > "PHP Bug #42" automagically appends info to the bugs db > - Befriend systems like http://bts-link.alioth.debian.org/ > - OpenID support, see also http://wiki.php.net/ideas/phpnetauth > - Username finder for the 'assigned' boxes, see also > http://people.php.net/ > > And as always, additional volunteers are welcome. > > Regards, > Philip > > [1] http://cvs.php.net/viewvc.cgi/pear/Bugtracker/ --- ## #44935 — Jani Taskinen — 2009-07-11T10:11:45+00:00 URL: https://externals.io/message/44782#44935 · In reply to: #44884 Please don't top post! And what you ask for is already there. --Jani Sriram Natarajan kirjoitti: > Hi > I very much miss the ability to add my email address to the bugs that I > am interested in. This used to allow to me to track its progress. I > wasn't not sure, if that is what you meant within Subscriptions.. > > - sriram > > > Philip Olson wrote: > > […] --- ## #44936 — Brett Bieber — 2009-07-11T12:27:08+00:00 URL: https://externals.io/message/44782#44936 · In reply to: #44782 > And as always, additional volunteers are welcome. Sounds great. How does one join the team? Is there an appropriate place to submit patches to, a bugtracker for the bugtracker? > [1] http://cvs.php.net/viewvc.cgi/pear/Bugtracker/ now http://svn.php.net/repository/pear/packages/Bugtracker/trunk/ -- Brett Bieber --- ## #44976 — Sriram Natarajan — 2009-07-15T17:30:47+00:00 URL: https://externals.io/message/44782#44976 · In reply to: #44935 Jani Taskinen wrote: > Please don't top post! > > And what you ask for is already there. > > --Jani > > > Sriram Natarajan kirjoitti: > > […] Jani if I am not mistaken, only CVS account holder currently can a email address to a bug. I am requesting for the ability to add email address for folks who don't have this privilege. This allows other people who ran into the same issue to be able to monitor the status of the bug as well. - Sriram --- ## #44977 — Sriram Natarajan — 2009-07-15T17:35:58+00:00 URL: https://externals.io/message/44782#44977 · In reply to: #44782 Hi bug tracking system also need the ability to mark a current bug as duplicate . Currently, all those bugs are marked as 'Bogus'. Also, it would be nice if we can have the ability to capture related bugs together. - Sriram Philip Olson wrote: > > The bug system today works fine but improvements are being made. I've > gone through the lists and details from past attempts and will list > ideas here. Please do not vote, but if a particular item appears like > a bad idea then please explain. Or, discuss additional (or modified) > ideas that will be useful to the PHP project. > > The new system[1] is based off the pear.php.net bug system (via Jani), > which long ago was a fork of our current (bugs.php.net). Because of > this, some of these items are already available via the pear geeks. > The plan is to have one bug tracker that includes > PEAR+PECL+Core+GTK+Etc. It's also planning to go live after Stage #1 > is completed, and also Jani and 2009 GSoC student Felipe Ribeiro are > working on this project. Soonish a test system will be setup for all > to break. Yes, this really is happening. > > Most people like the current system because it's simple, and I don't > foresee this changing. > > First stage: > - Cleanup code (in progress) > - Attachments : For a diff, test, backtrace, screenshot, whatever. (done) > - Package/Type separation : Packages (like extensions) and Bug Types > (like feature requests) are separate (done) > - Defined/Documented permissions : For example, so we all know if a > random person can comment on a bogus bug > - Preview button, instead of only submit (almost done) > - Deal with bug id clashes from current PECL/PEAR/PHP bug trackers, > and associated links > - Importing > - Testing > > Second stage: > - Additional history : When a bug was opened/closed etc. Currently we > don't log this except in emails > - Reclassification : Discuss how we handle this, like should old/new > lists both receive emails? > - Consider different captcha (like reCaptcha) for anonymous users > - Voting : Do we use or care about this? Improve? > - nofeedback improvements : People assume this means closed, when it > does not > > Third stage: > - Subscriptions : Allow people to subscribe to RSS and/or receive > emails per bug/package > - Tagging : Allow people to optionally attach tags to bugs > - IRC integration : Allow bot integration to an IRC channel, like a > #php.bugs resurrection > - Optional milestones (in pearweb today) > - Integrate with VCS. Research this, KISS. Ex. A commit containing > "PHP Bug #42" automagically appends info to the bugs db > - Befriend systems like http://bts-link.alioth.debian.org/ > - OpenID support, see also http://wiki.php.net/ideas/phpnetauth > - Username finder for the 'assigned' boxes, see also > http://people.php.net/ > > And as always, additional volunteers are welcome. > > Regards, > Philip > > [1] http://cvs.php.net/viewvc.cgi/pear/Bugtracker/ --- ## #44980 — Jani Taskinen — 2009-07-15T18:47:58+00:00 URL: https://externals.io/message/44782#44980 · In reply to: #44977 Sriram Natarajan wrote: > Hi > bug tracking system also need the ability to mark a current bug as > duplicate . Currently, all those bugs are marked as 'Bogus'. Also, it > would be nice if we can have the ability to capture related bugs together. > > - Sriram Again: DO NOT TOP POST!! And we're not adding anymore statuses. Status is irrelevant for bug being related to something or not. --Jani > Philip Olson wrote: > > […] --- ## #44981 — Jani Taskinen — 2009-07-15T18:50:53+00:00 URL: https://externals.io/message/44782#44981 · In reply to: #44976 Sriram Natarajan wrote: > > > Jani Taskinen wrote: > > […] > Jani > if I am not mistaken, only CVS account holder currently can a email > address to a bug. I am requesting for the ability to add email address > for folks who don't have this privilege. This allows other people who > ran into the same issue to be able to monitor the status of the bug as > well. You are mistaken and haven't read this thread at all. We are not talking about the current tracker at http://bugs.php.net/ here but the new stuff which is based on http://pear.php.net/bugs/bug.php?id=377&edit=1 (that url as example to show you that anyone can really subscribe to any bug..and that same is also in the new code..) --Jani > > - Sriram --- ## #44984 — Philip Olson — 2009-07-16T03:54:42+00:00 URL: https://externals.io/message/44782#44984 · In reply to: #44980 > Sriram Natarajan wrote: > > […] > And we're not adding anymore statuses. Status is irrelevant for bug > being related to something or not. I think we should bring back the duplicate status for duplicate bugs, and include a bug number field to be submitted instead of sometimes writing a bug number as a comment that links if we remembered the syntax. And besides, the new Bugtracker already has the duplicate status much like its mother pearweb/bugs has. As for 'capturing related bugs', I imagine the [optional] tagging would help with that... or do you have something specific in mind? Regards, Philip --- ## #44985 — Pierre Joye — 2009-07-16T07:48:05+00:00 URL: https://externals.io/message/44782#44985 · In reply to: #44984 > As for 'capturing related bugs', I imagine the [optional] tagging would help > with that... or do you have something specific in mind? Related bugs are more a list of bugs # related to a given one, or being a dependency, a coma separated list of # should do it (one to n relation in the db). Cheers, -- Pierre http://blog.thepimp.net | http://www.libgd.org