Let me say BIG THANK YOU to Jeremiah, Niels and whoever else has been involved in the development of the maemo.org packages interface - http://communitizer.blogspot.com/200...-packages.html

Now... let's have a look to the queue of apps that have been pushed from extras-devel to extras-testing:

http://maemo.org/packages/repository...ng_free_armel/

Zero! OK, makes sense. How do we get started, though?

People testing Maemo 5 inside Nokia are configuring extras-devel and trying out apps available there. However, the % of apps with dependency problems or other basic issues is relatively high. Enough to feel lazy about filing bugs at that stage.

So what about starting the process of developers pushing the packages that they think are ready to extras-testing? This will be more human testers (Nokia developers with units, SDK users...) concentrated in less but more solid applications.

I've read that dependencies in maemo 5 are a very big headache... I think we'll have lot of problems if something doesn't change

A final release announcement would give developers a reason to start polishing their apps for Fremantle.

Developing against a moving target like Fremantle that is hard to test in the current situation isn't fun:

• No task switcher in SDK (developer can't test integration of their apps)
• On-device software more recent than SDK contents (at least with beta1 this was the case for several weeks)
• Slow test cycles: upload, ask testers, wait for reply, ...
• On-device situations that are unreproducible in the SDK
• On-device features that are not emulated by the SDK
• Uncertain release date of final/frozen version

Having some kind of feature freeze or release announcement would help developers have a clear picture of what to expect in the end product and when to expect it. FLOSS developers write software in their free time.

Again, developers would have good reasons to get their apps running in Fremantle if they know the SDK contents are frozen (feature complete; only bugfixes) and they can expect a release in e.g. one month or whatever the timeframe is.

I resolved my dependency problem tonight, anyone with a real device and a Roku Soundbridge want to give Tabletbridge a try?

thanks,
Frank

Given the high developer relevance of this, I think maemo-developers should also be involved (if not the primary place of this discussion).

Otherwise, I'm echoing thp's thoughts entirely. The one bit of software I've published for Fremantle apparently has bugs, but I don't want more testing: I want to get the information necessary to fix those bugs first. Even once fixed, anyone using the accelerometers is going to have to have an awful lot of self-confidence to push something for wider testing.

Some of the "dependency problems" could also be being caused by the buggy implementation of the (not-quite-sure-if-it's-a-good-idea) third party package policy.

I don't know whether this is a topic for maemo-developers, here or a sprint task. I was just trying to kick off the discussion.

With all the problems you point out...

I still think it's worth to open the maemo-testing door. First because we need to test and probably fine tune the own promotion from devel to testing. Better to do it now that things are relatively calm than when a final release is out and everybody is in a rush.

Actually it is good to note that we haven't agreed on the criteria and process to promote a package from -devel to -extras (or have we?). That would be a good start. There was this maemo-developers thread and there is a wiki page, but no conclusions AFAIR.

In principle the promotion is meant to be automatic: the maintainer of a package thinks it meets the -testing criteria and pushes a botton. Then the automatic process runs some automatic checks and either promotes it or keeps it in -devel. So we need to agree on the criteria, see what can be automated now and put the trust on the developers for the rest.

My initial proposal for -testing quality criteria was:

We should add "The developers thing it's ready for testing".

And that's it. The fine-tuning and polishing belongs more to the promotion from extras-testing to extras. I agree with you that it is difficult for most hobbyist developers to go through this task without a final SDK, a product announced and an idea about the sales start date.

Clearly the current situation doesn't help getting applications polished. We can't give any dates for further SDK releases, but we consider this Beta 2 quite stable. Fremantle is in pure bugfix mode targeting the final release. The plan is to have a pre-final SDK release that will become the final either without changes or through a minor update synchronised with the Maemo 5 final release.

About the origin of the package dependency problems... The fact is with 120 apps around it's difficult to keep track of the broken dependencies created by the Package Policy, the ones caused by dependencies on deprecated components, the Python related problems... You don't know whether the developer is aware or not, whether it's in the top priority or anyway he is working on other stuff first, whether he actually wants to push that app to end users using Extras or is just playing around.

If the promotion to extras-testing is open then we can focus on the feedback of the developers willing to push their packages. And we can focus the human testing on the apps making it there.

This requirement doesn't make sense until there is Fremantle Testing category in downloads.

Applications which are in testing have to be clearly identified in downloads. Otherwise whole extras-testing -> extras stuff doesn't have any purpose because everyone will be using testing stuff unknowingly.

fwiw currently app entries in Downloads do have a label to state their quality:

Stable: http://maemo.org/downloads/product/O...personal-menu/

Beta: http://maemo.org/downloads/product/OS2008/aarddict/

Alpha: http://maemo.org/downloads/product/OS2008/gnumeric/

Should this be simply mapped to Extras, -testing and -devel?

I am really impressed by Niel's hard work on this project. He has done a lot of complicated coding to make the QA process easier for developers and brought a smart way to promote packages. His dedication to this community should be evident to everyone.

Let me elaborate a bit more:

- A developer is just playing with some packages in extras-devel: no Downloads page.

- A developer thinks the app is in a shape good enough to be promoted to -testing: Page created with Alpha label.

- An app makes it to extras-testing, ideally the page would be automatically updated to Beta within a week. Otherwise the change would be made manually.

- An apps makes it to Extras, ideally geta automatically updated to Stable quality. Otherwise the change is done manually.