0.2.8 (beta 3 tagged)

[Z-Man]

Server admins would be dependent on the master server, could not be independent without running their own master server. If the master server is compromised, well, let's just call it a single point of failure.

Yes, but if we want global user registration (and I think we want to support it for the lazy users who would otherwise choose the same password on every server anyway), there's always going to be such a single point of failure. Somewhere the global data has to be kept.
Unless, of course, we use a decentral structure: have many authentication servers around (for example, a clan would run its own authentication server), and the globally unique ID of a player would be his authentication server ID plus his username. Then we'd have the problem of how to identify and authenticate the authentication servers... Too many levels of indirection for me to grasp right now.

Being a fanatic of independence, I don't like it. Not unless participation on the server admin's part is voluntary. Probably also disabled by default...

Sure thing, no central authority should be enforced (Anarchy!). The same code that authenticates the user with the master server can also be used to authenticate the user with each individual server and its local user database. Ok, it would probably be better do do this in reverse: first, the local server specific authentication, then the global one if we feel like it.

Nothing on memory usage right now. Is that something you could grab from the memory manager in aa?

If it's active, yes (I think I disabled it by default because I mainly see it as a debugging tool) . It will miss some bits because not everything can be managed by it (like some C fanatics using malloc and free) and memory allocated by libratries.

[Luke-Jr]

Replying to z-man's stuff in the Authentication Thread

[Luke-Jr]

I propose we:
1. Create a new release prior to aardvark (0.2.8.0; codename longnose?)
1a. Move completed features to this release
1b. Fix issues players will refuse to upgrade for (camera behind wall, for example)
1c. Create a longnose branch and release
2. Keep the rest of the features (including new website) planned for aardvark (0.3.0.0)
2a. Make aardvark a "must have" release
3. Continually backport the bugfixes for aardvark to longnose
3a. When significant bugs are fixed, release 0.2.8.1, 0.2.8.2, etc

Comments?

[Z-Man]

It's not missing features that keeps us from releasing, it's the bugs. My features (those in the tracker) are finished in a branch, I'm just ironing out some consistency bugs before I merge. And the rest that's holding off aardvark are the bugs on the list.

The recording capacity is precisely what I need to fix the top priority bugs on my list, no chance delaying that.

[Lucifer]

We can wait for authentication another release if we need to, the only problem with that is the same ol' network protocol argument. If we do it for this release, we need to test it and see if it lives up to its promises about its place in the network protocol. But it is a high priority feature, as far as I'm concerned.

Did nemo merge in his custom connect menu yet? I still haven't seen it....

Other than the authentication thing, there isn't really anything on the list that can wait. The resource server (which is being worked on right now) can be late for the release, can't it? I mean, it wouldn't be good, but it wouldn't kill us either.

Also, I haven't played seriously with a recent cvs snapshot, but the one I'm playing with has big time problems with the camera. It zooms way out, and only gets smart again when I press "s" to chat. Tonight on MBC the smartcam zoomed way out and then just started turning slowly, clockwise. And it was zoomed so far out the cycles and walls were each only 1 pixel wide or so. Anyway, I need to build a newer cvs snapshot and test some more, but with last week happening like it did I've fallen a little behind in other work, so I have to play catchup this week.

Edit: With the invisiwall bug fixed, as far as I'm concerned some of the other bugs can wait, so long as the recording capacity is there. Then we don't piss off players by having the bugs there, we tell them we couldn't fix them without a public release with recording, so that's what we did. Then invite them to duplicate the bugs and send in their recordings.

[dlh]

Did nemo merge in his custom connect menu yet? I still haven't seen it....

