extras - sure. extras-testing - no idea. extras-devel should be left.

IMO, Tech stuff and Council should remove not only the dangerous but all packages that require reflashing to get rid off. There should be no exception unless there is a popup that informs the user during installation. Mentioning it in the download page and description is obligatory, but clearly not enough.

And while you are at it, could you please remove also this:
http://maemo.org/packages/package_in...map/5.59BETA1/ from extras-testing and devel?

Dangerous/Risky patches/apps should not be promoted to extras-testing until they are fixed by the developer. Deleting them completely is unfair.

title of this thread should have been
last chance to come up with technical objections against removing *patch from extras and extras-testing
As mentioned by MT in #1, it's already been decided about that we gonna remove it if no technical objections aganst that. A general poll is not productive anymore at this time. Neither is extending the topic to anything other than *patch.

/j

Last time I checked, general consensus was to revisit exact rules about things forbidden in packages, and giving time for developers to fix it, then starting to take action.

If you would care to read this (short) thread - it wasn't about those 2 packages, but about packages violating rules in general.

I'm also pretty sure, that Mentalist wrote exactly what he wanted to wrote, and doesn't need "correcting" to focus on witch-hunt for crapatches, only. Please, don't go deaf for Community suggestions - many wise ideas in this thread, and it would be pity to waste them, focusing *only*

I think both topics need covering separately.
However things are getting mixed together.

That's a funny one. I'm sure Maemo itself breaks Debian packaging guidelines. Notwithstanding that, it surely breaks Unix common-sense..

I don't think we should remove packages, unless they are clearly broken (e.g. "rm -rf /" in postinst, unless this is clearly described as part of what the package provides..).

The problem here is that unstable packages (e.g. speedpatch and batterypatch) have passed extras-testing and are now considered stable, i.e. in extras.

So there are 10 people (I think it's 10) who voted positively. And that is where we have an (unsolvable) problem. You will always get 10 people to vote yes to ANYTHING.

But hey, that's an inherent problem in life, and not just in Maemo. You either give people the freedom to say "this package is stable" or you give that right to the enlightened few/one. Both approaches are wrong, but there's no third option .

According to un-scientific "testing" (lol) from TMO forum members who want a quick boost, it "works".

And technically, that qualifies it for Maemo.org extras.

I think that one solution to this problem is an "extras-labs" repository for packages that interfere with Maemo core system components.

Advertise the extras-labs repo as a place where packages could blow up your device without following directions to the letter.

If a package in -devel doesn't move to extras even if a sufficient number of users (note, that was the point of the voting system in the first place) call it stable, what's the point?

I would leave things as-is: extras is for tested, stable, packages. Extras-testing for testing packages *and subsequently (after a given limit date) moving to extras to back to devel*. Extras-devel is for "may eat your babies" stuff.

Now if I write a program/package that *I* consider "stable" (by my own definition) and I want to make it available to people who know what they're doing, but not to everyone then I just make my own repository (like Ubuntu's PPA's) and then everybody's happy.

This would allow some kind of "bleeding edge" updates to SOME programs, without having to buy the whole extras-devel package.

Not wanting to move this thread any more off-topic.
I should point out that Maemo policy must follow Debian policy unless not feasible.
Any deviations from Debian policy should be listed. Any packages that do not conform "MUST be fixed" or the policy changed to suit foo-package.

http://wiki.maemo.org/Packaging/Guid..._Debian_Policy

https://maemo.org/forrest-images/pdf/maemo-policy.pdf