Bump all CNW/CNR 6.x issues to 7.x
catch - March 9, 2008 - 22:20
| Project: | Drupal.org webmasters |
| Component: | Other |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | active |
Jump to:
Description
There are nine pages of patches CNR and eight pages of patches CNW against D6. I'd guess 98% of them should be against D7, and the rest are being actively worked on. So it'd be lovely if we could do a one-off database update to bump them all up a version - hopefully that way we'll get a few less duplicate issues during the D7 cycle.
Yes I realise I should've filed this the day 6.0 was released. Would still save a lot of manual triage though.
#1
I do not understand why bugs should be fixed in HEAD first, then backported to a release?
Counter arguments:
1. The amount of real world sites running HEAD are minuscule, so patches will only be tested on dedicated HEAD installs.
2. More people have experience with a release which _could_ result in better tested patches (right).
3. Having a bug fix in a release is more valuable (to me) than having it in unused HEAD.
4. Just bumping a version: when a bug has been reported as being valid for a certain version, _keep_ it that version, or independently confirm its existence in HEAD.
#2
Tasks and feature requests ought to be bumped to D7 whatever happens IMO. Bugs I agree are a grey area.
It was my impression that the "fix in HEAD then backport" workflow was to 1. ensure consistency between branches where they've not already diverged 2. reduce work for the non-development branch maintainer.
Another option would be to change the contributor links to point to D6 bugs as requested here. For me, I never look at 6.x issues because the contributor links don't point to them.
#3
Has this task been done, or has been decided that the issues should not be changed as reported?