[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:
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. Quote:
/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?
Quote:
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. |
All times are GMT. The time now is 07:44. |
vBulletin® Version 3.8.8