patches

[Kent Boortz]

Klacke <klacke@REDACTED> writes:
> This mail is actually more to the OTP group than to the erlang-questions
> list. I'm bit disturbed by the way patches are sent in to this group
> and subsequently picked up by the otp group.
> 
> It would be nice to get some feedback somehow which patches
> are picked up by the otp team, which are dropped and which are
> modified and later accepted.

  0. I agree that silently just merging some and dropping others
     without notifying the author is not the way to handle
     contributions. When I had the main responsibility for the
     integration I know I wrote several authors about their patches
     but we could do better. We will discuss how we could improve the
     response on patches.

Some background

  1. We don't merge patches the same day they are sent to this
     list because we are busy doing other things. We go over this
     list before each OpenSource release to catch up on the patches.

  2. Build patches are always merged into the release, i.e. make file
     and configure patches for improved portability.

  3. Smaller patches that we can determine with visual inspection that
     it will not break anything else are always merged into the new
     OpenSource release.

  4. Experimental new features are mostly accepted if they are
     separated from the existing code and enabled with a configure
     flag.

  5. Larger patches or patches to critical parts of the system may
     take longer or never get into the source. We can't merge lots of
     new code into existing code without spending time understanding
     and verifying the new code. This take time.

  6. We have to focus on quality and this sometimes get in the way of
     adding new features. It has also happened that we accidently lost
     patches, sorry about that.

  7. It has been discussed before, we could of course branch of the
     OpenSource version from the commercial version and have less
     quality demands on the OpenSource version (the correction patches
     of course improves the quality as soon as we have had time to
     merge and verify them). This is not the direction we want to go,
     instead we want the commercial and the OpenSource version to be
     as close as possible. Mainly to reduce the amount of work needed
     for us to maintain the OpenSource version but also because we
     think the kind of OpenSource community we have prefer quality
     before features.

I assure you that the lack of immediate response is no indication that
we don't care. We are very thankful for the patches send to us and try
to get them into a the new OpenSource release as soon as possible,

kent