Could the moderators promoting packages from testing to extras simply take into account a negative vote count for each package?

If a package has a reported issue, negative feedback etc etc, move it to a quarantine repo (or something similar). Provide some guidance on the general reasons why the packages might be relocated to this repo as is done for the guidance on testing and devel.

The packages won't be removed altogether, they will be relegated back to devel and the maintainer has the right to promote again after they are fixed. See it more as repairing a wrongful promotion than anything else.

I am not sure new rules have to be issued as the patches clearly violate existing rules. Maybe we should set a rule that overclocking by default should be prohibited (unless user gives explicit permission), but that I think is common sense. The fact that overclocking voids the warranty should be enough evidence to the common sensibility of it.

Seeing the process backwards, if the community and the maintainer sees the decision to demote as wrong, it would take just a few days for the package to reach extras again.

Just so that this is noted, at least nowadays the description of the batterypatch package says that it overclocks the device. However, it's at the bottom of the description, where most users are unlikely to see it. (Sure we can say users should be more careful, and I'd agree, but even so something like an overclock should not automatically turn on without a clear affirmative from the end user.)

The other thing is if anyone goes and uploads a package that has batterypatch as a dependency, and that makes its way down to Extras or Extras-Testing, the dependency would be pulled with absolutely no warning or prompting to the user. So even if the description made it immediately obvious it overclocked, if it ever got pulled in as a dependency, users would not see its description unless they went out of their way to look.

[Insert other quotes about clear explanations of how the removal is determined.]
Agreed, a log and clearly stated guidelines for what is grounds for package removal would be nice. The log part might require some serious community coder volunteering to get that done in a way that doesn't depend on the people doing it manually updating the logs, though.

There's still choice, because you can always install the packages manually or out of extras-devel if you really want to choose that path. Yes it's a pain and extra inconvenience to either manually get the packages, or to enable extras-devel in the app managers and expose yourself to a bunch of other risks.

But think about this: a package is damaging, and gets promoted to Extras because enough people liked it without realizing that it is damaging, do the people who download it from Extras (expecting it to be safe) really choose to possibly mess up their systems? No, they just get messed up by a bad package that they might not have the skill or ability to check the safety of.

I take it you didn't notice I linked straight to this post in the initial post of this thread?

- Because users' choices should not be confined to only things other users can concieve of them wanting.
- Because the whole point of extras-devel is to have a hellish no-man's land where things can brick your device, but into which people can still venture to grab prebuilt packages if they so desire.
- Because one person's "is damaging" is another person's "risk I want to take", so while we might collectively agree something is too damaging for us to allow into the repos for unsuspecting users, we shouldn't deny those who /do/ want to take those risks the benefits of packages produced by an autobuilder instead of forcing them to go to precompiled binaries or build their own copies from source. Willingly taking a specific risk (downloading known broken package) does not mean willingness to take other risks (use precompiled binaries that are less guaranteed to match source than the autobuilt ones), or that they should be forced to choose between those other risks, or extra inconvenience (compiling from source). Yes I realize *patch packages are largely scripts, not binaries, but in general the above applies.
- Because it means one less repository to check (in case all repos have different versions) for the techstaff/volunteers/council/whoever.

Agreed. You'll note I didn't actually say "licence/debian packaging standards incompatibilities" along with damaging/harmful as reasons. I just listed that because it was one of the problems listed by sixwheeledbeast during the meeting.

I dislike *patches in general, however the "dangerous packages" I had in mind were ones that had in the postinst.

As long as what it does is clearly mentioned in the description, keep it. It's a legitimate package.

Users who seriously don't know what it does and install them from -devel anyways are either Maemo newbies, or riders on the short bus.

And for the users who do know what it does and use it anyway because it saves them a few hours of reading the Wiki and tweaking, good for them.

Hurrian,

From what I understand its not the -devel part that's the problem but the issue of it being in Extras. Since Extras is pre-loaded into every N900, it makes many people who don't come around here susceptible to something that sounds very promising.

Pushing the packages to -testing or -devel is fine as the role of the user becomes greater.

Yeah, as thedead1440 said, this is about whether to remove packages from Extras or Extras-Testing; so far everyone commenting besides sixwheeledbeast was fine with them staying in extras-devel. Unless of course your comments were specifically to respond to that "remove from -devel or not" side discussion, and you realize already that the main discussion is for the extras(-testing) repo removal, in which case disregard this post.

Oh, yeah, missed that. Sorry. Mea culpa.

I think a more amicable solution is to put

"Warning: This package overclocks your device and alters system components and settings. If you are not familiar with what exactly this package does, please do not install it.".

before the package description. Simply labeling it as "speedpatch" or "batterypatch" with a description of "makes your device X times better" doesn't properly inform the user, especially that it's about to do something potentially risky.

Remove them, everyone knows that the packages in extras-devel can be dangerous, it ont every page mentioning them but extras is considered safe, testing too though perhaps not as stable as extras

i agree, with hurrian regarding the rm command, but this is a generalised example. the only issue i have with moving back to faulty packages back to devel is your putting something back with known issues. devel to me has always been about untested apps, they might be ok, they might not. Totally the users risk.

if you do move them back to devel you need some way of indicating that a known issue has been found. In this case, mods + developer know there is an issue.in this case, if something happens to users device the viewpoint will be different as people where aware of an issue.

ot: as an aside, i would like to see changelog details when updating/installing like in cssu updates for all packages.

I understand it's a fair point that people should be able to download a damaged package.

But as Android_808 above, extras-devel is for mostly untested packages under development.
This package is badly broken and unlikely to be "devel"oped anymore.

Either way I see it from both POV's and the main issue is pushing speedpatch (cgroupspatch) back to devel from extras as a minimum.
This will stop the potential system damage of "end-users".

Bearing in mind that batterypatch (even tho it's in devel) is causing choas hence Ken-Young's post.

Yes I did miss your link MT, sorry.

Edit:-
You have to remember I have mostly got my "package-test" hat on here.
I feel we should protect are testers from known system damage as much as possible.
Without willing testers packages would stay in devel or testing forever. This in turn defeats the object of pushing unstable packages back to devel, or promoting good packages.