On Thursday, 20 December 2012 at 04:11:00 UTC, Jesse Phillips
wrote:
From the sound of it this request is pulled into master. We
continue to pull many of these changes in. How do we decide
they should be placed into staging, when we pull them into
master?. If we wait for some 'magic time' how do we pull it
into staging, does that mean we now cherry pick commits of
master?
Another issue is it sounds like master becomes a "phantom"
branch. At no point in time would master resemble what is
released. I see this as a problem because it is the branch
people are developing off of, it means nothing to test in
master as staging has the actual state that will be released.
Most of the D users are not D devs, and they don't want to be
testing highly unstable features, however some of them will want
to use reasonably stable new features, even though there may be
some bugs and there may be some changes. The reason for using the
testing branch at all, is that they need something in it that's
not available in the stable branch, so they may take a smallish
risk and try out the testing or staging branch (need to decide on
the terms here).
I placed a note in the wiki about the issue of making sure there
are incentives for people to do the things you wish them to do
for each major step in the process. If there is no incentives for
people to test what comes out of development, few people will
test it, but you need plenty of testers. The carrot is that a
staging tester gets a snapshot of what is most current that is
also reasonably stable, ie., there has to be enough confidence
that the code is stable enough to use for real, else the risk
will be too high to bother with it.
I know this because I'm one of those people. I pick and choose
stable vs
"reasonably" stable based on my needs and the risk assessment.
You need to be quick about supporting the testing branch and
careful about not dumping crap into it, it's a delicate balance
yes, but you *need* testers, and there's only one good way to get
them, you have to dangle a carrot out and hope they take the
bait, and then you have to be prepared to help them out when
things go wrong.
I expect very few people will take a chance on the dev branch
other than the devs themselves and a few of the experienced
people who know their way around the compiler, that's just the
way things will be because it'll be too risky for the regular
folks to bother with.
The user count will always be lowest for the dev branch, more for
staging but you want to encourage highest use possible which
means quick support, and the highest use will be for stable, but
because it's stable means it's not really being tested because it
should be mostly bug free, i.e., it's being "used" as opposed to
being "tested".
I don't think you can afford to drop the testing branch unless
you think there's no need for very many Average Joe testers, but
those are the guys who will uncover a ton of unexpected bugs
missed by the dev testers.
--rt
