I guess as a user, knowing that Dev and QA are complete doesn't really mean that a product is released if I can't install it. As a user of bzr I take release announcements with a grain of salt since to me all they mean is that another stage in the release process has been triggered and that a little while later, sometimes a day, sometimes a week, there'll be a product I can install. I don't really consider it waiting another day etc. I just consider it waiting for the release, email announcements to the contrary, I just can't be bothered to grab the source so I'll wait for installer. I'm not that hung up on dates, I don't really care if it's a day-0 package, the installer's ready when it's ready, and then it's released. Everything before that is just an early access option from my point of view. The term Release means different things to different people, I'm a developer, I know that I've got a different opinion to it when compared to some others in my office, but installers are first class citizens, they need to be part of the same process, and honestly they are what a lot of users consider to be the release vehicle. None of this changes the technical challenges of who, how, where and when. Guy <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>