[mb-devel] Fwd: Open Letter to the MusicBrainz Community

[Stefan Kestenholz]

i'm forwarding Dave's e-mail to the list, since it was sent in private (i
hope you do not mind). I agree with all of his remarks. As i've lined out in
the response to Steve, i might better not have labelled the changes to the
relationships box as "experimental", when in fact they were an attempt
to fix a ticket raised by Steve. When looking back from where we stand now,
it looks like i did oppose him on lots of the issues he brought forward,
alright.

But, I could not accept sentences like "The community wants this",
"Usebility dictates that things have to be done this way", etc. when in fact
these were opinions of one person, on the respective tickets. Such problems,
which are not related to a coding problem are by their very nature debatable
-- on the other hand, i have accepted numerous suggestions as tickets and
fixed all of them, most often under 24 hours. This is how i see it, compare
it to some other tickets in the tracker, and how they just have sat there --
bugfixes are trivial stuff, there's no headache involved whatsoever.

I can accept that it might be a difficult for others to adjust to my
iterative development process, but given the strides that I made, that is a
minor things compared to whatever was achieved. There were a couple of
things where I butted heads, for instance during the WikiDocs migration
process, the Terminology chnages, but to my understanding not on the server
code (Well, i was alone doing it). I do not know what robert meant with
having to clean up after me, i did do the majority of the bugfixes on my
own. I do believe that bugfixes are a normal way of development after such a
big change to the codebase, it thats not acceptable, the developers of
MusicBrainz will have to find a model that works for all of them...

This has again turned into a long winding mail, when in fact i only wanted
to forward daves' e-mail. I hope you can understand some of the points i try
to get across.


---------- Forwarded message ----------
From: Dave Evans <dave at rudolf.org.uk>
Date: Aug 18, 2006 10:16 AM
Subject: Re: Open Letter to the MusicBrainz Community
To: Stefan Kestenholz <keschte at gmail.com>
Cc: Steve Wyles <steve at inhouse.co.uk>, Don Redman <donredman at gmx.de>, Robert
Kaye <rob at eorbit.net>, Nikki <nikki at lmfao.org.uk>, Shepard <
simon.reinhardt at koeln.de>, Lukas Lalinsky <lalinsky at gmail.com>, "Christov
Russell (Wolfsong)" <wolfsong at endlessforest.net>

On Fri, Aug 18, 2006 at 08:52:34AM +0200, Stefan Kestenholz wrote:

> I started taking over development. I pissed off Dave Evans when I really
> started develoment, because there was a similar scenario happening then,
and
> I am sorry I did that. But I did not scare Dave away, he admitted to me
that
> he already was on his way out.

But were I /not/ already on my way out, I think I would have been after
those
disagreements we had.  In other words: just because I was already 99% fed up
with developing mb_server, that doesn't mean that you only pissed me off 1%.
I repeatedly asked you not to commit experimental code to the release branch
as I was trying to stabilise it; *that* is what I simply could not work
with.

> So, whats the big deal? Let get things done, and fix issues that might
arise
> soon after.
> ...
> For me, it is actually spot-on that the test server is a way to present
> proposed solutions for a problem, to figure out if the solution could
work.

This represents a fundamental disagreement which *must* be
resolved.  Different
people view the test server as different things (and indeed in the past, the
test server has indeed been used for different kinds of testing).  The trick
is to make sure that (a) everyone agrees on the development process (I
propose
one such process below); and (b) if a single "test" server is being used for
different purposes at different times, everyone needs to clearly understand
what those purposes are, and not get those different purposes confused.

Steve and I are apparently both of the opinion that the way to make a server
release is something along the lines of:

* Make a bunch of dangerous, experimental, interesting, etc. changes to the
  codebase.  Try them out.  See what's practical, what doesn't even work,
what
  works but is ugly, and what the community will and won't accept.

* At some point, declare that no more new dangerous, experimental,
  interesting, etc. changes will be made; from now on you'll only make bug
  fixes (and probably even then you'll only fix bugs which are new, or
worse,
  since the previous release).  Create a branch for the forthcoming release
  at this point.

* Now you've got a branch, feel free to go back to doing dangerous things on
  the trunk again.  However on the branch you've just created for the
  forthcoming release, from now on you ONLY make bug fix changes, as above.

* Eventually after however many bug fix changes it takes, the release branch
  becomes "good enough" for release to the live server.  The live server
gets
  flipped over to the new release branch.

* Still at this point it's likely that, from time to time, some bug fix will
  need to be made against the release which is now live.  Fine; make the
  change on a test box somewhere, test it, commit that change to the release
  branch, then push that change over to the live server.

At some points in that process it might be appropriate to use "the test
server" for testing the dangerous, experimental stuff; at other points, it
might be more appropriate to use the test server for testing the forthcoming
release branch, while the testing community hunts for bugs, and the
developers
get them fixed.  As long as it's clear at any given time to which use the
test
server is being put, and as long as those changes of use don't happen too
often (e.g. once a week is probably OK; ten times a day isn't), then fine.

But really, please, /don't/ commit new and experimental things to a bug-fix
release branch.

--
Dave Evans

PGP key: http://rudolf.org.uk/pgpkey


-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.3 (GNU/Linux)

iD8DBQFE5XdAnYOJTU6nkkkRAhzXAJ9SFSFpD2zUK7wb6IInIVZCPOhUTQCdE6ZX
PGBs3ZaVxy9Sv8A34E2/K28=
=KQB9
-----END PGP SIGNATURE-----
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.musicbrainz.org/pipermail/musicbrainz-devel/attachments/20060818/581fac40/attachment.htm