source/blog/posts/2009/10/15-d--dmd-and-open-development.rst

   1 Title: D and open development model
   2 Tags: en, d, dmd, compiler, phobos, druntime, development model, software
   3
   4 .. warning::
   5
   6     Long post ahead =)
   7
   8 I'm very glad that yesterday DMD_ had the first releases (`DMD 1.050`__ and
   9 `DMD 2.035`__) with a decent revision history__.  It took some time to `Walter
  10 Bright`_ to understand how the open source development model works, and I think
  11 he still has a lot more to learn, but I have some hope now about the future of
  12 D_.
  13
  14 __ http://www.digitalmars.com/d/1.0/changelog.html#new1_050
  15 __ http://www.digitalmars.com/d/2.0/changelog.html#new2_035
  16 __ http://www.dsource.org/projects/dmd/timeline?from=10%2F14%2F09&daysback=2&changeset=on
  17
  18 Not much time ago, neither Phobos_, DMD_ nor Druntime_ had revision control.
  19 Druntime_ didn't even exist, making D_ 1 split in two because of the Phobos_ vs
  20 Tango_ dichotomy. DMD_ back-end sources were not available either, and `Walter
  21 Bright`_ was the only person writing stuff (sometimes not because people didn't
  22 want to, but because he was too `anal retentive`__ to let them ;). It was
  23 almost impossible to make patches back then (your only chance was hacking GDC_,
  24 which is pretty hard).
  25
  26 __ http://www.urbandictionary.com/define.php?term=anal+retentive
  27
  28 Now I can say that DMD_, Phobos_ and Druntime_ have full source availability
  29 (DMD_ back-end is not `free/libre`__ though), almost all the parts of DMD_ have
  30 the sources published under a source control system. The *core* team has been
  31 expanded and even when `Walter Bright`_ is still in charge, at least
  32 3 developers are now very committed to D_: `Andrei Alexandrescu`_ (in charge
  33 of Phobos_), `Sean Kelly`_ (in charge of Druntime_) and `Don Clugston`_
  34 (squashing DMD_ bugs at full speed, specially in the back-end). Other people
  35 are contributing patches in a regular basis. There were about `72 patches`__
  36 submitted to bugzilla__ before DMD_ was distributed with full source (**72**
  37 patches in **~10 years**) , since then, `206 patches`__ were submitted (that
  38 is, **206** patches in less than **8 months**).
  39
  40 __ http://en.wikipedia.org/wiki/Free_and_open_source_software
  41 __ http://d.puremagic.com/issues/buglist.cgi?keywords=patch&chfieldto=2009-03-03&query_format=advanced&keywords_type=allwords&chfieldfrom=2000-03-03&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED
  42 __ http://d.puremagic.com/issues/
  43 __ http://d.puremagic.com/issues/buglist.cgi?keywords=patch&chfieldto=Now&query_format=advanced&keywords_type=allwords&chfieldfrom=2009-03-03&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bug_status=RESOLVED&bug_status=VERIFIED&bug_status=CLOSED
  44
  45 But even with this great improvement, there is much left to do yet (and I'm
  46 talking **only** about the development model). This is a small list of what
  47 I think it's necessary to keep moving to a more open development model:
  48
  49
  50 Releases
  51 --------
  52
  53 The release process should be improved. Me and other people are suggesting
  54 release candidates. This will allow people to test the new releases to find any
  55 regressions. As things are now, releases are not much different from a nightly
  56 build, except that you don't have one available every night :).  People get
  57 very frustrated when downloading a new version of the compiler and things stop
  58 working, and this holds back front-end updates in other compilers, like LDC_
  59 (which is frozen at `1.045`__ because of the `regressions`__ found in the next
  60 5 versions).
  61
  62 __ http://www.digitalmars.com/d/1.0/changelog.html#new1_045
  63 __ http://d.puremagic.com/issues/buglist.cgi?query_format=advanced&field0-0-0=content&bug_severity=regression&version=1.046&version=1.047&version=1.048&version=1.049&version=1.050&type0-0-0=allwords
  64
  65 I think `Walter Bright`_ is suffering from *premature releasing* too. Releases
  66 comes from nowhere, when nobody expects them. Nobody knows when a new compiler
  67 version will be released.  I think that hurts the language reliability.
  68
  69 I think the releases should be more predictable. A release schedule (even when
  70 not very accurate, like in many other open source projects) gives you some
  71 peace of mind.
  72
  73
  74 Peer review
  75 -----------
  76
  77 Even when commits are fairly small now in DMD_, I think they are far from
  78 ideal. Is very common to see unrelated changes in a commit (the classic example
  79 is the compiler version number being bumped in an bug fix). See `revision
  80 214`__ for example: the compiler version is bumped and there are some changes
  81 to the new JSON output, totally unrelated to `bug 3401`__, which is supposed to
  82 fix; or `revision 213`__, which *announces* the release of DMD_ 1.050 and DMD_
  83 2.035, introducing a bunch of changes that who knows what are supposed to do
  84 (well, they look like the introduction of the new type ``T[new]``, but that's
  85 not even documented in the release changelog :S).  This is bad for several
  86 reasons:
  87
  88 __ http://www.dsource.org/projects/dmd/changeset/214
  89 __ http://d.puremagic.com/issues/show_bug.cgi?id=3401
  90 __ http://www.dsource.org/projects/dmd/changeset/213
  91
  92 * Reviewing a patch with unrelated changes is hard.
  93 * If you want to fold in a individual patch (let's say, LDC_ guys want to fold
  94   a bug fix), you have a lot of junk to take care of.
  95 * If you want to do some sort of bisection__ to find a regression, you still
  96   have to figure out which is the group of related changes that introduced the
  97   regression.
  98
  99 __ http://jbowes.wordpress.com/2007/02/18/git-bisect-a-practical-example-with-yum/
 100
 101 I'm sure there are more...
 102
 103 Commit messages lacks a good description of the problem and the solution. Most
 104 commit messages in DMD_ are "bugzilla N". You have to go to the bugzilla bug to
 105 know what's all about. For example, Don's patches usually comes with very good
 106 and juicy information about the bug causes and why the patch fixes it (see an
 107 example__). **That** is a good commit message. You can learn a lot about the
 108 code by reading well commented patches, which can lead to more contributions in
 109 the future.
 110
 111 __ http://d.puremagic.com/issues/show_bug.cgi?id=1969#c2
 112
 113 Commits in Phobos_ can be even worse. The commits with a message "bugzilla N"
 114 are usually the good ones.  There are `56 commits`__ that have "minor" as the
 115 commit message. Yes, just "minor". That's pretty useless, it's very hard to
 116 review a patch when you don't know what is supposed to do. Commit messages are
 117 the base of peer reviewing, and peer reviewing is the base for high quality
 118 code.
 119
 120 __ http://www.dsource.org/projects/phobos/search?q=minor&changeset=on
 121
 122 So I think that D_ developers should focus a lot more in commit message. I know
 123 it can sound silly at first, but I think I would be a huge gain with too little
 124 effort.
 125
 126 Besides this, commits should be mailed to a newsgroup_ or mailing list to easy
 127 peer review. Now it's a little hard to make comments about a commit, you have
 128 to post the comment in the D_ newsgroup_ or make the comment by personal e-mail
 129 to the author. The former is not that bad but it's not easy to include context
 130 and people reading the comment will probably have to open a browser and search
 131 for the commented commit. This clearly make peer reviewing more difficult when
 132 the ideal would be to encourage it. The private mail is simply wrong because
 133 other people can't see the comments.
 134
 135
 136 Source control and versioning
 137 -----------------------------
 138
 139 This one is tightly related to the previous two topics. Using a good DVCS_ can
 140 make help a lot too. Subversion_ has a lot of problems with branching, which
 141 makes releases harder too (as having a branch for each release is very
 142 painful). Is bad for commit messages too, because there is no real difference
 143 in branches and directories, so know every commit is duplicated (both changes
 144 for DMD_ 1 and 2 are included). It's not easy to cherry-pick single commits
 145 either, and you can't fix you commits if you messed up, which leads to a lot of
 146 commits of the style "Woops! Fix the typo in the previous commit.".
 147
 148 I'm sure both the release process and peer reviewing can be greatly improved by
 149 using a better DVCS_.
 150
 151 Easy branching can also lead to a more fast evolving and reliable language.
 152 Yes, both are possible with branches. Now there are 2 branches: stable (D1) and
 153 experimental (D2). D1 is almost frozen and people is seeing less and less
 154 interest on it as it goes old, and D2 is too unstable for real use. Having some
 155 intermediate can be really helpful. For example, it has been announced that the
 156 concurrency model proposed by `Bartosz Milewski`_ will be not part of D2
 157 because there is not enough time to implement it, since D2 should be release
 158 fairly soon as `Andrei Alexandrescu`_ is writing a book__ that has a deadline
 159 and the language has to be finalized by the time the book is published.
 160
 161 __ http://www.amazon.com/exec/obidos/ASIN/0321635361/modecdesi-20
 162
 163 So concurrency (as AST macros) are delayed to D3. D2 is more than 2 years old,
 164 so one should expect that D3 will be not available in less than 5 years from
 165 now (assuming D2 would take 2.5 years and D3 would take the same). This might
 166 be too much time.
 167
 168 I think the language should adopt a model closer to Python_, where a minor
 169 language version (with backward compatible improvements) is release every
 170 1 ~ 1.5 years. Last mayor version took about 8 years, but considering how many
 171 new features Python_ included in minor versions that's not a big issue. The
 172 last mayor version was mostly a clean up of old stuff/nasty stuff, not huge
 173 changes to the language.
 174
 175
 176 Licensing
 177 ---------
 178
 179 I think the DMD_ back-end should have a better license. Personal use is simply
 180 not enough for a reference implementation of a language that wants to hit
 181 mainstream. If you plan to do business with it, not being able to patch the
 182 compiler if you need to and distribute it is not an option.
 183
 184 This is for the sake of DMD_ only, because other compilers (like LDC_ and GDC_)
 185 are fully free/libre.
 186
 187
 188 Conclusion
 189 ----------
 190
 191 Some of the things I mention are really hard to change, as they modify how
 192 people work and imply learning new tools. But other are fairly easy, and can be
 193 done progressively (like providing release candidates and improving commits and
 194 commit messages).
 195
 196 I hope `Walter Bright`_  & Co. keep walking the openness road =)
 197
 198
 199 .. _DMD: http://www.dsource.org/projects/dmd
 200 .. _Phobos: http://www.dsource.org/projects/phobos
 201 .. _Tango: http://www.dsource.org/projects/tango
 202 .. _Druntime: http://www.dsource.org/projects/druntime
 203 .. _LDC: http://www.dsource.org/projects/ldc
 204 .. _GDC: http://bitbucket.org/goshawk/gdc
 205 .. _Subversion: http://subversion.tigris.org/
 206 .. _DVCS: http://en.wikipedia.org/wiki/Distributed_revision_control
 207 .. _`Walter Bright`: http://www.walterbright.com/
 208 .. _D: http://www.digitalmars.com/d/
 209 .. _`Andrei Alexandrescu`: http://erdani.com/
 210 .. _`Sean Kelly`: http://www.dsource.org/projects/tango/wiki/SeanK
 211 .. _`Don Clugston`: http://prowiki.org/wiki4d/wiki.cgi?DonClugston
 212 .. _`Bartosz Milewski`: http://bartoszmilewski.wordpress.com/
 213 .. _newsgroup: http://www.digitalmars.com/NewsGroup.html
 214 .. _Python: http://www.python.org/
 215
 216 .. vim: set et sw=4 sts=4 :