I have found a typical pattern in the Drupal issue queue.
- A user identifies a problem in Drupal 6.x, and files a bug report (or feature request). Maybe someone even writes a D6 patch.
- Developers switch the issue's version to 7.x, and ask for a D7 patch.
- The issue is fixed for D7 and then marked as fixed.
- Noone does a backport. And even if that is for a reason, there is no clear indication of "won't fix for D6".

What is the correct procedure to avoid this pattern? Switch the issue back to D6, once it's fixed for D7?

Otherwise, do we need to change the issue workflow to take better reflect different Drupal versions?
For instance, there could be independent states for each Drupal version, like this:
D7 -> fixed in CVS, release in 7.01 or later
D6 -> needs work
D5 -> does not apply (functionality did not exist, so nothing to fix)

Comments

avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented
Project: Drupal.org infrastructure » Drupal.org site moderators

An issue is first fixed in Drupal 7, and then (eventually) in Drupal 6. If the issue applies for Drupal 6, then the status of the report should be changed in patch (to be ported) to mean the patch needs to be modified for the other Drupal versions.

donquixote’s picture

donquixote commented

Thanks for the explanation KiamLaLuno!

It seems the general policy is that only security issues and bug fixes are backported, not feature requests. For some issues this causes discussion about whether it's a feature or a bug, see
#29706-278: More secure password hashing
#493984: Passwords should be salted

I think that D6 will be around for a few years, it might even remain the top choice for new sites for quite some time (waiting for D7 contrib).

I am not really happy with the feature freeze idea, but this is just my personal opinion. So far I did not find a place where this policy is documented, and I did not find a place where it can be debated. I think it would be a good idea to make this information more visible.

grendzy’s picture

grendzy commented

I definitely agree the policy on stable releases could be better documented. At least, I personally wasn't able to find a "citation" for donquixote's question.

Perhaps this handbook page would be a good place to start:
Criteria for evaluating proposed changes

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented
Status: Active » Fixed

Tags tags tags...

The correct procedure for issues that need backporting (bug reports) is to tag an issue with 'needs backport to D6' or 'needs backport to D5'. We can then periodically review any D7 closed for fixed issues that haven't had their versions changed or backports started and we can change the status of those issues to 'patch (to be ported)'.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

donquixote’s picture

donquixote commented
Project: Drupal.org site moderators » Documentation
Component: Other » New documentation
Category: support » task
Status: Closed (fixed) » Active

issues that need backporting (bug reports)

Ok, what I understand here:
Bug fixes need backporting, everything else not.
Edge cases are severe performance fixes and security-related issues (see the examples above).

Wouldn't it be a good idea to write a manual page about this policy and its motivations? I think it's a central piece of the Drupal project, and the manual page could be linked to from other issues where people are begging for D6 features. It could also be a starting point for debates on such policies - either directly in the comment, or by links pointing to whatever discussion place.

I'm not going to start this myself, because I'm the very last to know about the motivations for the current backport policy.

EDIT:
The page suggested in #3 is a start, but it does not give the necessary answers.

grendzy’s picture

grendzy commented
Title: Issue workflow and backporting » Improve docs for Issue workflow and backporting

OK, I suggest a 2-part approach:
-- Add a bullet to criteria for evaluating proposed changes explaining the policy on new features / stable releases.

-- Link to this guide directly on the issue submission form. See #611894: Offer advice for feature requesters on /node/add/project-issue/drupal in the infrastructure queue for details on this proposal.

thoughts?

grendzy’s picture

grendzy commented
Status: Active » Fixed

I've updated the handbook page, and KiamLaLuno updated the text on the issue submission form.

donquixote’s picture

donquixote commented

Hmm.. one implication of the backport policy is that once a project is moved to core (such as CCK or imagecache), it will no longer get any new features implemented for D6 or D7 - correct? Wouldn't this mean, it is better not to move things into core?

avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented

If a module is moved to core in Drupal 7, I would expect that the version for Drupal 6 is still open to feature requests.
I didn't read the back port policy, but a back port is different from implementing a feature in the previous version of the module.

dave reid’s picture

dave reid
he/him
Primary language English
Location Nebraska USA
commented

There is no general backporting policy for modules and their maintainers. They can do what ever they want. They can implement their own policy or follow core's. Just because a module is moved to a future core version (Drupal 7) doesn't mean that they need to stop with features in their current version, but it's probably in their best interest to make sure that they slow down or shut off the feature requests as to ease the transition/upgrade process.

donquixote’s picture

donquixote commented

I was more thinking of D7:
If imagecache goes into core (which I read here: #371374: Add ImageCache UI Core), as I understand, this means an API freeze for imagecache in D7. The same for "fields in core" (CCK).
Actually I'm not that worried about feature freeze, if features can be added by additional contrib modules. But API freeze, in the sense that no new hooks can be added, that's a pity.

Example: Password salting + stretching (see above). If "user" was a contributed module, we would long have seen a solution in D6 (that does not use the workarounds of hook_form_alter)

avpaderno’s picture

avpaderno
he/him
Primary language Italian
Location Brescia, 🇮🇹 🇪🇺
commented

API freeze just means that there will not be any changes in Drupal 7 API, which will be applied to the successive Drupal version (Drupal 8, in this case).

grendzy’s picture

grendzy commented

Wouldn't this mean, it is better not to move things into core?

Just my opinion, but yes sometimes it's better for modules to stay in contrib, where they can evolve at a faster pace. Just because a module is important to the ecosystem doesn't mean it necessarily belongs in core. Core modules need to be mature enough to endure a 1-2 year release cycle, and ideally have a robust API to allow contrib to build on their functionality.

grendzy’s picture

grendzy commented

that does not use the workarounds of hook_form_alter

Didn't you know? hook_form_alter is the cause of, and solution to, all of life's problems. :-)

donquixote’s picture

donquixote commented

It feels a bit stupid having a separate password system hooked in at form level, instead of data level. But maybe I need to get used to it.

Status: Fixed » Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

donquixote’s picture

donquixote commented

"Backport policy"
http://drupal.org/node/767608

Information in this article should be checked by someone other than me.