Am Montag, 18. September 2006 02:49 schrieb Christian Ohm: > On Sunday, 17 September 2006 at 12:12, Dennis Schridde wrote: > > Am Samstag, 16. September 2006 23:33 schrieb Christian Ohm: > > > Besides, I find it useful to have my changes > > > version-controlled while working on something (and it's not really > > > convenient to have to use Darcs (or whatever else) besides SVN). > > > > > > Testing the changes in the branch is a nice side-effect if it happens, > > > but not the main purpose, and testing will happen as soon as the branch > > > is merged back into the trunk (that should happen as soon as possible). > > > > But if that breaks a lot (you didn't catch before because of missing > > testing) you have a broken trunk... > > So if we branch we probably have to keep in mind that merging it back can > > break a lot, simply because we didn't catch all the bugs in it. > > Yeah, well, then we could ask people to test the branch before merging > it back (and maybe make a test release from the branch). Notice something? (Hint: Compare your 2 paragraphs.) ;)
But yes, branches are needed and will get tested by someone one day. > > > Yeah, it's not ideal, but then, the autostuff isn't. Let's just replace > > > it, OK? It's just too annoying to work with. Do you need any help with > > > your waf evaluation? > > > > Compilation with waf was never a problem. Only "problem" I currently have > > is with the "autoconf" stuff. Means detection of libraries. > > That one currently has an odd API in waf and I expect it to be changed > > not so far in the future... > > I can create the configure module with the current API (a bit "von hinten > > durch die Brust ins Auge" (if someone can translate that too good > > english, be welcome) but it works). > > So waf is out until the configuration stuff is solved? A pity... Thomas just released 0.9.1 with a completely overhauled configuration. Works like a charm. :) (Now I just need to get variants working (for debug compiles).) > > I think I mixed up 2 different systems I had in mind. > > This is also why my RCs had to be in testing for several weeks: > > > > x.y numbering scheme, no z bugfix releases. > > Have features in every release (like we have currently) and instead of > > releasing bugfix only releases, release RCs before the final release so > > bugs get fixed. > > > > Means: > > - when all features are in: branch 2.1 and tag 2.1_rc1 > > - fix bugs > > - tag 2.1_rc2 > > - fix bugs > > - tag 2.1_rc3 > > - no more bugs: tag 2.1 and release. > > - do some development of new features and then branch 2.2 and tag 2.2_rc1 > > ... > > > > This scheme would match the one found in many commercial games I know of. > > But it doesn't work that well for an open source project with numerous > releases. I thought that it could be a problem. > > > Oh, by the way: Most of the things I propose are based on watching > > > (mostly) this project work (or not), not just pulled out of thin air. > > > ;) > > > > Jup. Do the same with my own proposals. ;) > > And I think most of your proposals are good, but as in daily politics > > there are sometimes many ways to approach a problem and you don't know in > > advance which one is better. :( > > Yeah. As long as we actually decide on one option that's OK. (Not like > on Berlios where some discussions just faded away without leading to > anything...) I think we do better now. :) Everybody has learned...
pgpDUVTVal01u.pgp
Description: PGP signature
_______________________________________________ Warzone-dev mailing list [email protected] https://mail.gna.org/listinfo/warzone-dev
