Bugfix woes for Drupal 6
Heine —Sun, 2009/09/13 - 10:55
The bugfixing procedure for Drupal 6 is, to say the least, "suboptimal".
Witness Issue #261258, that's been with us since Drupal 6.0. Thirteen releases later and the bug is still present.
Why, you ask? Because bugs should be fixed in HEAD (future release of Drupal) first, before being backported to 6.x-dev.
The advantage of this procedure is that Drupal 6 bugfixes will get the same test-coverage as the HEAD bugfix.( Of course, this test-coverage runs the bugfix code in a different code context than Drupal 6, but only Negative Nancy here would point that out).
Another advantage of the HEAD first procedure is that you prevent regressions, where a bug is fixed in 6.x, but not in 7.x.
Unfortunately, working first on HEAD increases the load on patch submitters as they have to install and work with the development version of a new version, unknown and (perhaps) of little interest to them. They also need to supply tests. In other words: Bugfixing the current release is limited to the core contributors working on the next release.
And then comes the additional trouble; The HEAD bugfix is allowed to introduce massive refactoring of existing code and functionality. This usually takes time as it comes with a lot of bikeshedding discussion. The resulting fix may not even apply to Drupal 6.
I hope this last point of trouble gets eliminated when HEAD gets into code freeze.
Now, I don't really have a solution to this problem. Perhaps we should start to file duplicate issues for Drupal 6 when an issue for HEAD gets into refactoring mode?
Comments
"Scratch your own itch"
Submitted by mikeytown2 (not verified) on Sun, 2009/09/13 - 12:07If you want a bugfix to go in, put your head down and get it done. Own the bug, make it yours.
Here's my first bugfix that went in to 7.x and then 6.x
http://drupal.org/node/276615
I recommend getting your issue to a "needs review" status; code talks, last patch was over a year ago.
Missing the point
Submitted by Heine on Sun, 2009/09/13 - 12:16You might be missing the point. It is not about this specific bug, it's about the bugfix procedure impeding fixes going into Drupal 6. edited to add: There are people who don't want to refactor code and design new API's for Drupal 7. All they want & need is a fix for the bug they experience. If they are willing to provide this, why impede progress?
Needs Review is not enough
Submitted by jhodgdon (not verified) on Sun, 2009/09/13 - 18:17I have had several issues for Drupal 7 that I patched and got to Needs Review status, and they sat there for months, with no one reviewing them at all (positively or negatively). It was very discouraging, since they were all worthy changes (in my opinion), up to code standards, with tests and documentation of the performance impact of the changes, and the changes were important for some users at least. This is just to point out that making a patch and getting it to "needs review", and making a case in an issue for its importance, is *not* enough to get it through. This has made me even more discouraged than Heine about the Drupal development process, so much so that I probably will never attempt to contribute a code patch to core again.
I will say that I've had quite a bit of success with documentation-only issues that I've patched (i.e. patching doc in core that gets displayed on api.drupal.org). It is not so hard to find people interested in documentation ot review those issues, so the lag is only weeks in most cases, the feedback has been constructive, and Dries and Webchick have been quite willing to commit them to Drupal 7... though once they're backported to Drupal 6, there's usually a delay of weeks to months before they get put into Drupal 6 (I think Gabor has been busy...).
--jhodgdon
core contribution
Submitted by Pasqualle (not verified) on Sun, 2009/09/13 - 19:39you want your patches to be reviewed, then try to help cleaning up the queue also: needs review
don't give up, every issue will be closed someday http://drupal.org/node/8
issues waiting for Gabor:
would you commit them? are you sure they won't break anything? It is much easier to commit something into D7..
missing the point
Submitted by Anonyous (not verified) on Mon, 2009/09/14 - 17:21I would hardly point to http://drupal.org/node/8 as motivation for core contributing. I've seen this speech about being tenacious many times. Those that say it simply don't get that there are people with other things to do, that want to contribute to core, but that won't endure this type of time sink as the price to pay to do it. Not to mention the burn out experienced by those that bite the bullet, take up the flag, dedicate hundreds of hours of effort toward core, only to have it kyboshed at the 11th hour.
You can rationalize it all you want, but the fact remains that core contributors will be scare as long as this is sop.
backport
Submitted by Pasqualle (not verified) on Sun, 2009/09/13 - 19:17yes, that's a good reason to create a separate issue for D6..
anyone with a d.o account can be a core contributor, there is no limitation.
the advantage of this procedure is that issues get the required attention. The fact is, that there are not enough resources to work on two different versions of Drupal (or contrib module)..
Balance
Submitted by Heine on Sun, 2009/09/13 - 20:43What I meant with "bugfixing the current release is limited to the core contributors working on the next release" is that people who want to fix something in Drupal 6, first have to get up to speed with HEAD.
The drawback of the current procedure is clearly that the current release doesn't get enough attention; issues in HEAD feel much less urgent than issues affecting one's site. Much more people are able to test on the current release (even in production, if they desire so) than HEAD.
We need to find a balance so we get enough attention to issues, and fix bugs fast enough in the current release, while not getting regressions in HEAD.
core bugs
Submitted by Christopher Pelham (not verified) on Mon, 2009/09/14 - 00:44To me, addressing bugs in an official release that hundreds of thousands of people are actually using right now should be prioritized much higher than preparing a future release. Just like security fixes are handled ASAP, why aren't bugs? What is the case for prioritizing the development of future features over eliminating bugs in live code? I'm not saying you don't have a case but it would be interesting and helpful to make that case clear and public.
My point was more or less
Submitted by Heine on Mon, 2009/09/14 - 14:42My point was more or less that Drupal 6 bugfixes are delayed because of this procedure. Negative Nancy would like to speed this up, without causing regressions in HEAD.
I agree
Submitted by Michelle (not verified) on Mon, 2009/09/14 - 03:15I don't have a solution, either, but I can sympathize. I am not likely to use Drupal 7 on a real site for at least a year, if ever. I am focused on Drupal 6. There are many people in the same boat. If something is broken in 6, we need it fixed in 6.
Michelle
Good point
Submitted by ksenzee (not verified) on Mon, 2009/09/14 - 16:29The current procedure would make sense -- nobody wants regressions, after all -- if it didn't break down so badly. Maybe instead of requiring a fix in HEAD first, we should just require a patch for HEAD at the same time as a patch for the current version, and require that they be worked on at the same time. Gabor could refuse to commit the D6 fix unless the D7 issue is progressing as well.
automated testing vs. "time will tell" testing
Submitted by Gábor Hojtsy (not verified) on Tue, 2009/09/15 - 09:32The problem with this approach is that Drupal 6 fixes get out to live sites much more quickly and we have no automated tests to verify anything. People click around on some pages, but getting a fix into a released Drupal 6 version is much harder to modify later, so if feedback on the issue turns out resulting bugs or side effects, the bugos Drupal 6 release will be out and on live sites for quite some time until another release can come around to fix. A practical example is http://drupal.org/node/292565 which was fixed 3 times already and different Drupal 6 releases contained different bugs due to me being proactive in trying to fix and release fixes as soon as possible.
The Drupal 7 way is to have automated tests and verify that way for quicker development, the pre Drupal 7 way was/is to wait more and see whether people see issues with the fix.
We don't want regressions in
Submitted by Pelle (not verified) on Mon, 2009/09/14 - 18:43We don't want regressions in HEAD once HEAD is released - but sometimes fixing a bug in HEAD might be work that leads nowhere since that bug is going to solved anyway through a more major refactoring.
One example of that is this issue: http://drupal.org/node/374463
While it fixed the bug in Drupal 6 pretty immediately it never got good enough for Drupal 7 and once it was resurrected it was no longer relevant to fix the bug in Drupal 7.
Not fixing a bug in D7 while fixing it in D6 means a regression in a version of Drupal that no one uses and no one are affected by - as long as that bug is fixed before D7 is released it won't matter if it was fixed in D7 first or not - but it will matter if it's fixed in D6 as soon as possible.
I would love to see a polish
Submitted by Tao Starbow (not verified) on Mon, 2009/09/14 - 23:43I would love to see a polish release. Maybe a year after the main release, folks take a break from working on the next version of Drupal, and take some time to focus just fixing bugs, UI inconsistencies and API mistakes. No functionality changes, no new features, just polish. I bet there would be a ton of folks that wanted to contribute to that effort.