[erlang-questions] Erlang 10 years of Open Source; it is time for the next step

[Christian S]

On Fri, Mar 21, 2008 at 3:03 PM, Matthias Lang <matthias@REDACTED> wrote:
>  Take a look at a patch that someone actually submitted, for example:
>
>   http://www.erlang.org/pipermail/erlang-questions/2008-January/032345.html
>
>  it's a pretty typical user-contributed patch, i.e. it's a small
>  change, only about five lines of code, it fixes a definite problem,
>  and, most importantly, it's mostly crap. The guy who submitted the
>  patch

What I see here is that an automated test-case that exposes this
problem should be written.

And that's the kind of feedback you could have received.

Something that leaves the test failures as a thorn until the cause is
fixed (or the test removed :). If OTP has survived with this hole so
far, it can probably survive many more months.


Now as for your needs:
If your code depend on the behavior that your patch introduces, then
you probably want to make sure it is included each time you compile
OTP?

Wouldn't you want to forward port it as new OTP makes new releases you
intend to use? Back port it to that old system still running R9?

Wouldn't you want to publish this patch so others with the same issue
can look at your attempt, or perhaps inviting HiPE to implement
something equivalent?


Basically I'm arguing for the use of a DSCM.  I don't get the feeling
that you argue against that. Are we actually disagreeing about
something? :)


Perhaps the most important issue I see here isn't if GIT or Mercurial
is chosen over Subversion, as both can already import from subversion.

The issue is if the public repository will have a commit log like:

  OTP ClearCase changes for 2008-03-20 11:00
  OTP ClearCase changes for 2008-03-20 14:00
  OTP ClearCase changes for 2008-03-14 16:00
  OTP ClearCase changes for 2008-03-13 09:00
  OTP ClearCase changes for 2008-03-11 14:00
  OTP ClearCase changes for 2008-03-11 11:00


Or if it will be a more lively one-commit-is-one-fixed-feature and
multiple living branches for pre-release fixes. Something more like

   http://lwn.net/Articles/140350/

Or a less busy log:

   http://www.flickr.com/photos/malcolmtredinnick/1516857444/