[development] Reviewing patches and making decisions

[Nathaniel Catchpole]

On Wed, Nov 5, 2008 at 2:59 PM, Chris Johnson
>
>
>
> This has always been the assumption -- that there is more development
> in the newest version than in older versions.  But it has always just
> been an assumption without proof -- and even I feel it was probably
> true most of the time, or in the past.
>
> If one only measures core development, than of course it's true,
> simply because past core releases are essentially frozen except
> security fixes.


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.


>
> But right now, I would bet far more effort is being spent on Drupal 6
> development than on Drupal 7 development.  And it's part of this
> topic's problem.
>
> Issues and patches are piling up in the Drupal 6 issue queues, but the
> push is to look at Drupal 7 development.
>
> For example, I'm spending 100% of my effort to build Drupal 6
> websites.  I find a bunch of bugs in D6.  I write issues and post
> patches.  My motivation to check for the same problem in D7 and then
> develop a D7 patch, is going to be considerably less than my
> motivation for D6.


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.



>  I might not even be able to do that, if the D7
> code is not sufficiently ready or stable.


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.



>  If I'm already waiting for
> patches to be applied to D6 modules, I'm not going to be interested in
> waiting even longer to have them applied to D7 and then get backported
> to D6.  I need the fix yesterday, not next year.


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.

An example from this week:
http://drupal.org/node/329646 opened on third november.

Fixed in both Drupal 6 and Drupal 7 on 4th November
http://drupal.org/cvs?commit=151247
http://drupal.org/cvs?commit=151248

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?


> Really it's all about every member of the community having a different
> agenda, and everyone is negotiating with the community to get as much
> support for their own agenda as possible.  Some people have more
> influence than others or more power than others in these negotiations
> (the Drupal community is much like the rest of life in this regard,
> after all).
>
> The question is whether the majority should continue to be facilitate
> the agenda of the minority, or if the majority should stand up, notice
> that it is the majority, and push more strongly for what they want.


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.

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'.

Nat
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20081105/20ba716c/attachment-0001.htm