In my experience, a small "alpha" team doesn't do nearly as much as a larger "wide beta" approach.

I think you're missing the point: They do both. In that order.

What if we discount such remarks from people on the alpha team?

Yeah. And in my experience, releasing it earlier to the larger group earlier on makes the *beta* releases *final* quality in a shorter period of time. Granted it takes a little more effort to manage the bugs coming in and such, but I think it's worth it.

Hell, why not just have automated nightly builds?

Cool.. yn0t_ just volunteered to manage all of the bugs from everyone.

Several comments -- Managing bug reports/release management is a really big timesink... I can say this both from my professional work as well as my jEmplode work, which is far less complex than the entire Empeg project. The Alpha team is setup to catch the obvious things quickly and it saves everyone a lot of time. Imagine if everyone was reporting the same bug (which happens ... a lot)? What a pain -- especially when they're doing this out of the goodness of their hearts. Optimizing that process is essential to all of us continuing to get releases.

Also, like Rob said, the Alpha team is under NDA, so we can see stuff you can't So in some cases it's not feasible from a marketing standpoint to deploy to a wide beta without revealing competitive info.

Also, there was something at the bottom of the NDA about souls and first borns. I didn't really understand it -- I think it was written in "proper" English, or something. But apparently the Empeg team feeds off of the lifeblood of the Alpha team and would actually wither and die without us. Anyway, I just signed it (in blood).

ms

Oops .. I think there was something about not talking about fight club on there too.

The Empeg alpha team is paid in free orgasms when emails come out with headers like

From: rvoisey@sonicblue.com
Subject: [empeg-caralpha] [ANNOUNCE] v<insert number greater than existing release> released

Managing bug reports/release management is a really big timesink

I got a sucker^H^H^H^H^H^Hvolunteer to help with this for OpenAFS; I was doing it all myself until like 6 months ago, and as we gained momentum it got to be a huge pain.

I'm not sure it's smart for me to keep doing it instead of developing, but I don't think we have a choice just now.

Also, like Rob said, the Alpha team is under NDA, so we can see stuff you can't

Hmmm, see, all the testers keep giving themselves away, takes a lot of the challenge out of figuring who to bump off!

The Empeg alpha team is paid in free orgasms

Damn, I missed that part in the NDA. Where do I download those again?

Yeah. And in my experience, releasing it earlier to the larger group earlier on makes the *beta* releases *final* quality in a shorter period of time. Granted it takes a little more effort to manage the bugs coming in and such, but I think it's worth it.

We're not talking about Beta releases. They're not of known Beta quality until the Alpha team have tested them, irrespective of the filename.

So let's put it another way. I don't have time to manage a mass ALPHA programme and the consequences that will arise from it. So, we can continue to use my system or we can discontinue new releases entirely.

OK class?

Imagine if everyone was reporting the same bug (which happens ... a lot)?

The S Series Beta Programme with about 40 participants reported 334 bugs, of which 30 were found to be valid and unique. The Programme Coordinator filtered out all the junk, and the development team got to see just the valid reports - which were all subsequently fixed.

SB Beta Programme Coordinators work full time to manage two to three simultaneous programmes, with probably no more than a couple of hundred participants in total. This is with Beta quality software which has already been through a QA alpha regression.

Rob

So let's put it another way. I don't have time to manage a mass ALPHA programme and the consequences that will arise from it. So, we can continue to use my system or we can discontinue new releases entirely.

OK class?

Why do I get the urge to say "Yeah! put that in your pipe and smoke it you ingrates"...

So let's put it another way. I don't have time to manage a mass ALPHA programme and the consequences that will arise from it. So, we can continue to use my system or we can discontinue new releases entirely.

Hey, relax, I'm just trying to share my experience and see if there's a better way to do things. If the finite resource in question is your time managing things, then I guess there's no better way to do it in this case.

Sorry I asked.

Why do I get the urge to say "Yeah! put that in your pipe and smoke it you ingrates"...

Funny, I don't consider myself an ingrate for trying to share a new perspective on things. On the contrary, I think it's good to occasionally challenge existing methods and see if there's a better way. Clearly in this case it looks like there isn't a better way (short of sharing the source with us and letting us do our own releases!) so I stand corrected.

Oh yeah, and ingrates don't spend a significant amount of their free time reporting bugs, helping new users, and developing 3rd party software. Actually, an ingrate wouldn't have cared enough to bother thinking about such a thing in the first place.

Funny, I don't consider myself an ingrate

Of course not...most of us share the same eagerness. I should have made it clear that that was tongue-in-cheek. My apologies, sir!

I think this is one of those "someone has to die before someone new can join" things. That's why we don't publish a list of team members

Well, two of your members just blabbed who they were, so... anyone want to get a spot on the alpha team?

I suppose this means I should be watching my back from here on out

So, can any of you alpha guys tell us... is OGG there?

Uh...they're under NDA's. They couldn't tell us if they wanted to.

Read this post. No idea if it's in the release given to the alpha team though.

- Trevor

... yeah -- what he said ...

I just sent a private message, then noticed he hasn't posted again.

Sad that there's no way to tell when someone last read.

I miss "finger".

Peter,
Thanks for all your help, I now understand the dynamic database and how it's used. I have a few more questions... )

I'm planning on adding a few new "tags" and I'm wondering the best way to do this. I've added two new tags in a tune fid: "starttime" and "endtime". They are used to set where to begin and end playback of a tune on a time scale. An example: The song "St. Robinson and his Cadillac dream" by the Counting Crow's is 15 minutes long, and is composed of two songs separated by 8 minutes of silence. By setting the endtime, I can stop the playback at the end of the first segment. I have the feature working on my empeg server using libMAD for mp3 playback, but I am wondering how I allow the user to make changes to this tag on my 3rd party player?

Given that the /drive0 partition is mounted read only, like the empeg. I don't want to remount it RW just to make changes to the fid | 0x1 file. I could allocate another scratch partition, and write out the changes to the fid | 0x1 file, (like the dynamic database), and then update the real fid | 0x1 file when I rebuild the database. But how would you do it?

-Scott

PS I'v attach a picture of my 3rd party touch screen player. Eventually, I will release it on sourceforge.net...

So, does this mean someone owes me $5?

i thought it was for ogg implementation? there isnt any evidence that the player supports it.

Hmm. You're right. I bet I could have an ogg-using version (instead of a MAD-using version) in a small number of hours, but I doubt it's worth $5 to do so.