Next focus: PROCESS

[Rob T]

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