<div class="gmail_quote">On Wed, Jul 29, 2009 at 11:00 AM, John Arbash Meinel <<a href="mailto:john@arbash-meinel.com">john@arbash-meinel.com</a>> wrote: <blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Guy Gascoigne-Piggford wrote: > Strongly seconded. > Just to mention, I've *often* released a X.Y-2 or even X.Y-3 because of packaging issues. I haven't done one for 1.17 specifically, because it is unclear what actually needed to be done. (I think it needs a newer bzr-rebase/rewrite, though not positive.) I *don't* think we need to release 1.17.1 because packaging failed. That is why the packages are labeled 1.17-1, as the final -Z indicates the *packaging* release number. Failures in packaging bump the packaging release number, not the bzr release number. If someone wants to propose a reasonable fix to get the all-in-one installer working (like telling me "use bzr-rewrite-0.5.100", then I'll go package one and let you poke at it. I would like to see packaging work a little better than it does today. We have some work from Sidnei da Silva to get a continuous build process via buildbot. (Not complete yet, or at least, not up to date.) However, there is a fairly large overhead in dealing with packaging, which is then compounding the difficulty of managing a release. And when you do at least a minor release 1/mo you want that to be a simple as you can make it. It would probably be good to have an item on a RM's checklist to go poke the people who build installers a couple of days after the official release has gone out. I'm *never* going to promise day-0 packages. Between coordinating timezones, vacation schedules, level of development activity, bugfixing, etc. Packaging is important, it certainly isn't the most important thing. Heck, when we get to the point of stable-every-6-months... if you are running code that is 6mo out of date, does it really matter if it takes an extra day to get it to you? John =:-> -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (Cygwin) Comment: Using GnuPG with Mozilla - <a href="http://enigmail.mozdev.org/" target="_blank">http://enigmail.mozdev.org/</a> iEYEARECAAYFAkpwjlcACgkQJdeBCYSNAANFMgCfZiOc8QMaSUD8/U2n9l/f9NpR P/oAoMMNoCrucDaiOXnPOnLjJ46oT3eR =Pp9e -----END PGP SIGNATURE----- </blockquote></div> I agree that packaging is important in general and especially important for releases labeled "stable." This has been a subject of discussion recently on the list and actually is improving to the extent that people like John and Guy (and others!) have been able to step up to do the work and provide feedback. Make no mistake, packaging is a *big* job -- as big as it is important. That said, I also think the proposed stable branch helps to alleviate the problems some of us may have experienced with the current release process. If it takes a week to get an installer built for the stable branch, that may be ok for people using the stable branch. It is stable, after all. As for the development branch, well, anyone who *needs* those should also know how to build their own installer if need be. We use a system like this internally at my company. People who need (or want) to track the bleeding edge accept the extra responsibility of being mostly self supporting. People who just need a stable tool wait for the installer on the stable branch. It works well, because we have clearly defined stable and development branches. And what *really* helps is that we do not announce a stable release until the installer is built and tested. What I'm saying in too many words is that I think the installer availability situation can improve under the new release proposal, because only the stable branch needs installers and they can be delayed for QA without slowing down the core developers. This is just my two cents as a bzr user who just happens also to be a professional developer of other products. This works for us, but maybe not for everyone. ~M