[development] Reviewing patches and making decisions

[Nathaniel Catchpole]

On Wed, Nov 5, 2008 at 10:51 AM, Anselm wrote:

>
> >
>
> So the implication here is that if a patch potentially causes backward
> compatibility problems with existing modules, then it should be moved to
> the
> next major release, while issues that are clearly fixing bugs can remain in
> the current release.
>

Almost. Issues fixing bugs that are still bugs in the next major release
should always be fixed in that release first, then backported to Drupal 6
and/or Drupal 5.

That way, we don't have bugs fixed in Drupal 6 which then crop up again in
Drupal 7, and there's also much more active development there, which
generally means more people available to review and refine proposed fixes
for any given issue.

When this works well, it means that fixing the bug in Drupal 6 can be as
simple as committing the same patch to that branch, or a quick re-roll and
commit - this is much harder to do the other way 'round.

If the code has completely changed in the next release up, then it's fine to
keep them where they are of course - but that's also worth noting in the
issue. If you find patches posted against Drupal 6 which ought to be fixed
in Drupal 7 first, moving them up a release is valuable in itself - the
'patch queue' defaults to Drupal 7, so those of us who rely on that to keep
with things only see stuff that's in there unless we're pointed to something
specifically.

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