Re: [drupal-devel] Improvements abandoned?
Steve raises an issue that has really been bugging me this week. There are currently 260 or so patches in the Drupal issue tracker. Lots of these are worthy patches... like the two Steve mentioned. But so many of them have little or no chance of being reviewed and applied. There must be dozens of people beavering away making improvements to Drupal and submitting patches only to have them get lost in this ocean of issues. Such a waste of resources. Something needs to be done to address this issue. I have looked through the issues tracker reading the comments and following the progress over time of quite a few issues. It's actually quite sad to see a patch get written, reviewed, finalised and then not committed only to see the issue revived 6 months later, the patch gets updated, reviewed, approved and not committed. 6 months later the issue gets revived by someone else bitten by the same bug. What can we do about it? I would like to see ten or so issues at a time nominated as "hot" issues which are targetted, resolved and committed. I think that by focusing on just a few issues at once that these ones will get completed and all Drupal users will benefit from these incremental improvements. These need not be big patches or implementations of extensive new features. Small patches like Steve's help text improvements are just as worthy of inclusion as a new forms API - and a whole lot simpler :) There just needs to be some mechanism to focus resources on a small subset of patches so that they get reviewed, approved and committed. ...Richard.
You are not alone, Richard. This has very issue has lead to long (and heated) threads already. The reason it is still not solved is because there seems to be no perfect solution. Not evne one that gets anywhere close to perfect. I have a lot of hope for Robert Douglas's talk on drupalCON in amsterdam, which will address this issue too, so it seems. Bèr On Tuesday 11 October 2005 08:22, Richard Archer wrote:
Steve raises an issue that has really been bugging me this week.
There are currently 260 or so patches in the Drupal issue tracker. Lots of these are worthy patches... like the two Steve mentioned. But so many of them have little or no chance of being reviewed and applied.
There must be dozens of people beavering away making improvements to Drupal and submitting patches only to have them get lost in this ocean of issues. Such a waste of resources.
Something needs to be done to address this issue.
I have looked through the issues tracker reading the comments and following the progress over time of quite a few issues. It's actually quite sad to see a patch get written, reviewed, finalised and then not committed only to see the issue revived 6 months later, the patch gets updated, reviewed, approved and not committed. 6 months later the issue gets revived by someone else bitten by the same bug.
What can we do about it?
I would like to see ten or so issues at a time nominated as "hot" issues which are targetted, resolved and committed. I think that by focusing on just a few issues at once that these ones will get completed and all Drupal users will benefit from these incremental improvements.
These need not be big patches or implementations of extensive new features. Small patches like Steve's help text improvements are just as worthy of inclusion as a new forms API - and a whole lot simpler :)
There just needs to be some mechanism to focus resources on a small subset of patches so that they get reviewed, approved and committed.
...Richard.
I have a lot of hope for Robert Douglas's talk on drupalCON in amsterdam, which will address this issue too, so it seems.
That's correct. I'm still in the due-dilligence phase, and have lots of people to talk to yet before the exact nature of my talk is set, but I'm interested in hearing any suggestions. For my background thinking on the issue, see here: http://drupal.org/node/28210 In the end, I'm interested in exploring ways that the patch queue can be more effective *now*, and how it can stay effective in a setting where Drupal is 5x more active than it is today. Feel free to email me on or off list with your suggestions. -Robert
On Tue, 11 Oct 2005, Richard Archer wrote:
Steve raises an issue that has really been bugging me this week.
There are currently 260 or so patches in the Drupal issue tracker. Lots of these are worthy patches... like the two Steve mentioned. But so many of them have little or no chance of being reviewed and applied.
Anybody can review patches.
There must be dozens of people beavering away making improvements to Drupal and submitting patches only to have them get lost in this ocean of issues. Such a waste of resources.
There are many worthy patches, but there are also many patches that simply lack the quality to make it for Drupal core. Or also implement features which apparently nobody but the original author needs or wants.
Something needs to be done to address this issue.
Yes.
I have looked through the issues tracker reading the comments and following the progress over time of quite a few issues. It's actually quite sad to see a patch get written, reviewed, finalised and then not committed only to see the issue revived 6 months later, the patch gets updated, reviewed, approved and not committed. 6 months later the issue gets revived by someone else bitten by the same bug.
It also happens that some patches get finally committed after more than six months time. :p Some of them were simply not ready (revisions patch) others were ready but not deemed worthy (node modules controll title patch).
What can we do about it?
I would like to see ten or so issues at a time nominated as "hot" issues which are targetted, resolved and committed. I think that by focusing on just a few issues at once that these ones will get completed and all Drupal users will benefit from these incremental improvements.
This is an excellent idea which has been brought up on the conference list, too, and will be executed in Amsterdam. Since I will get to chair this particular session, I'd very much like everybody to make lists of their favourite bugs or patches and send them to me off list. One restriction: Patches should address bugs, not new features. I will consider new features that you claim to be usability bugs, though. Please make a list like this: http://drupal.org/node/xxxxx bug about foo.module being broken on screen bar Only core module bugs should be on the list. I will publish the concatenated list somewhere on drupal.org. I'll probably add a book page for this so you can also post comments there.
These need not be big patches or implementations of extensive new features. Small patches like Steve's help text improvements are just as worthy of inclusion as a new forms API - and a whole lot simpler :)
As I understand it Steve now gets to update the handbook.
There just needs to be some mechanism to focus resources on a small subset of patches so that they get reviewed, approved and committed.
There will be one one-hour bug squashing meeting per day. The way I envision it to work is that I will assign one bug per developer, they look at it, come up with a patch or revive an existing patch, demonstrate that it is a) working and b) up to standards. Ideally Dries and Steven can then just commit the patches. Since there will be a lot of developers the bug list can get lengthy, don't be shy. Cheers, Gerhard
At 12:04 PM +0200 11/10/05, Gerhard Killesreiter wrote:
Since there will be a lot of developers the bug list can get lengthy, don't be shy.
This is an excellent plan and will go a long way towards shortening the backlog of bugs as well as improving the quality of Drupal. But there still remains the problems of: - all the feature requests and tasks in the queue - the fact that the queue grows faster than it is processed - the way unwanted patches just sit in the queue forever without being reviewed and rejected. A longer term process needs to be established to make sure worthy patches are considered and also that reviewers/contributors don't waste their time. ...Richard.
On Tue, 11 Oct 2005, Richard Archer wrote:
At 12:04 PM +0200 11/10/05, Gerhard Killesreiter wrote:
Since there will be a lot of developers the bug list can get lengthy, don't be shy.
This is an excellent plan and will go a long way towards shortening the backlog of bugs as well as improving the quality of Drupal.
Let's hope that.
But there still remains the problems of:
- all the feature requests and tasks in the queue
- the fact that the queue grows faster than it is processed
- the way unwanted patches just sit in the queue forever without being reviewed and rejected.
Yep.
A longer term process needs to be established to make sure worthy patches are considered and also that reviewers/contributors don't waste their time.
Well, Drupal is open source and as such follows the open source development model. That means it is developer driven and that in turn means that I scratch my own itch when it comes to patches. This is also true for anybody else submitting feature patches. Reviewing somebody else's patch usually does not scratch my own itch, but might help Drupal as a whole. But even then I mostly limit my review process to patches which I think make sense. This obviously is a very personal choice and I won't simply close another issue just because I don't need or like the particular feature. I wrote this to explain to you why there are so many patches and why it is likely that the number of patches will probably continue to grow. About feature requests or tasks: There are probably some of them that would deserve attention. But unless it scratches my own itch I won't work on them. So basically the same as for patches does apply. Cheers, Gerhard
On Tue, 11 Oct 2005, Gerhard Killesreiter wrote:
This is an excellent idea which has been brought up on the conference list, too, and will be executed in Amsterdam. Since I will get to chair this particular session, I'd very much like everybody to make lists of their favourite bugs or patches and send them to me off list. One restriction: Patches should address bugs, not new features. I will consider new features that you claim to be usability bugs, though.
Please make a list like this:
http://drupal.org/node/xxxxx bug about foo.module being broken on screen bar
Only core module bugs should be on the list.
Apparently I am not taken seriously. ;p Only Goba sent me a measly two bugs (but they do have a certain quality). Cheers, Gerhard
At 12:08 PM +0200 13/10/05, Gerhard Killesreiter wrote:
Only Goba sent me a measly two bugs (but they do have a certain quality).
My suggestion: Print out a list of bugs from the Tracker sorted by number of comments, descending. Start at the top of the list and work your way down. This means the bugs that have generated the most interest in the trackers get squashed. You might need to tweak the priority of a couple of newer bugs that haven't been around long enough to generate many comments but are interesting nonetheless. ...Richard.
On Thu, 13 Oct 2005, Richard Archer wrote:
At 12:08 PM +0200 13/10/05, Gerhard Killesreiter wrote:
Only Goba sent me a measly two bugs (but they do have a certain quality).
My suggestion:
Print out a list of bugs from the Tracker sorted by number of comments, descending.
Start at the top of the list and work your way down.
That is a nice idea, thanks. Cheers, Gerhard
Something needs to be done to address this issue.
I have looked through the issues tracker reading the comments and following the progress over time of quite a few issues. It's actually quite sad to see a patch get written, reviewed, finalised and then not committed only to see the issue revived 6 months later, the patch gets updated, reviewed, approved and not committed. 6 months later the issue gets revived by someone else bitten by the same bug.
What can we do about it?
1. Review patches. 2. Try applied patched code. 3. Write down your experience as a comment to the bug report. 4. Build buzz around a bug. Goba
participants (6)
-
Bèr Kessels -
Gabor Hojtsy -
Gerhard Killesreiter -
Richard Archer -
Robert Douglass -
Steve Dondley