Andi Vajda wrote: > - No more nine month-long release cycles > Over the last few weeks, we've been capable of releasing a decent RC > build > every other day or so. Why stop now ? We have about a 100 bugs > targetted > for our next release 0.7.1.
Releasing weekly (or something like that) can work for webapps, but generally won't work for desktop applications. It is a pretty big hurdle to download and install an application, and it is unreasonable to expect users to do that on a weekly, or even monthly basis for long stretches at a time. Automatic, incremental update is something that you could put in a desktop app to make it almost work. Still, even Firefox has problems here (try running Firefox as non-administrator and the automatic update attempt messes things up). > Our 0.7.1 release is currently planned in about a month. > Yeah, right. I am not so pessimistic. We probably have more bugs targeted for 0.7.1 than we can fix in a month, but if we really want to have a month long cycle for 0.7.1 I think we can do that by simply deciding not to fix all of those targeted. Just fix the most important ones we can in the next 3 weeks, then spend a week ironing out the kinks. Move the rest to 0.8 or 0.7.2. > The last thing we need, though - right now - is another big bang, > another let's start from scratch with a new approach project. Instead, I > think that we should improve, refactor, excise, rebuild, replace, small > and large parts of the software that need it one piece at time. And we > should do so keeping in mind users and developers, inside and outside. > Our users are normally oblivious to the esthetics of our architecture. > And now, they come first. I agree we shouldn't do a huge start-from-scratch rearchitecture. I think we could get big improvements by having a small task force rewrite/rearchitect pieces (like UI) of the app while the rest of the team fixes regular bugs and builds new features. In some ways it is more painful to do it this way, but I think starting more or less from scratch for the whole thing would be a mistake. > There seems to be consensus that our testability sucks. As has been said > before, decoupling the UI model from the application model would give us > a better handle on testability as well. Although I am a proponent of better tests etc., I don't think testability per se is a deciding factor in an applications success. I can point to a certain family of successful web browsers that practically relied on the if-it-compiles-and-starts-it-is-good-to-go testing methodology. -- Heikki Toivonen
signature.asc
Description: OpenPGP digital signature
_ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ _ Open Source Applications Foundation "chandler-dev" mailing list http://lists.osafoundation.org/mailman/listinfo/chandler-dev
