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

_______________________________________________
gtk-devel-list mailing list
gtk-devel-list@gnome.org
https://mail.gnome.org/mailman/listinfo/gtk-devel-list

Reply via email to