On Sun, 15 Jul 2012 16:06:58 -0700, Walter Bright
<newshou...@digitalmars.com> wrote:
On 7/15/2012 3:52 PM, Adam Wilson wrote:
So the problem is semantics then? Because I dredge up another word to
describe
what we are asking for if that's all it takes. But I don't think that
anyone
else is going to read "stable" as "unchanging". Software is by
definition
changing, or it's dead. It appears to my parsing of your sentence that
you are
asserting that stable == static. By that definition of stable, Windows
ME is
"stable" and ... ehrm, not a soul in the tech world would agree with
that
summation of WinME.
As I said earlier, no one else in FOSS or Commercial equates stable
with "has no
bugs", it means no new features and no regressions. Not a single
solitary person
I've talked too expects their software to be bug free.
THIS is what we mean when we say "stable":
http://www.modernperlbooks.com/mt/2009/06/what-does-stable-mean.html
It's also how pretty much everyone else will read "stable".
D does have a test suite, and it is a (almost always achieved) goal to
keep it always passing, even on the dev branch. In fact, most of my work
is running the test suite and making sure each change doesn't regress.
(Regressions that do slip through were not in the test suite.)
Frankly, I don't know how to do what you're asking for. D users, every
single day, clamor for:
1. more bug fixes
Branch A. Rebase into Branch B as needed.
2. more new features
Branch B.
3. why aren't deprecated features removed more quickly?
Branch A, marked for deprecation.
Branch B, actually removed. Becomes active when merged into Branch A.
(Assuming Branch B is merged roughly every other month as per current
processes.)
4. why don't we add this breaking feature?
Add it. Branch B.
5. why did you add that breaking feature which broke my code?
Why are you using Branch B you knucklehead?
Often, these are the same people! Sometimes, even in the same post!
This concept is precisely designed to significantly mitigate all five
problems.
Not everyone will test against Repo B, but this allows you to put the
responsibility for not testing against it on them. They know how it works
here, it's not your problem if you broke something that they had the
chance to test for but didn't.
And, to reiterate, we did release D1. Since its release, it has only
received bug fixes. No breaking changes, no regressions. This,
inevitably, has made many D1 users unhappy - they wanted new features
folded in.
So that was not satisfactory, either.
Yes, I do feel a bit put upon by this, as I see no way to satisfy all
these mutually contradictory requests.
I do apologize for that. It is not my intention to cause undue stress. I
am pushing the for the change because I think it will mitigate much of
your current stress in dealing with us. And I do recognize that we users
can be pretty demanding as I sit on the other side of this equation at
work. But because I sit on the other side, I get frustrated when I see
developers actively resisting the proven concepts that will drastically
reduce the very problem they are complaining about.
I should note that we use this exact model for every project we have where
I work and that it is been highly successful at keeping those five points
of tension moderated. And our users can actually get work done without
waiting for weeks and months because thing X is just plain broken, which
in turn makes us look good. (Improving Loyalty)
--
Adam Wilson
IRC: LightBender
Project Coordinator
The Horizon Project
http://www.thehorizonproject.org/
