|
Hi, list, Thanks for raising bugs but in case nobody said this: GNOME shell are only responsible for what happens with the gnome-shell module, not the entire gnome git moduleset so this list is possibly not the right place for a discussion about gnome bugs everywhere but since the topic is raised already I have a few points to throw in. There are 204 unreviewed patches in gnome-shell (a few of them are mine! ) which is a waste [1] However, I really do not think that is because of a collective conspiracy to focus on new features as opposed to fixing bugs - nobody smart wants to build a house on sand. That said, people are just that, life has a momentum of its own and some older, important bugs may well get missed because less important but more urgent ones get in the way. If so, that would be the consequence of some systematic error caused by a flaw or so in the tracking system itself. Identifying the cause of any error requires attention before anything can be rectified. Sindu has suggested this already and I also suspect the most likely culprit is the bugzilla bugtracking system lacks the required resources. If this is the case then shuffling additional support to the task of optimising the bugtracking system would be well worth it for everyone to think about. Not only to increase productivity but perhaps also to improve public confidence in GNOME's commitment to the interests of its users. Forgetting current resources for a minute I also have the following suggestions and would be willing to help in some way, for what that is worth: 1. Remove the "accepted_commit_now" option might be a way force a reviewer to push fixes on acceptance rather than working on an assumption: the patch contributor has the required git privilege to push their own commits when they may not. Either that or regularly sending autogenerated reminders to module maintainers when there is accepted work in their module which has not been committed to master. might do as well to draw attention to them so they can be dealt with by someone with the privilege to push them. In gnome shell alone there are 25 reviewed + accepted (accepted_commit_now) patches in right now which have not been pushed to master.[2] I wonder what the total number is for the rest of GNOME modules. I imagine there's loads. 2. Remove the option for a module maintainer to be able to comment on or review a bug unless they have changed the status of it from 'uncomfirmed' to reflect it's true status (too controversial?). Especially useful for newcomers but I reckon in general that might well speed up the process of seeking out important bugs for everyone. At the moment finding current problems relies on reading the bug threads, which is slow and requires a high level of inside knowledge to be anything but slow. 3. Allocate time to remove the names of module maintainers who are no longer in action so the information provided to bugzilla users is current and accurate and exploring a strategy to prevent the problem reoccurring. 4. Close rather than reset older bugs which have not been discussed for a long time could improve navigation and ensure bug reporters can easily flag the issues which are still present in the current releases by reopening the ever present ones. I think fedora bug trackers deal with things in this way but doing that may have it's own problems, I am not sure 5. Compile a list of currently unmanaged modules and encouraging newer contributors to bring them up to date or take them on. I can think of two modules I believe to be abandoned which I would happily take on if I knew how to go about it. I bet I am not the only one . 6. Introduce a requirement to review a bug before committing a patch of your own. This could potentially work well in some way that I cannot think of right now but could be problematic otherwise. 7. Disallowi git authority to push patches which are not already associated with any bug report so that the bugzilla reports reflect changes seen in master (the stats in bugzilla are not totally accurate whilst some developers can and although I am not sure how common it is - I note there are do push patches before raising a bug when they are not really meant to this) 8. Allow developers to submit patches to unresolved bugs during a freeze break. I can see the rationale but I am not sure the benefits of freezing bug fixes outweighs the disadvantages 9. Introduce a special 'feature freeze' for the purpose of clearing up remaining unresolved bugs. As I said, any of those kinds of tasks are likely to need additional volunteers with skills, interest and time to see implementation work out so for the time being I expect if Marshall were to speak to the bugtacking team directly they may be able to reassure, that the numbers (i.e. 46k) are a little misleading if at all correct. I would also encourage Marshall to take a gaze over the data available in bugzilla by querying it himself. Examining the figures critically, in context, might hopefully confirm to you that the majority of developers do continually review patches and work on bugs themselves well before the 'fun stuff' even starts for them. Many provide daily technical support on the IRC in addition to that work. For help on querying bugzilla try the #gnome-love IRC channel Andre also has a great blog category for tutorials on using bugzilla which you may find helpful and he himself is a very approachable guy so I am sure he would be happy to help you there if you ping him[3] Hope that helps. Regards, Magdalen [1] https://bugzilla.gnome.org/page.cgi?id=patchreport.html&product=gnome-shell&patch-status=none [2] https://bugzilla.gnome.org/page.cgi?id=patchreport.html&product=gnome-shell&patch-status=accepted-commit_now [3] https://blogs.gnome.org/aklapper/ On 17/01/14 15:06, Jasper St. Pierre
wrote:
|