Patches, and why they aren't being integrated

People have asked off-list why patches weren't being integrated.
For whom it may concern, here are the reasons that come to mind.

1. Cost of reviewing

  As a general rule, I don't integrate code without reviewing it.
  Reviewing code, especially code you have not written and don't
  understand /a priori/, is hard work. In fact, validating code
  written by someone else can take more time and effort than
  writing it yourself from scratch.

  Reviewing code is also a lot less fun than writing or designing,
  at least to me. Clearly, your patch better be interesting if
  it's to be integrated.

2. Maintainer time

  I don't have much free time and am not always able and willing
  to spend it on Yadex. And yes, sometimes a year or more will
  pass until I find myself with nothing more urgent and motivating
  to do today than processing your patch.

3. Timing

  At this point in the development of Yadex, the top priority as I
  see it is not adding features, it's improving the architecture.
  Specifically,

  - rewrite the wad directory handling code,

  - replace the level data globals by a Level class,

  - replace EditorLoop() by something sane,

  - modify the game definition code to support includes,
    alternative sorting methods, and a programmatic access to
    details of linedef types.

  These changes will bring enormous benefits, directly or
  indirectly. Undo (which in turn solves the problem of having to
  confirm every little change). Editing several levels at once.
  Doing cut and paste across levels. No more P_START/P_END
  problems.  Better consistency checking. Console mode and
  multiple-keystroke bindings, which means not having to rack
  one's brain for a good shortcut anymore, which in turn means
  it's going to be a lot easier to add functions. Macros.
  Customisable bindings (and bindings cheat-sheet for free).
  Better linedef type selector. Mouse tools à la Mac (or Gimp).

  Now, most patches I get are about adding features over the
  exisiting architecture. Desirable as those features may be, they
  distract me from what I think I should be doing first. They also
  add to my workload because they add more code that will have to
  be updated after the rewrites. The patches that touch
  EditorLoop() are the worst.

4. Sequence

  There are quite a few patches in my to-do list. Maybe yours
  isn't being processed because others have been submitted earlier
  and are still waiting for me to look at them.

  Sometimes, I'll let a patch jump the queue if it's a no-brainer
  (E.G. a bug fix), or if its value/cost ratio is high enough
  (E.G. the 3D preview patch). But in general, I don't think it
  would be fair to process submissions in last-in-first-out order.

All the above doesn't even touch on the issue of why a patch
would not be considered good enough, but I'll leave that for
another time.

As a final note, don't take rejection personally. Whether or not
a patch gets integrated has a lot more to do with the patch
itself and the circumstances than with who submitted it.

-- 
André Majorel <amajorel@xxxxxxxxx>
http://www.teaser.fr/~amajorel/

Other related posts:

  • » Patches, and why they aren't being integrated