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
contain bugs
<Xordan> If there's a 'no bugs' requirement you'll never release
<vknecht> *known
<Xordan> If there's a 'no known bugs' requirement you'll never release :)
<jwir3> lol
<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
reporters
<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
<jwir3> ;)
<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> :)
<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
<Dentoid> Hey
<Xordan> hi Dentoid
<jwir3> hi Dentoid
<jwir3> Is there going to be a CS conference next year?
<Xordan> would be nice
<jwir3> Yes
<jwir3> I'd be willing to help organize it. :)
<jwir3> brb
<Xordan> Problem is finding a place to host it I guess
<jwir3> b
* 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
mailing list.
--
-Mike
------------------------------------------------------------------------------
Come build with us! The BlackBerry(R) Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9 - 12, 2009. Register now!
http://p.sf.net/sfu/devconference
_______________________________________________
Crystal-main mailing list
Crystal-main@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/crystal-main
Unsubscribe:
mailto:crystal-main-requ...@lists.sourceforge.net?subject=unsubscribe
