Reply
Thread Tools
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#11
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 Following 2 Users Say Thank You to Android_808 For This Useful Post:
qwazix's Avatar
Moderator | Posts: 2,622 | Thanked: 5,447 times | Joined on Jan 2010
#12
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.
__________________
Proud coding competition 2012 winner: ρcam
My other apps: speedcrunch N9 N900 Jolla –– contactlaunch –– timenow

Nemo UX blog: Grog
My website: qwazix.com
My job: oob
 

The Following 5 Users Say Thank You to qwazix For This Useful Post:
Posts: 2,225 | Thanked: 3,822 times | Joined on Jun 2010 @ Florida
#13
Originally Posted by Ken-Young View Post
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....
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.

Originally Posted by Estel View Post
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.

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.
Originally Posted by Dave999 View Post
Removal from extras would be nice. Would also be nice with some logs of what is removed and why.
[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.

Originally Posted by uros View Post
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.
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.

Originally Posted by sixwheeledbeast View Post
I would like to point out the original report is here.
http://talk.maemo.org/showpost.php?p...postcount=3325
I take it you didn't notice I linked straight to this post in the initial post of this thread?

Originally Posted by sixwheeledbeast View Post
Personally I don't see why they can't be removed completely. Leaving the sources in garage for potential future maintainers to repair.
- 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.

Originally Posted by Estel View Post
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.
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.
 

The Following 7 Users Say Thank You to Mentalist Traceur For This Useful Post:
Posts: 1,225 | Thanked: 1,905 times | Joined on Feb 2011 @ Quezon City, Philippines
#14
I dislike *patches in general, however the "dangerous packages" I had in mind were ones that had
Code:
rm -rf --no-preserve-root
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.
__________________
N9 PR 1.3 Open Mode + kernel-plus for Harmattan
@kenweknot, working on Glacier for Nemo.
 
Moderator | Posts: 6,215 | Thanked: 6,400 times | Joined on Nov 2011
#15
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.
 

The Following 5 Users Say Thank You to thedead1440 For This Useful Post:
Posts: 2,225 | Thanked: 3,822 times | Joined on Jun 2010 @ Florida
#16
Originally Posted by Hurrian View Post
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.
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.
 

The Following 2 Users Say Thank You to Mentalist Traceur For This Useful Post:
Posts: 1,225 | Thanked: 1,905 times | Joined on Feb 2011 @ Quezon City, Philippines
#17
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.
__________________
N9 PR 1.3 Open Mode + kernel-plus for Harmattan
@kenweknot, working on Glacier for Nemo.
 
Posts: 44 | Thanked: 5 times | Joined on Feb 2013 @ Kenya
#18
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
 

The Following User Says Thank You to cdooh For This Useful Post:
Posts: 1,203 | Thanked: 3,027 times | Joined on Dec 2010
#19
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.
 

The Following 4 Users Say Thank You to Android_808 For This Useful Post:
Posts: 2,290 | Thanked: 4,133 times | Joined on Apr 2010 @ UK
#20
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.
__________________

Wiki Admin
sixwheeledbeast's wiki
Testing Squad Subscriber
- mcallerx - tenminutecore - FlopSwap - Qnotted - zzztop - Bander - Fight2048 -


Before posting or starting a thread please try this.

Last edited by sixwheeledbeast; 2013-03-30 at 09:30.
 

The Following User Says Thank You to sixwheeledbeast For This Useful Post:
Reply

Tags
community, dangerous, extras, harmful, repositories

Thread Tools

 
Forum Jump


All times are GMT. The time now is 13:49.