Filechooser bug day/weekend/week/month idea

[Timothy Arceri <t_arceri yahoo com au>]

Hi All,


I like to maximise the little time I have to contribute to Linux this is why I choose to contribute to GTK as 
I believe these contributions have the highest impact due to improvements reaching across multiple 
applications and desktops environments. 

Anyway lately I have been targeting the GTK filechooser in particular. This component alone currently has 320 
bugs filed against it thats over 9% of the total GTK bugs.

I have managed to help get the count down from 359 only a couple of weeks ago through a combination of 
patches, making duplicates and bumping old bugs and patches. I have even found a couple of unreported issue 
along the way. However I've come to the conclusion that if I want to make a serious dent to these bugs I need 
some help. So... 

I would like to propose we have a bug day/weekend/week/month dedicated to the file chooser. I have seen bug 
days proposed before without much enthusiasm but I've started on something I believe will help make this one 
more successful. I have started working my way through all the outstanding bugs and categorising them into 
groups based on the next action that should (in my opinion, I'm open to corrections) be taken. This should 
make it easy for potential contributors to find something they can help with and for the gtk maintainers to 
maximise the time they have to help out in working through the bugs.

So far these are the categories I have:

Bugs to maybe close - These are mostly old bugs. Some are crashes that were reported many years ago with very 
little or zero activity since. Some are reports that can no longer be reproduced, some are issue that are 
probably not as noticeable due to improvements in how the filechooseer works since the bug was first report.
Anyway there are bugs that the GTK maintainers might want to look at and possibly close as I dont feel 
comfortable closing them myself.


Design input needed - Again one for the GTK maintainers these bugs I consider need some guidance from the GTK 
team on whether or not its even a good idea to implement them before someone wastes time coding. 

Easier bug fixes - These are relatively easy bugs to work on that shouldn't be to hard to fix for a willing 
contributor. Generally most information thats needed is supplied in the bug report.


Harder bug fixes - As it would suggest these are harder/more time consuming bugs a contributor could work on 
with most information available in the bug report for someone wishing to start working on it.

Retest and likely fixed - These bugs need someone to retest and confirm if its still an issue or not. I'm 
guessing that most of these could be already fixed but its just a guess.

Retest and find root cause - Bugs need to be retested and the root cause of the issue tracked down as the bug 
report lacks this information. Some of these could be quite difficult to track down.


I intend to add at least two more one for all windows related issues and one for mac issues.

Once a complete list of these issues has been created we could advertise a bug day/week/etc for these to be 
worked on retested etc. Of coarse no one is stopping anyone working on them while the list is still being 
completed.

I upload the Libre Office documents I've used to categories these bugs here: 
http://www.itsqueeze.com/wp-content/uploads/2013/06/Filechooser-bugs.tar.gz but I would like to put all this 
on the Gnome wiki somewhere if that's possible?? That way others could help me finish of the lists if they 
wanted too and its up there for all to see ready for the bug day.

Anyway I'm keen to see what people think of my idea? Or if I'm just wasting my time.

Thanks,
Timothy Arceri