See convo below and continue here if you like. :)
<Xordan> vknecht: With the length of our release cycle as it is, I'm
thinking it'd be better to not have one stable release, but to have regular
stable and unstable snapshots.
<vknecht> well, wouldn't that take even more testing work to ensure the
snapshots are stable ?
<Xordan> stable will always be stable
<vknecht> I mean, work correctly and have no bugs ?
<Xordan> unstable, it's got to compile and run in general. Will probably
<Xordan> If there's a 'no bugs' requirement you'll never release
<Xordan> If there's a 'no known bugs' requirement you'll never release :)
<jwir3> Actually, I kind of agree with Mike
<Xordan> Most projects release 'stable' releases with bugs known
<Xordan> you just prioritise and release regular updates (x.x.1, x.x.2 etc.)
as things are fixed
<jwir3> I think that our release cycle is much too long, but I also
acknowledge the fact that it is in part because we're all working on other
projects, and many of us only have time to work on CS directly rarely
<jwir3> in other words, it's our own fault. ;)
<Xordan> Release can be mostly automated however
<Xordan> not having regular releases turns people off for sure
<vknecht> why not take the subject to the mailinh list ? but I guess the
answer will be "the problem is the same", not enough workforce in QA &
release departments ?
<jwir3> Well, one thing we could try is to recruit more QA and testers/bug
<jwir3> if we put up some web announcements stating that we are recruiting
beta testers, people might come
<Xordan> maybe yeah
<jwir3> I know a ton of people who say, "Yeah, I'll beta test your game when
it's done." It's the getting it done that's the issue for me
<vknecht> there's need for bugfixing too
<Xordan> vknecht: For example, I've spent a lot of time making PS releases
mostly automated now. I just compile, checkin to a repo and execute a
script, and everything is done automatically (art packaging+optimisation,
update+installer creation, publishing to mirrors).
<Xordan> Takes me 10min to do it
<jwir3> Wow, that's pretty sweet
<jwir3> How long did it take to set that up?
<vknecht> well, for CS it's about the same, there's some script for that
<Xordan> jwir3: Many months over the last two years.
<jwir3> Another thing that is kind of mysterious to me is how bugs get
assigned to a particular developer. Maybe if we had some more concrete bug
assignment process, more would get done
<Xordan> yes, for CS it should be easier too
<PIzik> Not exactly a flawless process though Xordan ;o)
<Xordan> I know there's scripts to do stuff
<Xordan> PIzik: Yet :)
<Xordan> It's nearly there
<jwir3> For example, I'm more likely to fix a bug (or even look at a bug)
that has been assigned to me directly
<jwir3> than I am to just scour the bug database ;)
<jwir3> I hate to say it, but it's true
<Xordan> yeah, I occasionally look through the bug tracker, but not often
<jwir3> we should have some more standard way to assign bugs to individuals
<jwir3> like pass around a sign up sheet
* jwir3 is kidding
<Xordan> vknecht: I guess we just need to provide tarball+zip's of the
source for a release really
<Xordan> though some builds are good too
<Xordan> but for repos people just want a 'labelled' source
<Xordan> hi Dentoid
<jwir3> hi Dentoid
<jwir3> Is there going to be a CS conference next year?
<Xordan> would be nice
<jwir3> I'd be willing to help organize it. :)
<Xordan> Problem is finding a place to host it I guess
* kung is now known as kung|away
<Xordan> vknecht: So I think we should probably branch off 2.0, release a
1.4 (stable) and 2.0 (unstable) and try and release updates every 2-3months
(or longer if stable has nothing done to it). Can swap 1.4 for 2.0 once 2.0
stables up (which it needs tbh).
<Xordan> We'll get more people testing if there's more people using
<jwir3> I think that's a good suggestion, and should be brought up on the