[Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

Okay, so on the meeting held on 2013-03-15, community member sixwheeledbeast brought up issues with the relatively well known packages speedpatch and batterypatch.

The criticisms against those particular packages were that:

• speedpatch installs itself by modifying syspart in a way that's not uninstalled cleanly (because it didn't use the standard syspart as the reference for what to make it after uninstall), and that it has caused people to have to reflash in the past.
• batterypatch automatically overclocks a device that installs it without any warning to a user
• batterypatch is coded in such a way that it does not properly check for the more recent power-kernel versions, even though it depends on that package
• One or both (I don't recall) of them violates the Debian packaging guidelines (which Maemo packages are supposed to adhere to).

After some searching since the meeting, I am personally uncertain if all of those criticisms are completely up to date - speedpatch's changelog says since version 3.5 that it does a safe uninstall and uses syspart configs provided by Nokia, for instance. So, obviously, a more in-depth look should always be conducted before doing anything to any package.

But the main point is, does the community think either the tech staff volunteers, or the Council, (or the Board, in theory), should act to remove packages that do clearly have the potential for damage from the Extras and perhaps Extras-Testing repositories? (Extras-Devel would be left untouched either way.)

[The Council's position as of two weeks ago was a unanimous yes for removing harmful packages from both Extras and Extras-Testing.]

[Full disclosure: Although this question is from the entire Council, the text in this post was written by me alone without the proof-reading usually done by other Council members.]

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

I believe such packages should be removed. I was bitten by the unexpected overclocking after installing batterypatch. I didn't realize overclocking was happening until many days after I installed batterypatch, and I certainly didn't expect that program to change the clock rate, so it took me quite a while to figure out what had happened. I was not pleased....

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

Removal from extras would be nice. Would also be nice with some logs of what is removed and why.

Let's remove some stuff

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

I think no. Mainly because is good thing to have choice. If any user wish to install those particular packages, this user have choice and responsibility.

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

I would like to point out the original report is here.
http://talk.maemo.org/showpost.php?p...postcount=3325

I made my feelings clear in the meeting.

Personally I don't see why they can't be removed completely. Leaving the sources in garage for potential future maintainers to repair.

IMO these should be treated separately from simple broken packages like "theme-customizer" for example, due to the nuture of the damage that can be caused.

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

This may have some sense only, if clear guidelines what is *not* allowed in package, would be prepared. Otherwise, packages with many influential people biased against them (batterypatch is good example here - heck, I'm also biased against it :) ) and/or bad fame, could get removed/harassed without thorough testing of actual state.

As said, I'm not fan of packages like speedpatch/batterypatch, but just like MentalistTraceur, I'm not sure about their actual state. Also, people tend to mix battery patch and speedpatch into one thing (AFAIK, only one of them does overclocking - 2nd is wrong [as in useless], but not harmful, either).

I certainly *don't* want to see packages removed, without good report about what serious and obligatory rules they've broken - especially, after perceiving first hand, how "objective" some people in tech staff are.

That, for example, is very bad reason to remove package - it should result in kindly asking maintainer to fix packaging, at most. Otherwise, we should remove 1/3 of extras, including some really good things from various "community heroes" here.

/Estel

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

I think the council should be allowed to do so, if they can prove a package is dangerous/malicious.

And even though people are warned about the dangers of installing from the extras-devel and extras-testing repositories, intentionally dangerous software should be removed.

In case the maintainer of a package is aware of faults in his or her software, as described by Mentalist Traceur, and does not take action to fix this, these packages should be removed aswell.

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

Not 100% true, modifing syspart is equally as harmful.

My report linked above has been done after testing both packages and checking it's sources. I had to reflash due to device unstablity. This is not a anti-foopackage issue.

The maintainer is not capable of repairing the package in this instance.

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

sixwheeledbeast, you're last person, that I would expect to have bad will, when it comes to testing packages.

Nevertheless, I think that it would be more fair to re-define rules for packages (what can't be in repos and why), announce them, and give maintainers 2-3 weeks for fixing. Then, start mercilessly executing those rules, be it against *patch or any other super-popular and respected package.

This way, it should be fair for everyone, without any sneaking suspicions about anyone being biased against anything.

/Estel

// Edit

And yes, I'm kinda playing advocatus diaboli here - I think that the more clear rules applying to *everyone* we will setup now (and tweak, if experience taught us about need to), the better future will be ;)

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

No matter that (maybe) I am the most anti-crappatch person here, I have to unpleasantly agree with Estel - we should modify the rules for extras in such a way that maintainers to be given a chance to fix/withdraw broken packages from extras. Along with a definition of what is "fubar package in extras". And if they don't fix/withdraw them, there should be a procedure to be followed.

I think extras-testing should not be changed, IMO it is fine.

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

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.

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

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.

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

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.

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

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.

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

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.

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

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.

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

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.

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

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

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

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.

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

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.

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

i think it was clearly enough repeated that what is being asked here is that the patches are removed from extras and extras-testing on the ground that they have been tested and shown to be at best useless or at worst requiring a re-flash.

the only thing i missed so far (and which was discussed on 15th of march) is the fact that the author does not have access to a N900 (or even dev. environment?) currently (and possibly for any foreseeable future?) and thus will not (be able to) fix the package(s).

my vote (if that's what's expected here):
any package that once tested turns out either to be useless or even (potentially) damaging to a device (conflict or dependencies and what not) should be removed from extras and extras-testing but left in extras-devel so that either the author or any interested dev can try and fix it.

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

I don't mind if it just gets shunted back to devel, as long as there is some notification on its repo page, even if its the just a clear in the package history/status at the bottom. A seperate sub-board on here recording the action taken and the reasons behind it could be created. Then any devs wanting to pick up unmaintained packages can make it known.

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

One thing I'd like to clarify here is that testing is not a "place between extas and devel" as in middle ground of riskyness. It's a place where developers place packages they absolutely believe they are extras-worthy, for other community members to test. There is no point of any package to indefinitely stay in testing. See it as the community equivalent to ovi submission. Any package in testing should either be promoted or rejected.

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

Just to jump in here, this kinda sounds like the issue to me -- there is currently no place for "middle ground of riskiness" types of apps. I've been surprised by this before -- the first time I pushed an app up to extras-devel, I found many people were expecting it to be a full-blown working program, when I was expecting I would still have time to develop it. :)

So, exactly what is "extras" today? If it is meant to be a repository of every piece of executable code available for the N900, then you can't in good conscience remove even the bad stuff from it. If, instead, it is meant to contain only a subset of all applications, then yes, the maintainers _must_ have the ability to remove entries that fall outside of that subset.

If "extras" is meant to be a set of tested, functional, presumed safe apps that any user could download without worry, perhaps another repository (say, "extras-additional" or "extras-risky" or something), could be formed for apps that don't fit into that category?

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

That it what I was getting at earlier with regards to a quarantined repo. A sort of everything here has a known problem, if you still want to use it, that's down to you place.

I think the reality is that the repos have become misused because of the lack of application promotion from Testing to Extras for everyday apps. cuteTube - to pick something just for illustration - has sometimes had an old version stuck in Extras that no longer works due to an API change. The fix makes it as far a Testing and stops. End-users then result to enabling Testing to get the fix, and then start relying on that repo for everything else. It is kind of the same as with Debian. Stable is around with no updates, users want new features so they switch to Testing, so where do the testers and experienced users go? They're just testing what everyone is already using. Problem gets introduced to Testing, everyone gets it. We already see this when end users complain about an issue CSSU-T, particularly, sadly for freemangordan, in Thumb where he waits for positive feedback of CSSU-T before pushing updates. The "it don't work" kinda people :p

We need to introduce a way to push small fixes and updates through to Extras much quicker to get the non "tech-savy" people back where they belong so they can disable the repos they shouldn't need to use. Larger the update, longer the testing.

This way you can shunt packages from Extras to Testing if you suspect there is an issue to stop the problem spreading and the people using it can test it out. If there is no issue, re-promote it, else push it back to Devel, which only developers and very experienced users should be using to test a subset of packages. Devel should not be used for general testing.

If we get this right, we don't need extra repos. Mods should have the ability to move packages in to/ out of the day to day, end user repo. We have a 3 tier structure, it just isn't being used correctly.

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

With regards to Karam's crapperware, it should never have ended up in the repo's in the first place. The moment it became clear that Karam was just throwing scripts in a package (scripts he found online, which he didn't understand himself at all) the packages should have been pulled. And it became even more annoying with the tons of threads about problems that were created by these scripts, for which Karam was not able to provide help.

As much as I believe in the open repo model, I tend to believe that tight and strict quality control is of vital importance. Practically for me that would mean something in between the Debian way and the Ubuntu way.

Slightly off topic, but recently I also noticed some license violations on a closed source package. Shouldn't there be some supervision for that as well?

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

License violations, if they are liable to cause issues by the repo hosting the offending package, are definitely something to look at. If it is a critical package or used by a lot of people, then something needs to be negotiated/repackaged or adapted to make them available. If you don't say what package, can we just stay oblivious.. ;)

I must admit I initially tried a very early version of one of the *patches, probably speed. The positive feedback regarding the "~200 line kernel patch" or Lennart Poettering's bashrc alternative, combined with my own laptop experiments gave me some hope that it may achieve the same. Initially it felt quicker, but after several serious interactivity hangs..it was flashed away.

I know a lot of your feelings regarding them/him, but these are just two packages by one developer. A lot of the comments so far have made this read like little more than a Karam bashing session. At the end of the day, he tried. He contributed his time and his effort towards something he hoped would help the greater community. I think a lot was to do with his attitude. marmistrz tried libxau6 update which caused problems, but he's still around and still respected.

Stop focusing purely on 2 packages and start to see the big picture. Coincidently, the libxau6 issue highlights my point about people misusing the current 3 tier structure.

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

I think it makes sense to move them to extras-devel.

The warning levels seem pretty plain between extras-testing & extras-devel. Slightly wonky code would be an expected possibility for extras-testing, a user would be more likely to research an application from there, & it would still give a location for availability for those who wanted to try or modify it.

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

As far as I know the issue with Connected N9 has more or less solved itself...

Sorry if it felt that way, but I disagree. I could have mentioned the early stages of Nitdroid as another example and there are more, but I chose this one as it is so obvious that it's hard to believe it was so ignored. Also, I only look at packages that interest me for some reason.

Which he didn't. People are still cleaning up so at the end of the equation the question is: Why do half-illiterates teach others they don't need an alphabet?

People are helped when offered solutions or knowledge to get to those solutions. I am all for a positive attitude and I have warm and fuzzy feelings towards the idea of a greater community. But if you are unable to split the red sea, I'd say you're unable to lead your people through to the other side.

Fully agree. Nothing to add.

Wasn't the problem with the libxau6 more of a repo security problem, rather than a coding problem?

Yes sir, I will.

I have not followed this particular discussion, only glanced at it. Please continue to highlight it.

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

Agree, but as I said, he tried. I feel some of the ill feeling should be directed at the users who continue(d) to use the packages, the people who should have been testing them and the system for allowing them to be promoted to Extras.

The issue was that whilst trying to add some Meego support, it allowed the developer to replace a core package. There were some discussions about how to avoid this in the future in other packages, such as using gcc-4.6 as a package name to avoid interfering with gcc 4.2 until it was tested and then editing a metapackage to pull in the updated files. Whatever the solution was, that isn't as important at the moment.

The real issue was that despite lots of warnings, many users still have -devel enabled and still continue to use apt-get. In this case, a number of lucky users received a free reboot-loop with their upgrade. Hopefully some of them may now have learnt their lesson.

The problem, as this illustrates is that even if you demote the problem packages to devel, there are still a number of insert expletive here users who will have devel enabled who'll install them anyway. Why?

The problem is, as I may have stated earlier (I can't remember as it's the fourth time I've had to rewrite this post thanks to Wifi dropouts, NetworkManager/Bluetooth causing kernel panics....) is that users are accessing the wrong repos because the applications they want are not getting pushed through to Extras/Testing. If we can get this right, you can stick whatever you want in devel because everyday users won't have to use it.

Apologies, it was worded better but after 4 times I'm tired of writing the same thing.

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

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

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

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?

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

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

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

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

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

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*

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

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

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

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 :).

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

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? ;)

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

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.

Re: [Council] Should Tech Staff and/or Council Remove Dangerous Packages From Extras and Extras-Testing?
 

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