I need to take some time to talk about the role of customers, or something like that.
Releasing is a management decision.
Whether that's an open decision or a closed decision, and whether it's for an open, closed, or semi-open project, it's still a management decision.
Typically management will have a list of things they want done, and will ask their teams of engineers, marketers, localizers and testers if everything is ready. Management can choose to wait for things, or press on. This is the case everywhere.
Last week, I had absolutely no idea when Firefox 3 would be released. If you're reading this, you probably know that there's a date. Although, it could change. There were no real plans for an RC3 until the middle of this week. And that's the open source project to which I actively contribute. Oh, I have no idea when Firefox 3.1 will be released, for all I know the version after 3.0 will be 3.14, 3.141, 3.1415, 3.5, 4.0, or 95.
I don't have any idea when Safari 3.1.2 will be available, or IE 8.
The only products that I know release dates for are date based products (I can predict Ubuntu 8.04).
The Mozilla view which I would hope people are familiar with is:
It'll ship when it's ready. talkback.html?article=1179 firefox-we-caught-microsoft-asleep-at-the-wheel.html #comment-1
Kairo (one of the driving people behind SeaMonkey) writes: Only, ever, ship when it's ready to be shipped, never before that point.
In Mozilla if someone writes X is fixed in bugzilla.mozilla.org, that just means there's a code fix (or it could be a process that's fixed, or a template for a document, or the next license or the next version of a web site), it doesn't mean it has passed through all verification steps. It could cause a regression and be backed out. It certainly doesn't mean that the fix will be available instantly.
When Sun fixes something in OpenSolaris the fixes will appear at bugs.opensolaris.org before they're available anywhere (as it happens, they're date based, so a fix should be in the next binary drop w/in 2 weeks unless it fails QA [which happens from time to time] in which case it may take a month).
Similar behavior can be found with other open projects (NetBeans comes to mind, you can see their issues but you should really read how their qa works).
As for Apple and Google, you will find that they may or may not announce a date for a product, and there can easily be a lag time between when it's announced and when you can get it.
Can't I get my kernel upgraded today? As for Kernel. If I'm using a Linux distribution, I know that just because mm or someone has committed a fix to an upstream kernel doesn't mean I'll instantly get that fix in my Linux distribution, in fact, for maintenance distributions (centos 3, rhel), I may be forced to wait for the time when I'm willing and able to upgrade to something newer. If I'm using a non-stock Linux or a non stock compiler (embedded-arm, codesourcery) then I'll probably have to wait for them to integrate the fix into a new release, and then pick a time to upgrade.
If you aren't used to any of these things, then hrm... I dunno...
I'm certainly used to waiting. And whenever people tell me about improvements, I'm happy, because it means that instead of bugging them about X, I know that they're responsive and I can choose to bug them about Y that they didn't know about.
Sure, this applies to Qt (I filed a bug against Qt, they confirmed it, I'm still waiting for them to fix it). Note that with Trolltech, if I'm told that they've fixed a bug in Qt, and I'm using Qtopia (which I was at the time), then I have to wait for them to backport it, or I have to wait for a new version of Qtopia (and those lag a bit).
This applies to them too, both Opera (I'm not sure how many bugs I've filed their way) and Apple (I need to report a bug about iLife's iWeb generating bad content to Apple).
I really don't know of many groups who deliver software instantly... At least, not good software.
As was written elsewhere (by the original complainant), there's a risk in fixing things, and perhaps it'll be backed out, or regress something else or .... Now I'm not going to discourage people from using bleeding edge software, bug reports based on the latest sources and binaries are always more welcome than old stale versions. But I understand the reason people don't want to upgrade (I rarely upgrade my software) and I would hope that people understand that if they're afraid of using the latest prerelease, then asking that the latest prerelease be released is at least a bit ridiculous, changing the name from "alpha, may destroy your computer" to "official" doesn't mean it won't destroy your computer.
Someone claimed that most people are not used to Nokia's policy to embargo any date (even estimate) regarding software (or hardware) release.
But please look at the rest of the industry. How can people not be used to this behavior?
I personally believe that Nokia's products are generally seasonal, although they have some wiggle room.
Regardless, it was discussed in maemo-developers and elsewhere that it is possible to retrieve Diablo updates - they're not simply vaporware, Nokia just isn't ready to ship them (perhaps there are still bugs to be fixed?).
Bugs are fixed when they're fixed, and transparency means telling people when they're fixed.
It's OK to want something, it's not OK to demand it. And it isn't acceptable to claim that something hasn't been done just because you can't get it.
If customers have a problem with management's lack of transparency in scheduling and actually releasing products, that's not something which should be discussed in developer forums. Managers don't read developer forums. And developers aren't paid for manager headaches.
For simplicity's sake, I don't know when Diablo will be released. I also didn't know when Chinook was going to be released (in fact, I believe a number of end users got Chinook before engineers at Nokia discovered/learned it was released).
Personally, I'm disappointed that when a bug is closed as "fixed in diablo", as a user I've no idea how to get the updated package on my N810.
Please excuse my disbelief ... you guys are the strangest users I've ever met.
I've got scratchbox handy,
In fact, I've got scratchbox handy is one of many definitions of not a user. Another is actually using Bugzilla at all (* see long paragraph below).
If you're using Scratchbox, or if you're using Bugzilla, you're a developer. As a developer, there should be a much higher barrier (reading a couple of pages) to entry.
If you're using Bugzilla, there are a few pages you should read.... Here's a short list of links that you can get to from enter_bug and show_bug:
Note that this page indicates what 4.1 is and that it's equivalent to Diablo (thanks to whomever maintained this wiki page). BTW, thanking people is a good practice, especially if you aren't paying for things.
The only other page I know of with numbers, but I don't promise to maintain it.
Recently, wiki.maemo.org has started talking about dates, hopefully that will help. (Historically the maemo.org roadmap pages were utterly useless, typically even the utterly useless Mozilla roadmaps which are perennially out of date at least tried to include guesses about seasons "next year".) maemo.org needs a page with release dates. Something like: CVS_Tags (which is sadly incomplete) would be nice....
This finally happened today, as the Codenames page includes a note to indicate that "Diablo" will not be available for download until after the N810 WiMax Edition is available for sale.
If it happens that this statement is wrong, someone can correct the wiki when a better statement is available. Most people in the interim would be able to follow the links read that, and realize that they'll just have to wait like the rest of us.
(I'm actually waiting for Diablo, and I'm an internal!)
Note that Bugzilla now only talks about versions (4.0, 4.1). And anytime someone says a bug is fixed in Diablo, they should make sure it has Target milestone: 4.1.
When 4.1 (Diablo) is released, then everyone can upgrade to it using whichever upgrade methods are available (I'll probably flash since I'm running stuff from 3.x or pre 4.0).
People may think that they can just download Firefox nightlies....
Try doing it for/from your tablet, Mozilla nightlies are available for a few platforms but that doesn't include tablets. Yes, as a convenience for testing they make available binaries for a limited set of common platforms, but for the rest you often get to wait for a release cycle.
If you were actually around when Netscape 6 was in development, you would see the same process that Nokia has now in place for bugs.
Well they certainly aren't users. They're developers. Developers should be expected to be aware of more processes, release cycles, etc.
In general, if you're a user (customer) of a vendor's product, the standard channel is one-way: Your vendor will announce via some means the availability of an update.
Users are supposed to wait for their vendor to tell them when there's an update. That's how it works for Mozilla Firefox, that's how it works for Windows, that's how it works for IE, that's how it works for Safari, that's how it works for every major software project in the entire world. Ubuntu included.
Users can try to make demands of vendors (people to whom they've given money), "dear Nokia, why haven't you given me a software update". They can call their vendor, send mail (I think it's 0.45USD these days), visit their vendor's store (there's one in New York, NY, and I know of one in Helsinki), or if the Vendor has some other feedback area, they may use that.
But if you aren't acting like a user then you have to do some other reading.
Developers are not free to make demands when the answers are already documented. They're expected to look up the answers.
In the free software world, you have to divide things a little more finely - there are developers, early adopters/beta testers, and late adopters.
I've been there. However anyone who is using an alpha or beta is expected to read documentation and learn about processes.
If I sent a message to LKML asking when an mm patch would be available in Ubuntu, I'd be flamed.
Can't we call people who use Bugzilla early adopters? I've worked with early adopters in the Netscape 6/7 days. At times I was one, at times I was a developer, and at times I was simply a user. Each class of person has a place, a role, responsibilities, duties, etc. and overstepping them is a violation of something.
If you make the wrong demands while in a beta program you'll be kicked out.
The list of the beta testers is because it seems there's no trust and within limits it would enable people to ask and answer questions without irritating engineers. This would be part of the price beta testers pay for getting early access to software, namely early access to nagging questions.
A beta program should not recycle more than 50% of the beta tester base.
This would be different as that testing has absolutely no public face. It would have to happen after products have been announced but before it ships (with a 1 month return on loaned hardware after a beta program ends).
To announce that I've unsubscribed from maemo-developers. The list really isn't worth my aggravation. There is no reason for users to ask such questions of employees.
It wasn't done when users or developers (and if you're going to provide categories, the people asking questions to maemo-developers are not developers, they're clueless users with scratchbox who refuse to read documentation or archives) were curious about a fix to the Netscape portion of a Gecko based release (Netscape 6, Netscape 6.1, Netscape 6.2, Netscape 7, ...). If someone said that something would be fixed in Netscape 6, we trusted them that it would be, and we waited. Or rather, we found something else that was wrong and reported it, hoping that it too might be fixed in Netscape 6. If we were really late and there was just some final polish to be done, we'd be told that something would be worked on for Netscape 6.1. Waiting is part of the process.
There were plenty of reasons to be upset with Netscape, but the engineers were given a certain degree of respect. And complaints about planning were generally directed where they belonged (at managers who were quite a bit more available than those from Nokia, including actually commenting in Bugzilla and often being available on IRC).
If this were an open source only software project, and I knew of an inferior product with inferior practices, I'd probably recommend that these people try that product.
My view is that people, especially developers have an obligation to read documentation and understand processes before they come and bother people.
Users (better customers) are supposed to contact the sales channels or official support forums. I'm told that maemo-users exists (I do not claim it is a support forum, nor do i intend to read it, however maemo-developers is not a support forum for users).