Arch bug triage howto or good practices

chicha · 2008-04-29 09:16:59

Hello,

I have been looking around the wiki and the forum and I did not found relevant information about how to help with Arch's bug tracker.
Also searching with keywords around "bugs" return a lot of posts in the forum and I might have missed the relevant post.

So I am wondering how I could help with triaging bugs at Arch ? I might also create a wiki page with any information from this post, to help newcomers willing to help.

If it is quite obvious that one could help by submitting patches, try to reproduce some bugs, invalidate some others, report bugs upstream, there are a few cases where I do not know what to do.

Lets take 2 examples :

http://bugs.archlinux.org/task/9052
The bug is related to some old versions of xorg, xulrunner and epiphany in testing. There are some new packages in core/extra.
Can I request a closure for this bug since it is related to old packages (and even the bug does not seem Arch related), or shall I just post a comment asking for confirmation of the validity of this bug with the new versions ?

http://bugs.archlinux.org/task/10101
In this bug a problem was raised with f-spot. I tried to help the user, and even provided a PKGBUILD with a patch from upstream so that he can recompile and test again. But the user seems to be disapointed by Arch and wants to quit. He does not seem to want to provide more information about his problem and do not answer to my request for more information. As the user might be away for a while, is there a period after which I can request a closure for this bug (a month after the last post), since I am pretty sure that the patch from upstream fixed the issue, and nobody else confirmed the bug, and the user seems to not answer to my request for more information ?

My problem is : in such cases, shall I request a closure for the bug, taking the risk that the user re-open it, or shall I just put a comment to say why I think this bug should be closed ? What is the best way to help you devs at making your work easier with bugs, after submitting patched of course ?

Thank you for your help !

Allan · 2008-04-29 09:39:40

I will add how I would deal with these bugs... not necessarily a set in stone guideline but I do enjoy bug squashing!

In the first case (xorg, xulrunner and epiphany), you can try replicating the bug yourself with current versions or given there has been no activity there for a while post to the bug asking if it is still valid.

For the second bug (f-spot), the user just answered in the last couple of days...

In general, if I can not replicate the bug with the latest software versions or the user hasn't responded to a request for info for a month, I request closure. The bug can always be re-opened if a user experiences it again.

Edit: Wow - I haven't gone on a bug squash for a while and I see there is 629 bugs at the moment. We should have a bug day soon and get rid of at least 129 of these.

Last edited by Allan (2008-04-29 09:41:26)

chicha · 2008-04-29 09:48:52

Thank you Allan.

Unfortunatly I cannot reproduce the Xorg related bug since it is hardware related and I do not have this hardware. Bu I can ask if the problem is still valid ...

About the f-spot bug you are right. They are no answer only since very few days, and I will wait for a month or a new f-spot release before asking for closure.

However did you hear about a Bug Squashing howto/mail/forum post which could be interesting, or do you think it might help if I start a dedicated page on the wiki (bug_squashing for instance) ?

Allan · 2008-04-29 10:04:28

I don't remember a specific page. Essentially to bug squash all you have to do is look at bugs and see if they are valid. If not, ask for them to be closed. If they are still valid, see if you can find a fix. Google often turns up fixes for older bugs, particularly in other distros bug trackers or the mailing lists for the software itself.

Occasionally there is an organized bug day which gets announced everywhere. There is somethings a list of bugs that are targeted (e.g. http://wiki.archlinux.org/index.php/Bug_Day_TODO which is probably out of date) but most often people just browse the bug reports looking for bug they may be able to help with. However, you don't have to wait for these. Just get in and help!

If you want to create a wiki page, post a link here when you are done and I will give it a look over.

chicha · 2008-04-29 10:17:21

I was looking for practices and guidelines specific to Arch compared to other bug tracking system such as the Gnome or KDE ones for instance.
Apparently there are not any specificities in the Arch way of managing bugs. I do not think there is much more to say than what you just said in you post.

However I will start a wiki page about reporting bugs and bug squashing. It might be usefull (or not ). I will post a link here as soon as I wrote it !

Thank you very much for your help !

Allan · 2008-04-29 10:27:55

There is nothing really Arch specific that I can think of... a bug is a bug!

chicha · 2008-05-07 15:50:35

Hello Allan,

I am becoming a bug tracker addict and had great fun with Arch's bug tracker
However I saw (and edited) a lot of invalid bug reports or bug with incomplete or invalid information at Arch's BTS.

I really feel like a documention for How to report bugs would be nice for beginners.
I have created a wiki page : Bug Reporting Guidelines.

This is still a draft and need to be continued and improved, but I am sure people who report/fix bugs will be happy to improve the document and/or put a link to it in some bug reports ...

Comments are welcome, and feel free to bring some TUs/Developers in this thread ...

tigrmesh · 2008-05-07 16:26:21

chicha wrote:

I really feel like a documention for How to report bugs would be nice for beginners.
I have created a wiki page : Bug Reporting Guidelines.

What a great idea! Thank you for doing this. And great job!

chicha · 2008-05-07 17:47:13

tigrmesh wrote:

What a great idea! Thank you for doing this. And great job!

Thank you too for your corrections : I realize how many english mistakes I did ...

stojic · 2008-05-07 18:13:14

Great idea indeed, I corrected some grammar and spelling there, but I am not a native speaker so correct further if necessary .

cubekid · 2008-05-07 21:27:47

This is really awesome! Now I have no excuse for not helping out Arch

dolby · 2008-05-08 00:13:25

there should also be a link to that page on top of the flyspray (in big red letters)
thanks for writing this

edit: made a feature request http://bugs.archlinux.org/task/10370

Last edited by dolby (2008-05-08 00:19:28)

Allan · 2008-05-08 01:27:35

I had a quick look at the wiki page and it looks to be shaping up nicely. Added to my toolbar in firefox to make me give it a decent read through later. Thanks for contributing.

Edit: Toofishes comment in the history amused me enough to come here and comment on it!

Last edited by Allan (2008-05-08 04:08:18)

Arch Linux

#1 2008-04-29 09:16:59

Arch bug triage howto or good practices

#2 2008-04-29 09:39:40

Re: Arch bug triage howto or good practices

#3 2008-04-29 09:48:52

Re: Arch bug triage howto or good practices

#4 2008-04-29 10:04:28

Re: Arch bug triage howto or good practices

#5 2008-04-29 10:17:21

Re: Arch bug triage howto or good practices

#6 2008-04-29 10:27:55

Re: Arch bug triage howto or good practices

#7 2008-05-07 15:50:35

Re: Arch bug triage howto or good practices

#8 2008-05-07 16:26:21

Re: Arch bug triage howto or good practices

#9 2008-05-07 17:47:13

Re: Arch bug triage howto or good practices

#10 2008-05-07 18:13:14

Re: Arch bug triage howto or good practices

#11 2008-05-07 21:27:47

Re: Arch bug triage howto or good practices

#12 2008-05-08 00:13:25

Re: Arch bug triage howto or good practices

#13 2008-05-08 01:27:35

Re: Arch bug triage howto or good practices

Board footer