^^^^ what he says!

Can you ping your team again? There are quite some packages waiting in the queue and I rather test all aspects of the promotion chain before devices end up in people's hands.

It would also be nice for developers to know if their app is working/behaving on devices which they don't have

I've also been testing a few apps and added comments on a few ones in the promotion interface and/or filed bugs/send emails/pinged folks on irc.

I am wondering what other developers without a device are doing...

I have never put a package in extras-devel (let alone promoted it to extras) without having installed and tested it on the device myself and (in the case of GPE) had at least a couple of other people test it on their devices. Not only do I want to make sure I haven't made some simple mistake (e.g. with installation), I need to be able to debug and support any problems people report.

However, if we all wait for that for Fremantle it will be quite some time before lots of packages are available.

Are other developers who do not have N900's putting their packages in extras-devel as soon as they compile? I realise that some testing can be done in X86 but not everything (for example installation cannot be tested because the set of packages present on a clean device is very different from the set of packages on a clean SDK; init scripts and other startup actions cannot be verified, which is absolutely critical as it would stop the user's device from booting, etc.).

Does the community want developers to put packages into extras-devel and promote to extras-testing as soon as they compile and seem to work under X86? Or does the community want developers to wait until they have devices and can test and support their packages? There is no right answer and, as this is a tradeoff between supportability and availability of applications at launch, I suspect the answer may change over the next few months.

I would appreciate some guidance from the council, and Quim.

During the Danish Weekend, we were allowed to upload and run our apps on development devices to see how they work (or what's missing). Turns out that these development units had about the same contents as the SDK (no task switcher, etc..), so some things really could not be tested, and the software environment was not really different from the SDK (apart from running on a real armel machine).

Apart from that: Yes. It's really difficult, and prone to error, and introduces some delays while the package is running through the autobuilder to finally land in the repository and then some more time to get someone with a real device to test it.

Combine this with the fact that the SDK contents differ from the on-device software (this was a big problem with pre-beta2, don't know the current situation), and you're in for some nice trial-and-error testing.

One does get a glimpse of how the engineers of the first moon lander must have felt, having to design and implement something that they can't really test in a real-world scenario before releasing it.

Extras-Devel: I'd say yes. No harm done, and if someone uses Extras-Devel, (s)he has to live with the fact that things might (and will?) break.

Extras-Testing: AFAIK there will be clear guidelines for when a package in -Devel can enter -Testing (and same for the -Testing -> Extras transition), so that apps with problems won't be promoted from -Devel to -Testing without further checks if things work.

Of course, I expect the UI of several Fremantle apps to be redesigned/refined after developers have gotten their hands on a real device and have seen how built-in applications utilize the new widgets and how it works in a real-world scenario. But that's just the UI, and not the backend/lower layer stuff, which can already be stable/ready.

Giving the developers some weeks headstart to fix issues before public availability of the units would be helpful, though.

Generally speaking I think I remember an article about Apple's appstore stating that Apple has approx. 20 (?) full-time employees just testing 3rd party apps before making them available to end users (Darn, did not bookmark it).
I don't think that letting a company decide is the best solution if you have a community around like we have in maemo.org.
I hope that the number of Maemo "fans" will increase with the launch of the N900 and that some of them will join testing -devel and -testing apps and promoting (as much as I hope that more people will join the Bugsquad and that we won't lose them directly again as they become developers, like it happens so often in KDE and GNOME Bugsquad, but that's totally different debate). ;-)

I recommend you to have some flexibility these days specially when uploading software to extras-devel. Once you are there it's easier to get feedback from user with devices. Now that the N900 is launched reporting bugs publicly is easier for many people.

extras-devel is now conceived in a way that you actually don't need much external feedback to be there. extras-testing is the place to get human feedback.

Also, having your software in decent condition in extras-testing or at least extras-devel will make you a better candidate to get fresh hardware sooner...

I tried to promote Mauku 2.0 beta 3 into extras-testing. The result was: "Server Error Can not continue promotion, because dependency package microfeed is a user section package and needs to be promoted first!" However, I had promoted the package microfeed just before that!

Is there again (saying "again" I refer to very annoying dependency handling in extras-devel autobuilder) some unspecified time that a promoter has to wait before the promotion is actually performed? Is it really true, that I have to sit and wait until all dependencies have gone through some promotion phases until I can click the "promote" link of a next package?

I bet there are also other developers who really do not have that much time to spend to unnecessary bureaucratic steps. The promotion interface as well as extras autobuilder should not introduce additional load for developers, but function very smoothly and almost transparently.

Luckily there is ongoing efforts to fix extras autobuilder. I hope the promotion interface is fixed too (or even better: I have just misunderstood something and everything just works).

I think that X-Fade is still making the actual promotion manually

According to Microfeed description I'm not really sure what it is. If it's a real application it should have a easier description. If it's not a user applicaition it shouldn't be in user/ category