Gerhard Killesreiter schrieb:
Let me illustrate the "why".
I am in the process of writing a slightly changed version of the dblog module. Most of the changes will be in the .install file.
While I do think my changes are a good idea, others might disagree. It is one of the patches where Dries was more stubborn than me after all (http://drupal.org/node/78503, for the interested reader).
Now, should I really call this dblog and use the 6--2 branch
Alex is only talking about backporting patches which are actually in Drupal 7 already (as far as I know), so assuming that patch gets refreshed and committed, why not? A module with an issue queue is better than people clamouring for 'can I have a D6 version of this patch plz' on fixed issues in the core queue which are never going to get a straight backport in core itself. However I think using the actual namespace for the module does bring up some issues (hook_update_N() and just general potential confusion) - so we could consider aggregator_backport and dblog_backport or something instead (or at least really, really clear and standard descriptions on project pages). Another example where this is has happened already is tracker2 (which runs on Drupal.org) - although the issue it fixes is still a critical bug in HEAD and hasn't been updated in a while - hence why I think a 2.x branch of core modules is a good idea - it saves having to manually apply patches, fork, or reinvent the wheel - all of which has happened with aggregator, tracker, comment and others to various levels of success and confusion. Nat