0.2.8.3_beta1: Release process and bugs

[Z-Man]

It was beta? Where? When?

Nevertheless, thanks for the reminder. I'd say we should finally STOP PUTTING NEW FEATURES into 0.2.8, as compelling as each of them may be. Triumvir stomp on that?

Assuming that is settled, there are indeed a couple of outstanding bugs, luckily most in the new features.

[Monkey]

...more than a couple...and even more when I get round to posting...

[dlh]

That's what I get for not reading the entire thread. :) I thought it had a beta release.

Are all the bugs on launchpad, in the 0.2.8.3 milestone?

[epsy]

Nevertheless, thanks for the reminder. I'd say we should finally STOP PUTTING NEW FEATURES into 0.2.8, as compelling as each of them may be. Triumvir stomp on that?

Agreed, but what about the zthread packages?

PS: dlh: yes, that's pretty much it

[Lucifer]

Nevertheless, thanks for the reminder. I'd say we should finally STOP PUTTING NEW FEATURES into 0.2.8, as compelling as each of them may be. Triumvir stomp on that?

So no level editor in 0.2.8.3?

/me ducks

Hey, let the release manager decide that one, heh. (Not that we have actual release managers or anything)

[Z-Man]

Agreed, but what about the zthread packages?

What about them? We link statically. C++ libraries are a pain anyway to link dynamically. I'm far more worried about the pthread code. On many levels.

[Luke-Jr]

Agreed, but what about the zthread packages?

What about them? We link statically. C++ libraries are a pain anyway to link dynamically. I'm far more worried about the pthread code. On many levels.

The pthreads code was meant to replace zThreads since it isn't maintained. That obviously isn't possible on all platforms, and isn't working out well on those it is supported on, so assimilating zThreads was the "solution". So AFAIK, the best way to go about the threading issue right now is to copy the few zThreads files Arma uses into the Arma codebase somewhere.

[Tank Program]

I'd say we should finally STOP PUTTING NEW FEATURES into 0.2.8, as compelling as each of them may be. Triumvir stomp on that?

I'd agree to that. We keep adding little things in, and it's still been at least a year since 0.2.8.2.1. If we're not going anywhere, we can go nowhere in style and go nowhere with 0.3.x and 0.4.x.

[epsy]

So, to sum up, we have 2 non-confirmed high-priority bugs, which may get a greater help from the larger testing audience of a beta, and two low-priority, one being unconfirmed as well, which can be solved later, if at all.

Oh, and that pthread stuff should definitely be always turned off, in case we don't have zthread installed.

That's pretty much it. Once that's done, nothing but a beta(which also means bus factor) should be done, it showed to be enough stable for it, as some "production" servers actively use it, and they didn't get much problems, if at all. I really don't see a reason we should wait more. A beta for xmas?

[Z-Man]

Oh, and that pthread stuff should definitely be always turned off, in case we don't have zthread installed.

Exactly. Go for it. Also, glancing over the code, I see at least three bugs. One per-authentication-process memory leak, pthread mutex resource leaks and non-working recursive mutices.

Plus, I don't see the point of supporting pthreads directly in the first place. It gets us nowhere on Windows (OK, there's an implementation available, but it too doesn't look too maintained.) To combat the problem that ZThread will sooner or later get obsolete, we can always switch over to boots on the trunk; for the near future, which matters for 0.2.8, I don't see problems with that, however.

[Monkey]

Is the bug policy, for betas, to only fix security/stability bugs or to fix some/most/all other bugs too? There are more bugs than you think. I will be posting soon (after Ladle) about at least one.

IMO we definitely shouldn't finalise the 0.2.8 branch altogether due to:
1) Bugs
2) There is at least one feature that, IMO, is important to add (it is only in my head at the moment).

Choices, IMO:
1) Delay the beta
2) Don't delay the beta but make a 0.2.8.4 also

Note that I do agree with a feature halt to all but important features.

[Lucifer]

The bug policy is to fix all bugs of a certain priority or higher/worse. It used to be 5, but I don't know what it is since we went over to launchpad.

The new feature policy is that the stable branch isn't supposed to get any new features. We like to bend that rule from time to time.

[Monkey]

Will there be a beta1, beta2, etc? If so then there is less to worry about...

[Lucifer]

Will there be a beta1, beta2, etc? If so then there is less to worry about...

We've already had those two, haven't we? Aren't we on beta3 now? I've lost track.

Anyway, the release process goes like this:

1. Develop, develop, develop
2. When developers can't find more bugs, or rather can't find more bugs above the fix-it threshold, release a beta
3. Wait, collect bug reports, work on them
4. Release another beta
5. Repeat steps 3-4 for a long time until we can't find any more bugs
6. Release a release candidate
7. Wait, collect bug reports, work on them. The difference between a beta and a RC is that for an RC, the bugs are already fixed, we're testing packaging, upgrade process, and stuff, and we intend to release very soon. A beta can stay out for several months, but an RC needs to be acted upon within a week or two.
8. Repeat steps 6-7 until the RC is "perfect". If more serious bugs surface, throw it back to beta and go back to step 3.
9. Release. The last RC becomes the new release, the only change allowed is the change required to make the version a non-RC version.

Make sense?

[Z-Man]

Make sense?

Yep.

Mokey: Your feature is not important for 0.2.8. Plain simple. We have to stop adding stuff some time, and that time is now. And why the delay in reporting bugs? What's so hard about it? /me stops before really getting angry.