*still needs key to add from master list (will not finish tonight, its 4 am and I am going to bed).
*If you edit a favorite, you have to move back out to the net_menu and enter back into the favorites menu to see the change. Don't know how to fix this.
*localized strings + the \1 parameters (don't know what to call them). So instead of seeing in your favorites menu Breakfast in Hell, you will see Connect to Breakfast in Hell, and Edit Breakfast in Hell.

[Luke-Jr]

It's not missing features that keeps us from releasing, it's the bugs.

It's both, but there's only a few bugs that are really annoying... none are really too-annoying. Don't forget, we can always do a 0.2.8.1 and so on later.

My features (those in the tracker) are finished in a branch, I'm just ironing out some consistency bugs before I merge. And the rest that's holding off aardvark are the bugs on the list.

You forget the new website that goes with aardvark, which includes the resource repository and authentication.

We can wait for authentication another release if we need to,

Effectively, that's what it would be doing-- moving aardvark to that 'other' release and inserting one in the middle.

Did nemo merge in his custom connect menu yet? I still haven't seen it....

Just now, I think.

Other than the authentication thing, there isn't really anything on the list that can wait. The resource server (which is being worked on right now) can be late for the release, can't it? I mean, it wouldn't be good, but it wouldn't kill us either.

The resource repository, like authentication, is part of the new website and wouldn't work earlier than it is ready.

Also, I haven't played seriously with a recent cvs snapshot, but the one I'm playing with has big time problems with the camera. It zooms way out, and only gets smart again when I press "s" to chat. Tonight on MBC the smartcam zoomed way out and then just started turning slowly, clockwise. And it was zoomed so far out the cycles and walls were each only 1 pixel wide or so.

Key sticking... not sure what causes that, but it's easy to fix.

Edit: With the invisiwall bug fixed, as far as I'm concerned some of the other bugs can wait, so long as the recording capacity is there. Then we don't piss off players by having the bugs there, we tell them we couldn't fix them without a public release with recording, so that's what we did. Then invite them to duplicate the bugs and send in their recordings.

Good excuse^W idea!

[Lucifer]

Ok, so what it looks like we need to do is push off the resource server and authentication to bardvark, z-man needs to finish the recording capacity, and then z-man should tell us if that enables him to fix his top priority bugs right away or if it would be better to push it off to a maintenance release where the bugs will be fixed by getting recordings from players experiencing the bugs.

Then, when z-man is ready with recording, we can branch and release the first beta, right? I mean, we don't need z-man's top priority bugs fixed to release a formal beta, because we do have all this other code that needs some testing too....

[dlh]

It's both, but there's only a few bugs that are really annoying... none are really too-annoying. Don't forget, we can always do a 0.2.8.1 and so on later.

I disagree, the bugs are very annoying. You don't find going through walls and holes appearing in walls annoying?

[Lucifer]

It's both, but there's only a few bugs that are really annoying... none are really too-annoying. Don't forget, we can always do a 0.2.8.1 and so on later.

I disagree, the bugs are very annoying. You don't find going through walls and holes appearing in walls annoying?

New Lucifer Todo: setup a cvs snapshot server somewhere (ask Swampy if I can use Swampland in 2.7.1 for it) to test these bugs

[Luke-Jr]

Then, when z-man is ready with recording, we can branch and release the first beta, right? I mean, we don't need z-man's top priority bugs fixed to release a formal beta, because we do have all this other code that needs some testing too....

Should 'formal' betas be listed with dates along with the CVS snapshots or should we set the date field to "0280 beta 1" or a mix of both? Perhaps "0280 beta 1<br />YYYY-MM-DD"?

It's both, but there's only a few bugs that are really annoying... none are really too-annoying. Don't forget, we can always do a 0.2.8.1 and so on later.

I disagree, the bugs are very annoying. You don't find going through walls and holes appearing in walls annoying?

I don't find bugs overly annoying if they're not very common regardless of what they are. And we're certainly not making much use of bugfix releases right now, we might as well use them for actual bugfixing.

[Lucifer]

Then, when z-man is ready with recording, we can branch and release the first beta, right? I mean, we don't need z-man's top priority bugs fixed to release a formal beta, because we do have all this other code that needs some testing too....

Should 'formal' betas be listed with dates along with the CVS snapshots or should we set the date field to "0280 beta 1" or a mix of both? Perhaps "0280 beta 1<br />YYYY-MM-DD"?

I think the schema should be this:

CVS snapshot: just like it is, it's fine

beta: armagetronad-0.2.8.0.beta1 (or beta-1).whatevertheappropriateextension

Release candidate: armagetronad-0.2.8.0.rc1.whatevertheappropriateextension

Final version: armagetronad-0.2.8.0.whatevertheextension

That will allow at least rpm to properly upgrade each stage. I know for Windows we don't have to worry so much about it, I assume emerge and apt-get will all behave well with that scheme, but don't know it for a fact.

I don't find bugs overly annoying if they're not very common regardless of what they are. And we're certainly not making much use of bugfix releases right now, we might as well use them for actual bugfixing.

I'm with Luke to some extent here. I don't think these particularly annoying bugs should stop a beta. Quite the contrary, I think they're the reason we need a beta. We need to put out a beta so people who want to test bugs will do it. A beta is more formal than a cvs snapshot and I think releasing a beta will get more testers than just a snapshot. When the recording code is ready for beta, that is when I think we should release it. We'll use the results from the recording to gather information on the bugs and hopefully fix them for a second beta.

We also have other code besides those bugs, new code, that needs to be tested at large. I'd like to see how well the headlights work out for real, so far Jonathan's the only one who has pretty headlights. Nemo's just written a fair amount of code that needs to be tested on clients and servers. I've no idea how wide the testing on shaped arenas has been. Having formal betas that provide a proper upgrade path will make it easier for server admins to run beta servers.

So, in short, I think z-man's the one who should decide if we beta now, because it's dependent on code he's working on right now. And pretty much the extent of the decision that needs to be made is "Does the new recording code allow him to fix these bugs immediately, or does he need to deploy the code and collect information over time on the bugs?" If he needs to deploy the code, we need a beta to support fixing the bugs. All other features originally planned are implemented, there are three that might be bumped. Rather, two that are being bumped and one that might get bumped (that one is the screen resolution thing that I'm doing, hopefully I'll squeeze it in during beta testing).

I figure we'll be in beta state for about a month, maybe two. I'm not actually a big fan of doing release candidates and I'd just as soon go straight from last beta to official release.

Remember, we did essentially agree that these bugs should be fixed for release, but never specified if that meant "beta" or "public", and I think it means "public". I don't mean to get technical on you guys, but I really think we need some beta testing involved in the bughunt.

[dlh]

not very common

But the problem is the going through walls bug is very common. When microbus was running cvs (one month ago approximately?), it happened alot. I've only seen people go through walls twice on a 2.7.1 server, but at microbus it was happening every other round. I even saw a few holes in walls (<-- need new term). I think the increased frequency of these bugs should hold back an offical release until they are fixed.

A release with the recording code would be useful, but it seems users already have a hard time differentiating between official/beta/totally unoffical cvs builds. I think if we do release a offical beta, we should only do it here on the forums and not on sourceforge. That way we only get seasoned tron'ers testing it out, and not someone who just downloaded the game and it is their first time playing.

[Lucifer]

I think if we do release a offical beta, we should only do it here on the forums and not on sourceforge. That way we only get seasoned tron'ers testing it out, and not someone who just downloaded the game and it is their first time playing.

I don't have any problem with that.

[Z-Man]

Full ack on the beta bug thing. Betas are supposed to be buggy as hell, otherwise users won't notice we're actually fixing bugs