Posted by catch on February 14, 2008 at 1:12am
| Project: | Drupal.org customizations |
| Version: | 6.x-3.x-dev |
| Component: | Code |
| Category: | task |
| Priority: | major |
| Assigned: | Unassigned |
| Status: | closed (fixed) |
Issue Summary
I just saw they got bumped to D7. This is good, but I'd prefer it more fine-grained if possible.
Something like:
D6 pending bugs
D6 criticals
D7 patch queue
D7 patches to review
So it's easy to keep an eye on post-release D6 issues without having to use bookmarks or any of that crazy stuff.
Comments
#1
Also, the counts still refer to D6 queues (click on "0 criticals"). I thought this was cron not having run yet when I originally posted.
#2
That's goverened by drupalorg.module (in contrib HEAD). Just committed this change: http://cvs.drupal.org/viewcvs/drupal/contributions/modules/drupalorg/dru... Note that drupalorg module is also limited to tracking counts for only one set of release node numbers, so the mixed Drupal 7 + 6 counting needs to be implemented as well here, not only a change of links in the block.
drupalorg module still needs to be cvs updated on drupal.org.
#3
cvs up done
#4
Ooh new shiny D7 counts. Thanks! Will leave open for D6 bug counts if people think it's a good idea.
#5
#6
I think this is indeed a good idea but does need some feature development.
#7
Time to do this again.
Apart from bumping to 8.x, I'd propose the following changes:
1. Include 'Patch (to be ported)' in the issue listings - this applies to 7.x security patches being forward ported to 8.x, and 8.x backports to 7.x - both currently get a bit hidden when set to that status.
2. If it's easy, have a single link to 8.x + 7.x critical issues (so we know how many criticals total against both versions), if not, add a new line for 7.x criticals so that these can be easily tracked.
I haven't done any d.o. patches (or at least not for a very long time), but if no-one jumps on this I'll try to figure it out.
#8
Arguably D7 major issues could be added here as well.
#9
Here's an initial patch. I don't have d.o testing profile set up locally, so no testing beyond php -l.
I went for separate links for each version, because that's a lot simpler - and running a couple of extra queries that are the same structure is less of a change than making = an IN(). Also I'm not convinced combined issue lists will be that helpful compared to two separate ones.
#10
Would it make sense to make the D7 links available as a separate block? Maybe even add a block for D6 links as well, but keep the main contributor links block for D8?
#11
Fixed a few variable names in this chunk:
<?php$counts_pending = $counts[DRUPALORG_CORE_VERSION_TID]['Pending bugs'];
$counts_critical_stable = $counts[DRUPALORG_CORE_VERSION_TID]['Critical issues'];
$counts_major_stable = $counts[DRUPALORG_CORE_VERSION_TID]['Major issues'];
$counts_queue = $counts[DRUPALORG_CORE_VERSION_TID]['Patch queue'];
$counts_review = $counts[DRUPALORG_CORE_VERSION_TID]['Patches to review'];
$counts_critical = $counts[DRUPALORG_CORE_DEVELOPMENT_VERSION_TID]['Critical issues'];
$counts_major = $counts[DRUPALORG_CORE_DEVELOPMENT_VERSION_TID]['Major issues'];
?>
Otherwise looks good to me, unless anyone has any comments about breaking 7 issues out into a separate block (just the links under 'queues').
#12
Whoops, looking at that, a couple of the contants are wrong still.
This renames the contants which don't seemed to be used anywhere else in drupalorg or any of it's modules (I greped through bzr checkout).
Also applied this on http://project.redesign.devdrupal.org/ but that DB needs refreshed since it doesn't have the proper term for 8.x in it yet.
#13
Separate block - I'm not sure either way.
I kind of want them in the same block, because we have continual confusion on the core development process, and people who are new and want to track D7 issues, may not realise that all the work is being done against D8 for those issues too. Too many times with D7, I forgot to filter on D7 issues and discovered a load of working being done in D6 issues that should've been tracked against D7 (including completely duplicate issues because they were duplicate across the two versions). That's a harder problem to solve than this block though.
#14
+++ b/drupalorg_project/drupalorg_project.moduleundefined@@ -4,16 +4,26 @@
+define('DRUPALORG_CORE_DEVELOPMENT_VERSION_NAME', '8x');
Changed this to 8.x
#15
Caught one constant hiding in a loop.
#16
Committed, tagging for deployment.
#17
Deployed.
#18
Woo! Thanks mikey_p and drumm for fixing this up!
#19
Followup issue for those interested: #1155604: Move pending bugs below patches in contributors block.
#20
Automatically closed -- issue fixed for 2 weeks with no activity.