Closed (fixed)
Project:
Drupal.org customizations
Version:
6.x-3.x-dev
Component:
Code
Priority:
Major
Category:
Task
Assigned:
Unassigned
Reporter:
Created:
14 Feb 2008 at 01:12 UTC
Updated:
23 May 2014 at 18:23 UTC
Jump to comment: Most recent, Most recent file
Comments
Comment #1
catchAlso, the counts still refer to D6 queues (click on "0 criticals"). I thought this was cron not having run yet when I originally posted.
Comment #2
gábor hojtsyThat'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.
Comment #3
gerhard killesreiter commentedcvs up done
Comment #4
catchOoh new shiny D7 counts. Thanks! Will leave open for D6 bug counts if people think it's a good idea.
Comment #5
catchComment #6
gábor hojtsyI think this is indeed a good idea but does need some feature development.
Comment #7
catchTime 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.
Comment #8
catchArguably D7 major issues could be added here as well.
Comment #9
catchHere'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.
Comment #10
mikey_p commentedWould 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?
Comment #11
mikey_p commentedFixed a few variable names in this chunk:
Otherwise looks good to me, unless anyone has any comments about breaking 7 issues out into a separate block (just the links under 'queues').
Comment #12
mikey_p commentedWhoops, 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.
Comment #13
catchSeparate 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.
Comment #14
mikey_p commentedChanged this to 8.x
Comment #15
mikey_p commentedCaught one constant hiding in a loop.
Comment #16
mikey_p commentedCommitted, tagging for deployment.
Comment #17
drummDeployed.
Comment #18
catchWoo! Thanks mikey_p and drumm for fixing this up!
Comment #19
catchFollowup issue for those interested: #1155604: Move pending bugs below patches in contributors block.