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.

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.

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.

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?

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

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.

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?

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.

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.

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.

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.