[openbeos] Re: some points

Michael Phipps <mphipps1@xxxxxxxxxxxxxxxx> wrote:
> > > The "development" section is actually independent from the 
> > > general status. 
> > > "alpha" generally means something like "somewhat working", "beta" 
> > > usually 
> > > stands for "functionally complete". So 90%-100% developed would 
> > > generally 
> > > mean anything between beta and mature. Beta could start earlier, 
> > > the effort 
> > > for alpha status is different from team to team. The development 
> > > bar tries 
> > > to reflect how much work has been done already to achieve 
> > > maturity of the 
> > > component; when it's 100% complete and the status is "mature" 
> > > (note, also 
> > > missing tests can keep a component in beta status), you can say 
> > > it reached 
> > > R1 stage - ready for release.
> > Well, gee wiz. That is even more confusing.
> Yes.

That's the beauty of expressing an understandable state of the project 
:)
Seems we're not doing the greatest job there ;-)

> > So the midi kit is almost done with development but hasn't reached 
> > a point 
> > yet where they can can claim it's alpha? Is that because it really 
> > can't be 
> > tested or used until it's just about code complete? Or is it just 
> > that the 
> > team lead hasn't updated status? From the MIDI status page, it 
> > looks like the 
> > former.
> There are no real standards for alpha or beta, except that beta is 
> generally 
> better than alpha. 

I have to disagree a little; first of, yes, there is no written 
standard (that I know of). How Alpha/Beta should be understood is an 
unwritten agreement between developers that can likely be different 
from project to project or even from team to team.
Therefore we should have a clear understanding of what alpha/beta means 
to us - and when we eventually found out, we should propagate our 
wisdom. With a written explanation on the status page.

Also, as a further improvement, we could define milestones for every 
team and make those public as well. That's a well understood and clear 
method to show progress and make changes and needed effort 
understandable.

> Let's talk in a couple of extremes:
> 1) For Kit Foo, Team Leader Bar likes the "release often" mindset. He 
> releases 
> a new alpha once a week. Maybe there is little functionality, but he 
> releases 
> anyway.
> 
> 2) For Kit Bar, Team Leader Omega hates bug reports. So he waits 
> until his 
> stuff is completely code complete, all tests pass, and the OpenBSD 
> team has 
> expressed amazement at how secure the code is. Then he makes an 
> alpha.
> 
> Reality, for Haiku, falls somewhere inbetween. 
> There are frequent builds of the kernel kit. It is not code complete, 
> by any 
> means. On the other hand, there have never been any alpha of the 
> interface kit, 
> and it is at least as far along as the kernel kit, I would say. 

We should try and find a general mechanism for all teams. For some 
teams, it's easier to make representable snapshots, for others, it's 
nearly impossible.
For the interface kit, we should probably make a sample application 
that makes use of all of our widgets.

> > If it is, it really seems like alpha/beta/mature section deperately 
> > needs to 
> > be in a different table.
> There needs to be some space between them, I will agree. 

Yes, that's just a thing from the past that hasn't been fixed yet.

> > Of course, maybe I'm just still lost about the whole thing and 
> > shouldn't 
> > really be worrying about it at this point.
> Eh. In a lot of ways, you can ignore the alpha and beta columns. If 
> you "just" 
> look at status, when they are all correct, you will get a good idea 
> of where 
> the kit really is.

I disagree here :)
You can always only believe you might have a good idea about the status 
- a simple progress bar from 0% to 100% is surely not enough to gain 
real understanding.
The alpha/beta status is an improvement, as would be any other of the 
here mentioned suggestions as well IMO.

Bye,
   Axel.

Other related posts: