Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
By Paul Natsuo Kishimoto on
I'm really excited about Drupal 5.0 - so much so that I've been hitting the "critical bugs" links from the beta and RC pages over and over again to watch the developers progress towards new releases. Due to work and other coding commitments, I can't get involved in rolling patches right now—eventually, I will. In the meantime, I want to help by doing bug triage; that is, herding bugs so they're easier for developers to attack. For example,
- There are three pages of active bugs against 5.0-beta1 and 5.0-beta2; shouldn't these be updated to 5.0-rc1 or 5.x-dev if they're still outstanding? Which one?
- There are active tasks (16 total) and feature requests (9 total) against 5.0-beta1, 5.0-beta2 and 5.0-rc1. Since these are really development milestones and not actual releases, should there really even be features and tasks for them?
There are also 49 pages of bugs, tasks and feature requests against "x.y.z". I suspect a lot of cruft could be cleaned out, and many recent issues would be revealed as duplicates of, e.g. Drupal.org node #572, which is four years old.
If anyone could help me out by answering these questions or pointing me to answers, I'd be able to get started. I'd also like to actively maintain a set of guidelines and examples, if someone could suggest an appropriate place to do so. Maybe groups.drupal.org?
Comments
Random answers: x.y.z is the
Random answers:
x.y.z is the version bugs that were previously assigned to HEAD got assigned to when HEAD was removed as a target recently. Anything that's x.y.z DOES need to either be closed or moved to a branch it still applies to. (Actually, you CAN'T do anything to an x.y.z bug without moving it first, as there technically isn't really an x.y.z category -- it forces you to recategorize it.)
Feel free to clean out obvious stuff, close bugs that were resolved but not marked fixed, etc.
The correct place to maintain guidelines and examples is in the Handbook. Just find the appropriate location for it and create a new book page. (Browse through it to make sure there isn't a page on this already ;)
Tasks against -beta1 and -beta2 that are in active state should probabaly be evaluated and moved up to 5.x-dev, 6.x-dev, or closed. Feature requests should probabaly go to 5.x-dev or 6.x-dev, depending on how invasive said feature is. (5.x will have no more major features added, it's feature frozen.)
Dormant support requests should be followed up on or closed.
Oh, and play bug bingo ;)
--Brandon
Thanks
That's exactly what I was looking for!
I tried, but whittling down lists is more my cup of tea -)
How would you define "dormant" for support requests?
Triage Responses
Glad to hear it :). As you know, there is a lot of work that could be done purely in the triage department so your help is much appreciated.
The short answer is that it doesn't matter that much as long as the major version is correct (4.6 vs. 4.7 vs 5.x vs. 6.x). Developers usually perform bug searches that include all related minor releases within a major release so they will find those bugs anyway. BUT if someone does specifically confirm that the bug/issue still exists in the latest CVS version it is okay to reclassify it to 5.x-dev.
Now, this is going to be a lot of work without much benefit if you do this across every minor release (beta1, beta2, rc1, rc2) so I recommend only switching the version from a specific release to -dev if you are making already making a comment to the issue for some other reason: you reviewed the patch, have an idea, are improving the title, etc.
The place where it is helpful is when you specifically test old bugs (x.y.z, 4.7, 4.6, etc.) and report on whether they still exist in 5.x-dev (or whatever the currently developed version of Drupal is). That is to say: the value is in confirming or disconfirming that they exist, not in the reclassification itself.
Indeed this is true - I've done a bit of work on this as well. It is often enlightening to see old duplicate issues, because certain comments may have been made in the past but not in the most recent issue that shed light on a bug or possible solution. Sometimes the earlier issue will have a better solution than what is proposed in the most recent issue.
What I have found interesting is that on occasion a bug will be found and quickly fixed and only later will someone learn that it was a duplicate and the earlier issue had a similar (or exactly the same in some cases) patch posted, but no one reviewed it for whatever reason. Triaging can be very helpful in reducing the likelihood of this wasted effort.
http://drupal.org/node/73179 and the other pages in that area are a good place to start. They could all use some editing and reorganization.
Groups.drupal.org would be the place to discuss potential guidelines but as Brandon says they should ultimately be stored in the handbook. I joined the group you made and can help with the development of the guidelines. http://groups.drupal.org/reviewers is a related (and somewhat defunct) group.
Substantial Changes
You're right, and I'll take care to avoid making changes to bugs that don't add useful information. I've been struggling with a hypothetical scenario: Suppose I add a response to an issue asking the user who submitted it to confirm they still have the problem. I would guess, for very old issues, that they may not do so. Would it be alright in those cases to simply close the bug and mark it as won't fix? What sort of time frame should they be allowed?
Also, editing of the handbook pages seems to be restricted. Should I use the "Suggest documentation improvements" quick link to submit new text?
Thanks for your advice.
In general I think it's best
In general I think it's best to be conservative in issue editing: only close or won't fix bugs when it seems to be the accurate response.
If you are dealing with very old issues, you're right that asking the original submitter to confirm the bug is unlikely to be fruitful. However, closing or won't fixing the bug does not add value by itself: a status change is not warranted unless you have specifically confirmed or denied the bug.
If possible one should personally confirm or deny the existence of the bug in HEAD, and edit the issue accordingly. Browsing through the CVS logs or looking at changes to specific modules can also give you clues as to the status of the issue.
If you don't feel equipped to evaluate the issue it's best to just leave it alone. It doesn't hurt anything to have old bugs in the queue, and is preferable to prematurely closing bugs that still exist.
Of course these are my own opinions and other developers might disagree with me.
There are three pages of
Yes, they should be always be confirmed to development branch. In this case 5.x-dev
No, it shouldn't. project.module shouldn't allow any 'features' except for the top development branch (in this case 6.x-dev). In the case of 'tasks', these can be some tweeks that I prefer to call them 'minor bugs'.
Agree.
Strongly agree.
I disagree. An old bug that is still open is much more confusing, than if it was closed. This is obvious when there are big code changes (eg. from 4.6 to 5)
Anyway, my current steps (were) are:
* cleared 4.5 queue
* cleared 4.6 queue until I cannot do more (has CNR and CNW bugs that must be addressed by senior developers)
* clear 4.7 queue
* clear x.y.z queue
A smaller (and controlled) queue gets more attention from developers, allowing bugs to be better and quickly solved.
Note that my definition of clear is: confirm, reclassify and call attention (always from older to newer issues)
BTW: with 4 more bugs I break the 1.000 bugs mark :)
----------
Fernando Silva
Openquest - Sistemas de Informação, Lda
Important!!!
Just a big exception: critical bugs from older branches should only be closed by "senior developers".
Remember that a critical bug, assumes greater responsibility than a normal bug, specially if it affects security.
----------
Fernando Silva
Openquest - Sistemas de Informação, Lda
What to do if the contribution no longer exists?
I am quite happy to close issues through triaging efforts. Sometimes however the module or theme it pertains to no longer exists and the issue cannot be closed (mandatory field empty). There should be a discipline in closing outstanding feature requests or bugs and not leave them dangling. How to approach this problem?