On 3/28/06, Bradley Arsenault <[EMAIL PROTECTED]> wrote: > On 3/21/06, Martin Voelkle <[EMAIL PROTECTED]> wrote: > > If you do it without trying, try to avoid doing it. > > Maybe you should ask yourself this question: what does 1.0 mean for you? > > > > IMHO, it's about getting the quality of the game to a point where we > > can say it's stable. > > That implies pretty much bug squashing and reworking the map editor. I > > know these are completely fuzzy goals, but face it: the map editor is > > unusable. It's not about fixing it like this or like that, it's about > > RE-doing its UI. > > Fuzzy goals do nothing. Just saying "fix the map editor and the game > is perfect" does nothing. Once has to describe whats wrong, and the > preferred solution, as a concensus. Thats what i'm trying to do.
My point is just "fix the map editor and the game is releasable", meaning we can concentrate on other stuff with less pressure. > > You seem to have good ideas, but from my POV, they don't seem to bring > > us any closer to a 1.0 release. That shouldn't stop you, there is no > > harm in doing new stuff. Branch, and merge when it's done. But I > > really think that wishlist items should be out of a 1.0 roadmap. > > Branch and merge is annoying and stupid idea. Merging is a slow > process, and especially painfull when someone changed HEAD while you > where branching and ambuiguities arrive. In my opponion, all changes > should go in HEAD. It saves time and effort, and it allows more than > one person to contribute to a new area of code. That's because you assume there is no way to track changes to HEAD while in a branch, which is true with CVS and SVN, but absolutely false with newer SCMs. All changes going to HEAD means no commit while the feature is in a broken state which implies no way to be more than 1 hacking on that feature. > > This is what sucks with CVS: branching is not as easy as it could be. > > You can't keep track of changes in HEAD when you are working on a > > branch. However, merging code is usually not as complicated as people > > think it is. > > I have tried to merge code before, its not pretty. Branching isn't > worth it in any way just to solve some usability issues and add a few > menus here and there. Again, CVS branching is a pain but it's a zero-effort with newer SCM. So it's worth it as soon as you want to implement a feature in more than 1 commit. > > It's unfortunate that open projects must be finished before releasing. > > This is due to the fact that they have been done on the HEAD branch. > > Had we avoided that, we would not be in that position today. I think > > it would be worth to change the source control system (that might > > imply ditching savannah), so people can work on their enhancements > > without holding back the HEAD branch. > > That is opposite of good logic. Merging is annoying and can lead to > ambuigities quickly, as well as duplicated effort, etc.. Ditching > savannah is also a bad idea, if anything, we should ditch savannah CVS > and go for Savannah SVN, as SVN is much, much better than CVS, and > savannah has that. Duplicate effort is worse if you work on HEAD: you build your feature privately, because commiting would break HEAD. With a branch, your separate work is public: people can work on it. And if you can keep track of changes in HEAD, you simply have the best of both worlds: no hard merge and no single commit features. You should really try newer SCMs that popped out since the bitkeeper incident. Try bazaar-ng, darcs, codeville, mercurial, monotone or cogito and you will see that since anesthesia was invented you no longer have reasons to be afraid of punctures. Martin _______________________________________________ glob2-devel mailing list [email protected] http://lists.nongnu.org/mailman/listinfo/glob2-devel
