From: Jean-Philippe <jpm...@fr...> - 2012-05-12 09:07:28
|
Hi, everyone. Sorry, long, but very important ; please read to the end :-) >> What about creating a wiki page about collecting every ones 2.1 ideas and >> wishes in the >> categories: >> Cars >> Tracks >> Menu >> New Features >> Driver& Physics >> Sound >> Important Bugfixes >> >> Everybody writes his ideas in? Like we started one for Version 3: >> http://sourceforge.net/apps/trac/speed-dreams/wiki/IdeasForRelease3 >> >> Or collected here: >> http://sourceforge.net/apps/trac/speed-dreams/wiki/Feature > I mostly agree. In fact the time span is not the most important question. > I'll start a wiki page now. However some titles like 'bugfixes' and > 'new features' is not a main category, but that's only a technical > problem. > > I suggest to merge the IdeasForRelease3 and the Feature and the > GSOC2011 pages, so we can have one page with all the 'wishlist' to > overview. Then we can pick some of these and move them to the '2.1 > planned feature list' that lists the plans (and only those) that when > complete, 2.1 can be called 'feature freeze'. I agree, let's make things "concentrated" and easy to read, into 1 single wiki page. Then, sorry to insist : yes, ideas/wishes are useful, but only if someone is willing to implement them (see the Network subject, as an ex.) ... What about a "parallel" wiki page listing what each dev/artist would like to work on in a 1 or 2 year future ? This would greatly help getting a concrete and feasible 2.1 / 3.0 feature list, IMO. (of course, the wish list can also help devs/artists to pick up subject they'd no have thought before :-) > Why would we go through all the testing/release headaches for a 2.1 > release when 2.0 seems to be OK? Lets give ourselves some time and go for > 3.0 to be released at the start of 2013. I'm with Simon / Eckhard on this, 1 release every 9 or 12 months seems a good rate for me ... but I agree with you Kilo, provided we stick to it. >> The team has to agree to a plan and stick to it.... > Indeed. Let's be strict - to our own principles. For this we definitely have to find tricks to force us to stick to the schedule. >> PS1: On the dev. process subject, I started to write a page on the meaning >> of dev / alpha / beta / release candidate ... stuff (see Devs corner / >> Release method). > Yep, saw that and I think it is a must to put all these 'rules' in a > wiki page. However, I'd like to see everyone promise (or something > even stronger) that we will be working according to the rules. I am > ready to do that - is everyone ready to follow? Remember, a community > works only if every member accepted some rules. I agree 100% : while writing this "Release Method" page (and also 1 about communication and 1 other about roles / technical responsibilities inside the team ... let me some time / help me), I was precisely thinking about a kind of "contract" or "formal promise" that EVERY member of the dev team will have to formally agree on (and so, carefully read and discuss before, of course) before going on. I want we all agree on clear and simple rules ; then, things will be simpler : when some of us passed the limits, many of us see it, tell it, and recall the contract : done. No more complicated discussions about unclear rules that were never written. Of course, these rules have to remain compatible with our "fun" scheme :-) But they are needed if we want to deliver HQ releases as we stated (do we all agree on this HQ release target ?) > From Eckhard (April, 8th : "Re: Our future release process") > From my point of view it looks like: > - There are always thing that didn't get into the next final step > - We did a great step targeting end users why stop now > - We are break to much dead lines and our process is to loose > - We are not enough people to do a stable rolling release > or a release every 6 months > > So here is my idea to discuss: > > CYLCLE > - A new, final release every 9 month > - Directly after the new final release we made inside 14 days a plan > about the next update and the next final release > - 2 month after the new, final release we release an update that ships > with bug fixes only, small improvements and things that didn't get it into > the last, final release > - 4 weeks to the next, final release an absolute commit stop starts, only bug > fixes are allowed - > no new feature, no new artwork etc. > - 2 weeks to the next, final release we start to think and prepare > with anything that is required for the release too: screenies, announcment, > posts, press packages etc. > - Updates will get only a short list about changes and will only be announced > over our website, our social channels and our community board (with these > tools it will find its way into the world too) > - For every release we create a wiki page that includes exact dates > and timeline > - so nobody must be frustrated when his fix didn't get it into > - because he knows the deadline and he knows there will be an upadte release > later > - If something should find it's way into the next, final release during the 4 > weeks of bugfixing time 50% of the developers must agree with it and two team > members (the developer of the feature excluded) must be agreed to test this > new feature after commit during 1 week I agree here about 1 big idea : the fixed schedule scheme. I'd translate it like this for 2.1 / 3.0 with my own words and ideas : besides a clear feature list, each future release MUST feature a fixed schedule stating the release date, and thus, the dates when we enter 1) the beta stage 2) the alpha stage. As you said, Eckhard : when something is not ready when the dead line comes, then it simply have to be HIDDEN (or removed) from the visible stuff of the release. And as this is a clear rule stated from the beginning, accepted by all of us, no discussion on that, no frustration about not releasing it this time. Of course, this means we define tricks for every kind of technical change (code, art work, ...) in order to be able to HIDE the unfinished stuff when the dead line comes : not always simple (we have : #ifdef, interfaces/modules, svn branching, reverting, source file separation, in-code versionning, even code duplication ... for the code, and some of these tricks for the artwork ...) Each planned task for a release WILL have a fall-back plan of this type in order we can SIMPLY and EASILY hide/remove/revert the unfinished part of the work (may be all of it) in case it is not ready on time. What do you think ? Cheers, Jean-Philippe. |