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
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
Philip Olson wrote:
- Importing
Of what..?
Existing bugs from php/pecl/php/gtk
- Tagging : Allow people to optionally attach tags to bugs
What tags..?
I assume web2.0 tagging (as in gmail labels for example, or blog entry tags..)
-Hannes
Hannes Magnusson wrote:
Philip Olson wrote:
- Importing
Of what..?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..
- Tagging : Allow people to optionally attach tags to bugs
What tags..?I assume web2.0 tagging (as in gmail labels for example, or blog entry tags..)
Just useless "chrome" IMO..
--Jani
- 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
Richard Lynch wrote:
- 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.
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
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
Hannes Magnusson wrote:
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).
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 :).
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 notThird 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
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:
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 notThird 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
Jani Taskinen wrote:
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
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
Sriram Natarajan wrote:
Jani Taskinen wrote:
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
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
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?
now http://svn.php.net/repository/pear/packages/Bugtracker/trunk/
--
Brett Bieber
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 notThird 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
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:
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 notThird 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
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
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
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