On Wed, Nov 5, 2008 at 2:59 PM, Chris Johnson <div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"><div class="Ih2E3d"><br>
<br>
</div>This has always been the assumption -- that there is more development<br>
in the newest version than in older versions. But it has always just<br>
been an assumption without proof -- and even I feel it was probably<br>
true most of the time, or in the past.<br>
<br>
If one only measures core development, than of course it's true,<br>
simply because past core releases are essentially frozen except<br>
security fixes.</blockquote><div> </div><div>Exactly, and we're talking about core patches. Most active contrib development is happening in Drupal 6, I generally don't see many patches posted for Drupal 4.7 versions of contrib modules, or even Drupal 5 depending on which module it is. <br>
</div><div> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
But right now, I would bet far more effort is being spent on Drupal 6<br>
development than on Drupal 7 development. And it's part of this<br>
topic's problem.<br>
<br>
Issues and patches are piling up in the Drupal 6 issue queues, but the<br>
push is to look at Drupal 7 development.<br>
<br>
For example, I'm spending 100% of my effort to build Drupal 6<br>
websites. I find a bunch of bugs in D6. I write issues and post<br>
patches. My motivation to check for the same problem in D7 and then<br>
develop a D7 patch, is going to be considerably less than my<br>
motivation for D6.</blockquote><div> </div><div>Well you could post the patch against D7 without verifying, someone watching that queue will take a look (if they have time), and if it doesn't apply to D7, move it back to D6, or re-roll for Drupal 7. This happens regularly, stating that the patch was rolled against Drupal 6 is all you need to do here.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I might not even be able to do that, if the D7<br>
code is not sufficiently ready or stable.</blockquote><div> </div><div>D7 is exceptionally stable due to many hundreds of automated tests. Getting tests written to prevent bugs reappearing is one of the many reasons that doing active development there is useful. Since the tests verify that the bug is fixed (assuming they're written properly), then in general you're more likely to get a decent fix, and one that doesn't cause regressions elsewhere. And supplying patches with tests gets them committed much, much faster.<br>
<br> </div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> If I'm already waiting for<br>
patches to be applied to D6 modules, I'm not going to be interested in<br>
waiting even longer to have them applied to D7 and then get backported<br>
to D6. I need the fix yesterday, not next year.</blockquote><div> </div><div>Patches can get applied to Drupal 7 in as little as a few hours, depending on the patch, the availability of reviewers and core maintainers.<br>
<br>An example from this week:<br><a href="http://drupal.org/node/329646">http://drupal.org/node/329646</a> opened on third november.<br><br>Fixed in both Drupal 6 and Drupal 7 on 4th November<br><a href="http://drupal.org/cvs?commit=151247">http://drupal.org/cvs?commit=151247</a><br>
<a href="http://drupal.org/cvs?commit=151248">http://drupal.org/cvs?commit=151248</a><br><br>In which way is this slower than ignoring advice, posting a patch to the Drupal 6 queue, then trying to cajole a small number of over-stretched volunteers to change their workflow?<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>
Really it's all about every member of the community having a different<br>
agenda, and everyone is negotiating with the community to get as much<br>
support for their own agenda as possible. Some people have more<br>
influence than others or more power than others in these negotiations<br>
(the Drupal community is much like the rest of life in this regard,<br>
after all).<br>
<br>
The question is whether the majority should continue to be facilitate<br>
the agenda of the minority, or if the majority should stand up, notice<br>
that it is the majority, and push more strongly for what they want.</blockquote><div><br>Well, the smallest minority is the core maintainers. There's two for Drupal 7, two for Drupal 6 (obviously Dries gets counted twice, so that's actually three people for both branches). Since only Dries can commit to both branches (like the example above), something has the best chance of being fixed in both branches if it's submitted to the Drupal 7 queue first of all. Also, webchick has a lot more time allocated to core development than Gabor, since Drupal 6 is in maintenance. If a patch goes through the review and RTBC cycle in Drupal 7, then more times than not it's a quick look over and commit for Drupal 6 - expecting all the back and forth of a core commit to happen in a maintenance release is asking too much IMO - Drupal 6 is likely to have a 2-3 year release cycle, after all.<br>
<br>The other minority you're talking about is those actively working on core development on a regular (i.e. daily) basis - i.e. the people who are actually reviewing and RTBC-ing those patches. As far as I know , the majority of that minority prefers the current workflow too. This is volunteer project, and the ony real power as such lies with those with commit access - people can make their voices heard by complaining on the development list, or by getting stuck in, and change gets made on the strength of arguments. I've not actually seen any arguments put forward for changing the current workflow, except that some people 'don't have time'.<br>
<br>Nat<br></div></div>