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.
I would like to see a "port" category added to the project module..
alongside bug, task, feature etc. I believe this will make it easier
to ensure that fixes are backported/checked promptly and correctly.
Comment | File | Size | Author |
---|---|---|---|
#2 | project_issue_port.patch_1.txt | 1.24 KB | dww |
#1 | project_issue_port.patch.txt | 1.22 KB | dww |
Comments
Comment #1
dwwi'm not sure i love the name 'port' for this. i'd be happy to entertain alternate proposals. ;) but, here's a patch for now, pending any better suggestions...
Comment #2
dww"port request"? looks an awful lot like "support request" ;)
"backport request" is both pretty long and not always accurate (could be something that needs "forward" porting to HEAD or some such)...
still torn on what to call this thing.
Comment #3
moonray CreditAttribution: moonray commentedHow about plain "Porting"?
Comment #4
dwwspoke to dries about this and he's pretty strongly opposed. feature vs. bug is far more important than 'port'. if anything, this should be a complementary field, not a new category of issue. but a whole new field/property just for this is a ton of work. moreover, you can just bump the issue to the right target version.
if we were really slick, we'd let you assign the issue to someone else, so dries/drumm could bump the version to 4.7.x-dev and assign to killes when they wanted something backported. that's another issue entirely.
anyway, in spite of the simplicity of the code changes involved with this approach, it would clobber/mask useful information (you'd have to remember to reset the category back to 'bug' when done), and it's likely to confuse end users trying to submit new bug/feature issues.
therefore, "won't fix"...
sorry, zen. ;)
-derek
Comment #5
Zen CreditAttribution: Zen commentedI actually agree.. it would be better off as a status option rather than a category.. "code (patch to be ported)" or some such.
-K
Comment #6
dwwif that's all we want, this is just a d.o infra request, since there's a settings page to add additional status values:
http://drupal.org/admin/settings/project_issue/status
no need to change project_issue.module for this, since the hard-coded default status values are already way too specific for our needs as it is. ;) i'd be happy to add this, so long as:
a) killes/dries/et al agree it's worth doing and
b) we agree on the name
there was a thread somewhere about renaming our existing status values to be shorter to help people w/ busted browsers. instead of adding to that problem, how about just calling it:
"patch (port needed)" ?
i'm still a little worried this extra choice will confuse people, but i guess that'd be true no matter what we do. we should consider where/how to document the new status in a way people will actually read it.
thanks,
-derek
Comment #7
Zen CreditAttribution: Zen commentedpatch (to be ported) is sufficient IMO.
As for easing the confusion to non-technical users, I suggest linking to pages like http://drupal.org/node/45111 (in a section dedicated to the issue tracker) in the issue form.
Thanks Derek.
-K
Comment #8
killes@www.drop.org CreditAttribution: killes@www.drop.org commentedI think a new patch category would be ok, will add one, shouldn't I hear otherwise.
Comment #9
dwwadded the status, and gave the appropriate roles permission to set it.
Comment #10
(not verified) CreditAttribution: commented