Hi, everyone. I apologize in advance for quoting Ian at length here. His posting complex enough that I have to quote lots of pieces to provide context.
Ian Clatworthy writes: To get the ball rolling, I'd like to hear everyone's thoughts on how > Bazaar 2.0 ought to be packaged on OS X. . . . > > Here are some "degrees of freedom" to consider: > > * OS version: Panther vs Tiger vs Leopard vs SnowLeopard? I believe that Apple's recent practice has been to cease producing security updates for a given operating system at the release of the second one to follow - so security updates for Panther came to an end with the release of Leopard. If that remains true, the end of security updates for Tiger will come with the release of Snow Leopard in September. If support for Panther or Tiger requires extra work, it might make sense to target only Leopard and Snow Leopard at this point. * multiple languages You're discussing a localized installer, here, correct? Build the installer with an internationalization framework and let the localizations flow in from the grateful public. :-) > * bundled documentation format: HTML vs PDF vs Help Viewer There are multiple tools for generating HTML and PDF. I do not know whether any of them target Apple's Help Viewer. > * bundled python vs not? If not, assume which platform version? My knee-jerk reaction is to consider Python the run-time for Bzr, and bundle the run-time. Python 2.6.2 is current as I write this, and the python.orginstaller mis freely distributable and is available for Tiger and Leopard. Does it work on Snow Leopard? Also, what do we bundle vs install separately: > > * GUI apps: QBzr, bzr-gtk, Explorer? > * other popular plugins? No opinion here, which is probably unusual given my interest in bzr-mac. I am here in bzr-mac because I need to use Bzr to develop an OS X packaging/installer for a Python-based application that is dear to me. That application's development community uses Bzr and Launchpad, so really fixing its packaging requires using Bzr under OS X. I hope that work on the application's packaging and installer could draw on lessons learned from packaging Bzr. Here's *my* initial brain dump. Firstly, some design principles ... > > (a) When it comes to installers, "1" is the divine number. +1. This matches the Pythonic ideal that There's One Way to Do It. > (b) When 2 installers are offered, the second one should offer a > superset of the first, not require one installer be run, then another, > then another, etc. +1. I see Bazaar is an application, with GUI's for the more casual/occasional user. Applications come with a single installer at most. > Secondly, some suggested bundling ... > > (c) The recommended installer ought to have everything necessary for a > great experience included. This bundle might be called something like > "Bazaar Desktop x.y" and might contain ... > > * Bazaar Explorer > * QBzr > * Qt and PyQt > * Documentation in Help Viewer format. The docs ought to cover the > core bzr tool + some docs on the GUI tools Any suggestions for generating documentation in Help Viewer format? * popular plugins (e.g. bzr-svn) > * libraries/binaries supporting those plugins > * core bzr +1 on the (c) list. > This installer needs to be available in many languages. If documentation > has been localised for a given language, we bundle that instead of or in > addition to the English docs. "In addition" strikes me as a good idea, so that the user whose native tongue is not English has English docs to refer to when looking for terminology to use on English-language discussion lists, blogs, and such. > (e) The "core/cli" installer (or easy-install support) ought to be > managed as part of the bzr core project. It should be easy to > automatically build and only require freely available tools to make. Sounds sensible. > > > (f) The "desktop" installer could be managed as part of the bzr core but > is arguably better handled as a separate project. It's quite feasible > that we'll ship a "Bazaar Desktop 2.n Release 2" 2-3 months into the 6 > month development cycle for Bazaar 2.n+1 because we may want to offer: > > * the latest stable core > * upgraded and/or more plugins > * new version of QBzr and Explorer say > * better and/or more localised documentation. > > It therefore makes sense IMO to make that installer a separate project > with its own small code base, bugs, translations, etc. +1. Bzr is much like the Python-based application I mention above: a fast-developing application with multiple dependencies and multiple plug-ins. Bzr development outstrips packaging and distribution, and those have needs independent of the development of Bzr's core; > > > And finally ... > > While I've used a MacBook > Pro laptop for most of the last 3 years, I use Ubuntu on a desktop right > now and under Parallels on OS X whenever I can. So I'm arguably Mac > savvy but a long way from hard core. If you live and breath OS X, your > opinion is 10X more important than mine. :-) My experience is a little different from yours. I have 20 years' technical support experience including remote support for installation of applications, some with simple installers under MS-DOS, some with multiple buggy sub-installers running under Windows 3.1/3.11/95/98//NT2000/XP. In the past couple of years, I have started supporting an OS X application as well, and using a Mac for daily life. Since I have to put up with the eccentricities of broken installers in my work life, I really don't want to enjoy such pleasures in my spare time! :-) I want Bzr and my Favorite App to benefit from good installers, and to spread far and wide; they're good technology, and deserve the best exposure they can get. -- David
_______________________________________________ Mailing list: https://launchpad.net/~bzr-mac Post to : [email protected] Unsubscribe : https://launchpad.net/~bzr-mac More help : https://help.launchpad.net/ListHelp
