Re: Proposal: Karma-Whores protection mailing list
ext Anderson Lizardo anderson.liza...@openbossa.org writes: Well, the direct dependency check wouldn't do anything useful anymore, or would it? (I.e., has-dependency || pymaemo-optify-is-installed == pymaemo-optify-is-installed.) Yes, having pymaemo-optify installed after .deb's have been created would be a indication of that package depending (directly or indirectly) on some Python package during build. That is true on the buildbot, but not on people's machines. The buildbot has close to the minimal amount of packages installed for any given build, but people's machines have a lot unrelated packages installed, usually. So I don't think we should look into the build environment, we should only look into the source tree or the packages that have been built. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
ext Andrew Flegg and...@bleb.org writes: On Sun, Jan 3, 2010 at 10:56, Matan Ziv-Av ma...@svgalib.org wrote: What do you mean optify is the default? optification is a temporary hack, and it is being replaced by a real solution as soon as possible. I'll put money on it being a temporary hack for the lifetime of Fremantle; Yes. I would consider it a complete disaster if Maemo 6 requires optification as well. It would be awesome to get rid of optification already during Maemo 5, but that is probably not feasible. The plan for Maemo 6 is to put everything on the eMMC by default. It has not been implemented yet, and there is thus not much experience with running the whole OS from the big eMMC. There might still be some surprises caused by the performance differences between ext3 and ubifs, or between the OneNAND and the eMMC. But I don't expect these surprises to topple the whole plan of putting everything on the eMMC by default. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
Marius Vollmer wrote: The plan for Maemo 6 is to put everything on the eMMC by default. Excellent idea. Finally :-) It has not been implemented yet, and there is thus not much experience with running the whole OS from the big eMMC. As for getting experience - it is easy to gain it by cloning any current OS version to card ;-) There might still be some surprises caused by the performance differences between ext3 and ubifs, or between the OneNAND and the eMMC. For previous devices it felt faster when booted from card except some corner cases (frequent fsyncs in sqlite causing metalayer-crawler to take ages). For N900 the boot feels a bit slower but once system is booted I don't see much difference (with ext2) but it is too early to really tell. And BTW when OneNAND is free, in theory it could be used for swap (over ubi) causing less writes to eMMC when system is out of memory and already slow. Frantisek ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
ext Frantisek Dufka duf...@seznam.cz writes: It has not been implemented yet, and there is thus not much experience with running the whole OS from the big eMMC. As for getting experience - it is easy to gain it by cloning any current OS version to card ;-) Yes, we just haven't done that internally in any official way... There might still be some surprises caused by the performance differences between ext3 and ubifs, or between the OneNAND and the eMMC. For previous devices it felt faster when booted from card except some corner cases (frequent fsyncs in sqlite causing metalayer-crawler to take ages). Yes, fsyncs on ext3 (in Tracker and elsewhere) is what I am mostly worried about right now. People here have brought up the idea to have a small partition on the OneNAND specifically for database journals. Maybe mounted on /var/journals? And BTW when OneNAND is free, in theory it could be used for swap (over ubi) causing less writes to eMMC when system is out of memory and already slow. Yes, that's the plan. (Don't know the details of how swap will be put on a mtd, though, but I am confident that our kernel guys will dtrt.) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
ext Ed Bartosh bart...@gmail.com writes: I'll definitely find a time to do whatever is needed. Moreover, I was asking couple of times already if it's time to enable optification by default in autobuilder. I was given an answer that some testing is still needed. I think Marius should know the latest status. I still have to do something about the Python optification. I will do that in the next few days. The 'something' will likely be some way to detect the relevant packages and to stop optifying them in auto mode. (Indirect dependencies are a bit expensive to follow, so my current idea is that I go with a list of direct dependencies instead.) Also, I want to improve the heuristic and the official rules for optification together that using maemo-optify will automatically make your package conform to the rules. In other words, I want to avoid the situation where you need to do more than using maemo-optify to satisfy the QA criteria about optification. My current idea is that we will have a rule that takes in ratios: You need to have 20 times as many bytes (uncompressed) on the eMMC than on the OneNAND. The idea with this is that when all packages conform to this, your will most probably run out of eMMC before you run out of OneNAND. I'll try to do that in the next few days as well. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
Hi, a little patience please for the QA changes, as some remember we agreed in a couple of changes to the QA process that will improve it a lot, but due to other factors these changes aren't implemented yet, I'll try to push the process in the next few days. We also have a proposal of a team of testers, with some 'special powers' to avoid 'manipulation' of the QA system and to push apps that are stuck in a testing queue for a while, more on this soon. Best regards, -- Valério Valério http://www.valeriovalerio.org On Mon, Jan 4, 2010 at 12:11 PM, Marius Vollmer marius.voll...@nokia.comwrote: ext Ed Bartosh bart...@gmail.com writes: I'll definitely find a time to do whatever is needed. Moreover, I was asking couple of times already if it's time to enable optification by default in autobuilder. I was given an answer that some testing is still needed. I think Marius should know the latest status. I still have to do something about the Python optification. I will do that in the next few days. The 'something' will likely be some way to detect the relevant packages and to stop optifying them in auto mode. (Indirect dependencies are a bit expensive to follow, so my current idea is that I go with a list of direct dependencies instead.) Also, I want to improve the heuristic and the official rules for optification together that using maemo-optify will automatically make your package conform to the rules. In other words, I want to avoid the situation where you need to do more than using maemo-optify to satisfy the QA criteria about optification. My current idea is that we will have a rule that takes in ratios: You need to have 20 times as many bytes (uncompressed) on the eMMC than on the OneNAND. The idea with this is that when all packages conform to this, your will most probably run out of eMMC before you run out of OneNAND. I'll try to do that in the next few days as well. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Mon, Jan 4, 2010 at 8:11 AM, Marius Vollmer marius.voll...@nokia.com wrote: ext Ed Bartosh bart...@gmail.com writes: I'll definitely find a time to do whatever is needed. Moreover, I was asking couple of times already if it's time to enable optification by default in autobuilder. I was given an answer that some testing is still needed. I think Marius should know the latest status. I still have to do something about the Python optification. I will do that in the next few days. The 'something' will likely be some way to detect the relevant packages and to stop optifying them in auto mode. (Indirect dependencies are a bit expensive to follow, so my current idea is that I go with a list of direct dependencies instead.) Is maemo-optify-deb run on autobuilder inside the scratchbox target and after all dependencies have been installed? If so, checking whether pymaemo-optify is installed on the scratchbox target would be one heuristic to detect indirect dependencies, given that (theoretically) the scratchbox target is cleaned before each package build. Sample shell script snippet: if dpkg -s pymaemo-optify | grep -q not-installed; then echo pymaemo-optify is not installed else echo pymaemo-optify is installed fi This together with the direct dependency check (i.e. looking by pymaemo-optify or python or python2.5 on Depends) would make a good heuristic (in my opinion). This is just an idea, more testing is needed. Regards, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
ext Anderson Lizardo anderson.liza...@openbossa.org writes: Is maemo-optify-deb run on autobuilder inside the scratchbox target and after all dependencies have been installed? Yes. It is run after the package archives have been built and after pymaemo-optify has done its thing. So maybe it is best just to look for the effect that pymaemo-optify has. Maybe pymaemo-optify could even just echo none debian/optify... I'll have to have a closer look at how pymaemo-optify actually works... (We should also think about folding pymaemo-optify into maemo-optify completely, but that can be done later as well.) If so, checking whether pymaemo-optify is installed on the scratchbox target would be one heuristic to detect indirect dependencies, Yeah, I was thinking of that, too... Maybe it is indeed good enough. This together with the direct dependency check (i.e. looking by pymaemo-optify or python or python2.5 on Depends) would make a good heuristic (in my opinion). Well, the direct dependency check wouldn't do anything useful anymore, or would it? (I.e., has-dependency || pymaemo-optify-is-installed == pymaemo-optify-is-installed.) ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
Marius Vollmer marius.voll...@nokia.com writes: ext Anderson Lizardo anderson.liza...@openbossa.org writes: Is maemo-optify-deb run on autobuilder inside the scratchbox target and after all dependencies have been installed? Yes. It is run after the package archives have been built and after pymaemo-optify has done its thing. So maybe it is best just to look for the effect that pymaemo-optify has. Oi wei, sorry for the brain fart. I only now realize that pymaemo-optify works at run-time, not at build time... (We should also think about folding pymaemo-optify into maemo-optify completely, but that can be done later as well.) So forget about this, obviously. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Mon, Jan 4, 2010 at 15:16, Marius Vollmer marius.voll...@nokia.com wrote: Maybe pymaemo-optify could even just echo none debian/optify... I'll have to have a closer look at how pymaemo-optify actually works. pymaemo-optify is a runtime package which maintains the bind mounts used in Python. It is not involved in the build process. The reason I mention indirect dependency is that any package using Python (and ultimately pymaemo-optify) will have the file system already optified at runtime (i.e. /usr/lib/python2.5 is on the eMMC, without using symlinks). Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Mon, Jan 4, 2010 at 11:16 AM, Marius Vollmer marius.voll...@nokia.com wrote: ext Anderson Lizardo anderson.liza...@openbossa.org writes: Is maemo-optify-deb run on autobuilder inside the scratchbox target and after all dependencies have been installed? Yes. It is run after the package archives have been built and after pymaemo-optify has done its thing. So maybe it is best just to look for the effect that pymaemo-optify has. Maybe pymaemo-optify could even just echo none debian/optify... I'll have to have a closer look at how pymaemo-optify actually works... pymaemo-optify currently works on run-time (using the bind mount trick), so it does not modify any packages. Only python2.5 was changed to depend on pymaemo-optify, so it is guaranteed to be installed along with python applications. (We should also think about folding pymaemo-optify into maemo-optify completely, but that can be done later as well.) Given that pymaemo-optify currently does not manipulate the packages themselves, but works at low level by bind-mounting Python directories, I think the _current_ version cannot be merged with maemo-optify. This together with the direct dependency check (i.e. looking by pymaemo-optify or python or python2.5 on Depends) would make a good heuristic (in my opinion). Well, the direct dependency check wouldn't do anything useful anymore, or would it? (I.e., has-dependency || pymaemo-optify-is-installed == pymaemo-optify-is-installed.) Yes, having pymaemo-optify installed after .deb's have been created would be a indication of that package depending (directly or indirectly) on some Python package during build. But it does not guarantee the package which maemo-deb-optify is running on actually depends on python during runtime. But I agree having just one heuristic would be better (IMHO), others could be added if/where necessary. My two cents, -- Anderson Lizardo OpenBossa Labs - INdT Manaus - Brazil ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Automatic optification (was: Re: Proposal: Karma-Whores protection mailing list)
On Monday 04 January 2010 12:11:46 Marius Vollmer wrote: ext Ed Bartosh bart...@gmail.com writes: I'll definitely find a time to do whatever is needed. Moreover, I was asking couple of times already if it's time to enable optification by default in autobuilder. I was given an answer that some testing is still needed. I think Marius should know the latest status. I still have to do something about the Python optification. I will do that in the next few days. Thanks. We really need this in order to turn on optification by default. The 'something' will likely be some way to detect the relevant packages and to stop optifying them in auto mode. (Indirect dependencies are a bit expensive to follow, so my current idea is that I go with a list of direct dependencies instead.) The sooner we can try it, the sooner we can find out if it works! My current idea is that we will have a rule that takes in ratios: You need to have 20 times as many bytes (uncompressed) on the eMMC than on the OneNAND. The idea with this is that when all packages conform to this, your will most probably run out of eMMC before you run out of OneNAND. Can you explain that in more detail? Do you mean that you will optify (move) smaller and smaller files until you get to the right ratio and then stop? What if you can't get to the right ratio -- is that a failure? Are you still planning to allow the developer to override decisions? Do we actually need that level of complexity? I really don't like the idea of the optification changing between releases just because one file has changed size -- for example, I wouldn't want the developer to find that one of their files (e.g. a binary) has suddenly been moved because a different file (e.g. a text file) has changed size. That is asking for creating unexpected bugs. I would prefer to keep the algorithm the same as we have now, as we have got some experience with that, and turn on automatic optification with that algorithm. We can look at improving it in the future but otherwise it will be another 6 months before we are ready to turn on automatic optification! The best is the enemy of the good! Graham ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Sat, 2 Jan 2010, Jeff Moe wrote: On Saturday 02 January 2010 17:54:46 Andrew Flegg wrote: For the record, you don't even need to do that now. All you need to do is opt-in to the autobuilder doing optification for you, by putting the single word 'auto' in a new file: debian/optify. At some point the default will change from 'none' to 'auto', and then you can opt-out by putting the single word 'none' in debian/optify. I hope that day comes soon with optify is the default... Can it be today? What is needed to make that change? What do you mean optify is the default? optification is a temporary hack, and it is being replaced by a real solution as soon as possible. See the last line of this message: http://www.mail-archive.com/maemo-developers@maemo.org/msg20401.html -- Matan Ziv-Av. ma...@svgalib.org ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
Mustali Dalal wrote: Till, It is obvious that your angst is against my thumbs-down to your app due to my perceived understanding of optification which is at odds with yours. I take testing seriously and do this as a way of giving back to the open-source community. Thanks I am a developer too; but still on the maemo-developer learning curve. The experience with rating your app is not something I would consider a high-point of maemo. So long as you take it as an outlier :) David -- Don't worry, you'll be fine; I saw it work in a cartoon once... ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
Hi, Am Samstag 02 Januar 2010 schrieb Jeff Moe: What's the advantage in delaying the optification? It is soo easy. A The disadvantages: Another round of testing on my side for all three plattforms. Making sure that all features in that version are usable, so i can't just take the current svn which includes half-done features. Loosing existing thumbs-up. The users won't be able to start the optified binary from the command line anymore. Etc etc ... whopping 4 bytes or so. It sounds like your app shouldn't have made it to extras in the first place if it wasn't optified. It _is_ optified and uses ~280k of rootfs space for the binary itself. Just optify and let this die finally. Will happen with the next release once all features currently pending are done. Until then the broken version stays in extras (e.g. crashes if you try to view the relations of a relation and the WMS feature is barely usable due to an offset error). Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Sun, Jan 3, 2010 at 10:56, Matan Ziv-Av ma...@svgalib.org wrote: What do you mean optify is the default? optification is a temporary hack, and it is being replaced by a real solution as soon as possible. I'll put money on it being a temporary hack for the lifetime of Fremantle; hence the Fremantle auto-builder running `maemo-optify-deb --auto'. Indeed, it's temporary nature means that as much as possible should be automated. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Saturday 02 January 2010 20:33:56 Till Harbaum / Lists wrote: What do you think? I really think it's wrong that testers can stop bad developers, but that there's no way for developers to stop bad testers. That's why I suggested a while back on various places that maybe there should be QA moderator(s) (QAmaster if you wish) who could follow up on tester's results (this would also help the interpretative nature of QA rules). Personally, I think a thumbs down should be valid only if there is an *accepted* bug report accompanying it (alas, not quite feasible with the current setup), as it's kind of silly to have 5 thumb-downs for the same (maybe invalid, or not as important) issue and thus block the whole release altogether. Regards, Attila ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
2010/1/2 Till Harbaum / Lists li...@harbaum.org: Hi, Am Samstag 02 Januar 2010 schrieb Jeff Moe: Does this, perchance, have anything to do with what you are talking about? http://maemo.org/packages/package_instance/view/fremantle_extras- testing_free_armel/osm2go/0.8.1-maemo1 Sure I must say he annoyed me to at first, but make my silly package better for in in the end. Seems if you just freaking optified your binary all these threads could die. Just to make this clear: I WILL do this particular optification. But this will take some time as i am also doing other changes. And any bug i fixed in that version is now delayed. I am annoyed by the fact that my bug fixes are delayed for something the version already in extras also has. Where's the advantage in delaying the update? Btw. one easy way to optify ./usr/bin/osm2go is to add --bindir=/opt/osm2go/bin to the 'configure' line from debian/rules and adjust the 'Exec' fields in osm2go.desktop (and .service file, which I didn't find in this package). So no symlink required but of course one needs to specify the full path when executed from the terminal. ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Jan 2, 2010, at 21:54, Andrew Flegg wrote: On Sat, Jan 2, 2010 at 20:47, Micke Nordin mickew...@gmail.com wrote: Am I missing something? Doesn't optification basicaly mean that all you have to do is install a binary in your SDK and then you have to add a single line to the rulesfile? For the record, you don't even need to do that now. All you need to do is opt-in to the autobuilder doing optification for you, by putting the single word 'auto' in a new file: debian/optify. To stay abreast of these changes it would be great if we had a canonical document about this so that we could move information from the wiki to the Packaging pdf for example. Where does that canonical document reside now? For example, I see nothing in the current packaging document: http://wiki.maemo.org/Documentation/Maemo_5_Developer_Guide/Packaging,_Deploying_and_Distributing I am happy to add information there from disparate sources but if there is already a canonical source I'll copy that. Jeremiah ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Sun, Jan 3, 2010 at 15:39, Jeremiah Foster jerem...@jeremiahfoster.com wrote: On Jan 2, 2010, at 21:54, Andrew Flegg wrote: For the record, you don't even need to do that now. All you need to do is opt-in to the autobuilder doing optification for you, by putting the single word 'auto' in a new file: debian/optify. To stay abreast of these changes it would be great if we had a canonical document about this [...] Agreed. Someone needs to take ownership not just of the technical changes (which have been coordinated between Ed Marius so far, AFAICT) but also the communication and education of developers. I am happy to add information there from disparate sources but if there is already a canonical source I'll copy that. I'm not aware of any documentation - nor what Ed Marius' current timescales are. Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
2010/1/3 Andrew Flegg and...@bleb.org: On Sun, Jan 3, 2010 at 15:39, Jeremiah Foster jerem...@jeremiahfoster.com wrote: On Jan 2, 2010, at 21:54, Andrew Flegg wrote: For the record, you don't even need to do that now. All you need to do is opt-in to the autobuilder doing optification for you, by putting the single word 'auto' in a new file: debian/optify. To stay abreast of these changes it would be great if we had a canonical document about this [...] Agreed. Someone needs to take ownership not just of the technical changes (which have been coordinated between Ed Marius so far, AFAICT) but also the communication and education of developers. I am happy to add information there from disparate sources but if there is already a canonical source I'll copy that. I'm not aware of any documentation - nor what Ed Marius' current timescales are. I'll definitely find a time to do whatever is needed. Moreover, I was asking couple of times already if it's time to enable optification by default in autobuilder. I was given an answer that some testing is still needed. I think Marius should know the latest status. PS: Last news about optification for me was a discusstion about python maemo-optify [1] last month. [1] http://lists.maemo.org/pipermail/maemo-developers/2009-December/022782.html -- BR, Ed ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Proposal: Karma-Whores protection mailing list
Hi, it seems that some of the extras-testing testers are not really doing a good job. Thus it seems to happen every now and then that some app gets a thumbs down for things it shouldn't be getting a thumbs down for or where such a verdict is at least questionable. My proposal is simple: Let's setup some mailing list which only real developers are allowed to join (may just be everybody with a working app in any of the repositories). And once someone thinks to be the victim of a karma-whore he may ask for help on that list. If we have at least 10 people on such a list we can easily override any such thumb down. In such a case the developer would explain why he thinks the thumb down is not justified and if enough list members agree and help out the problem will be fixed. Does garage allow for invitation-only mailing lists? What do you think? I really think it's wrong that testers can stop bad developers, but that there's no way for developers to stop bad testers. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Saturday 02 January 2010 16:33:56 Till Harbaum / Lists wrote: Hi, it seems that some of the extras-testing testers are not really doing a good job. Thus it seems to happen every now and then that some app gets a thumbs down for things it shouldn't be getting a thumbs down for or where such a verdict is at least questionable. My proposal is simple: Let's setup some mailing list which only real developers are allowed to join (may just be everybody with a working app in any of the repositories). And once someone thinks to be the victim of a karma-whore he may ask for help on that list. If we have at least 10 people on such a list we can easily override any such thumb down. In such a case the developer would explain why he thinks the thumb down is not justified and if enough list members agree and help out the problem will be fixed. Does garage allow for invitation-only mailing lists? What do you think? I really think it's wrong that testers can stop bad developers, but that there's no way for developers to stop bad testers. Closed lists are bad and only cause trouble and bad feelings. How about just bringing up particular cases to this list where you think there was an inappropriate thumbs down and it can be sorted here? It's not happening that often, is it? Any examples? -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Sat, Jan 2, 2010 at 7:33 PM, Till Harbaum / Lists li...@harbaum.orgwrote: Hi, it seems that some of the extras-testing testers are not really doing a good job. Thus it seems to happen every now and then that some app gets a thumbs down for things it shouldn't be getting a thumbs down for or where such a verdict is at least questionable. usually what you or I may think is unjustified matters to people. i My proposal is simple: Let's setup some mailing list which only real developers are allowed to join (may just be everybody with a working app in any of the repositories). And once someone thinks to be the victim of a karma-whore he may ask for help on that list. If we have at least 10 people on such a list we can easily override any such thumb down. In such a case the developer would explain why he thinks the thumb down is not justified and if enough list members agree and help out the problem will be fixed. the voice of the commons is generally to be listened to. we put our apps into the community, our apps are going on their devices, why should we have more say than them? a cabal of rebels overruling usually valid issues undermines the process for everyone. i have not updated any apps since finding out I also have to handle optification and other issues. i'm not upset at the mechanism though. Does garage allow for invitation-only mailing lists? not sure What do you think? I really think it's wrong that testers can stop bad developers, but that there's no way for developers to stop bad testers. that sounds like a freudian slip, its right that testers can stop bad developers. Till till, I know you are miffed about this process, we all have growing pains with the new steps, but we want all our users to have the best experience possible gary ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Saturday 02 January 2010 16:33:56 Till Harbaum / Lists wrote: Hi, it seems that some of the extras-testing testers are not really doing a good job. Thus it seems to happen every now and then that some app gets a thumbs down for things it shouldn't be getting a thumbs down for or where such a verdict is at least questionable. My proposal is simple: Let's setup some mailing list which only real developers are allowed to join (may just be everybody with a working app in any of the repositories). And once someone thinks to be the victim of a karma-whore he may ask for help on that list. If we have at least 10 people on such a list we can easily override any such thumb down. In such a case the developer would explain why he thinks the thumb down is not justified and if enough list members agree and help out the problem will be fixed. Does garage allow for invitation-only mailing lists? What do you think? I really think it's wrong that testers can stop bad developers, but that there's no way for developers to stop bad testers. Does this, perchance, have anything to do with what you are talking about? http://maemo.org/packages/package_instance/view/fremantle_extras- testing_free_armel/osm2go/0.8.1-maemo1 I must say he annoyed me to at first, but make my silly package better for in in the end. Seems if you just freaking optified your binary all these threads could die. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
Hi, Am Samstag 02 Januar 2010 schrieb Gary Birkett: the voice of the commons is generally to be listened to. Listening to them is fine. we put our apps into the community, our apps are going on their devices, why should we have more say than them? I don't propose that we need to have more to say then them. I just ask certain people to give their vote. This is how all elections work: You ask those people to vote who you think have the right understanding. I am asking developers since i trust them more than someone doing those tests to get enough karma to get the next-gen device for free. a cabal of rebels overruling usually valid issues undermines the process for everyone. Why are developers rebels? I am not asking those people to give a thumbs up for just everything. I ask them to reconsider and override the vote of someone who perhaps doesn't have enough knowledge of the things he's judging upon. i have not updated any apps since finding out I also have to handle optification and other issues. i'm not upset at the mechanism though. I am not sure i understand that. You gave up. Is that right? If this i fine for you: Good. But what if you could actually convince these lists members that indeed your app is a win and that e.g. in your case optification isn't useful? Why not giving you a place/group to explain your technical reasoning behind your work? What do you think? I really think it's wrong that testers can stop bad developers, but that there's no way for developers to stop bad testers. that sounds like a freudian slip, its right that testers can stop bad developers. Perhaps i wasn't clear. I meant: It's good that there's a mechanism to stop bad developers. But it's bad that you can't stop bad testers. till, I know you are miffed about this process, we all have growing pains with the new steps, but we want all our users to have the best experience possible So do i. Preventing bug-fixes from reaching extras due to issues the version already in extras also has is e.g. useless. You gain nothing if there already is a version in extras which has this flaw that's causing the update to be delayed. I am willing to learn: What's the disadvantage of uploading a new version that isn't perfect but better than the previous version? Once a program is in extras the rules what's good and bad just change. Everything better than the previous version should be good. Or what am i missing? Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
Hi, Am Samstag 02 Januar 2010 schrieb Jeff Moe: Does this, perchance, have anything to do with what you are talking about? http://maemo.org/packages/package_instance/view/fremantle_extras- testing_free_armel/osm2go/0.8.1-maemo1 Sure I must say he annoyed me to at first, but make my silly package better for in in the end. Seems if you just freaking optified your binary all these threads could die. Just to make this clear: I WILL do this particular optification. But this will take some time as i am also doing other changes. And any bug i fixed in that version is now delayed. I am annoyed by the fact that my bug fixes are delayed for something the version already in extras also has. Where's the advantage in delaying the update? Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
- Ursprungsmeddelande iSeems if you just freaking optified your binary all these threads could die. Just to make this clear: I WILL do this particular optification. But this will take some time as i am also doing other changes. And any bug i fixed in that version is now delayed. Am I missing something? Doesn't optification basicaly mean that all you have to do is install a binary in your SDK and then you have to add a single line to the rulesfile? /Micke ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Sat, Jan 2, 2010 at 20:47, Micke Nordin mickew...@gmail.com wrote: Am I missing something? Doesn't optification basicaly mean that all you have to do is install a binary in your SDK and then you have to add a single line to the rulesfile? For the record, you don't even need to do that now. All you need to do is opt-in to the autobuilder doing optification for you, by putting the single word 'auto' in a new file: debian/optify. At some point the default will change from 'none' to 'auto', and then you can opt-out by putting the single word 'none' in debian/optify. HTH, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Saturday 02 January 2010 17:54:46 Andrew Flegg wrote: For the record, you don't even need to do that now. All you need to do is opt-in to the autobuilder doing optification for you, by putting the single word 'auto' in a new file: debian/optify. At some point the default will change from 'none' to 'auto', and then you can opt-out by putting the single word 'none' in debian/optify. I hope that day comes soon with optify is the default... Can it be today? What is needed to make that change? Then people will have to explain why they are opting out of optifying instead of coming up with excuses of why they won't optify. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Saturday 02 January 2010 17:23:24 Till Harbaum / Lists wrote: Hi, Am Samstag 02 Januar 2010 schrieb Jeff Moe: Does this, perchance, have anything to do with what you are talking about? http://maemo.org/packages/package_instance/view/fremantle_extras- testing_free_armel/osm2go/0.8.1-maemo1 Sure I must say he annoyed me to at first, but make my silly package better for in in the end. Seems if you just freaking optified your binary all these threads could die. Just to make this clear: I WILL do this particular optification. But this will take some time as i am also doing other changes. And any bug i fixed in that version is now delayed. I am annoyed by the fact that my bug fixes are delayed for something the version already in extras also has. Where's the advantage in delaying the update? What's the advantage in delaying the optification? It is soo easy. A whopping 4 bytes or so. It sounds like your app shouldn't have made it to extras in the first place if it wasn't optified. Just optify and let this die finally. -Jeff ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
On Sat, Jan 2, 2010 at 21:53, Jeff Moe m...@blagblagblag.org wrote: On Saturday 02 January 2010 17:54:46 Andrew Flegg wrote: At some point the default will change from 'none' to 'auto', and then you can opt-out by putting the single word 'none' in debian/optify. I hope that day comes soon with optify is the default... Can it be today? What is needed to make that change? What's needed is more testing of it being done as part of the build process and a review of the heuristics using by maemo-optify-deb (if nothing else, any instance of pymaemo-optify in the dependency graph should prevent optification in 'auto' mode - that's the big one I think is still missing). Apart from clear communication, I imagine at some point it'll need some co-ordination between Ed, Marius, Niels and Jeremiah to try a test-run of everything currently built - perhaps into a test repo which brave volunteers can try. I think, at this point, there aren't any known blocking problems with the process so it's just taking that brave step. If everything goes well, everything gets rebuilt in extras-devel ( -testing?) with the default changed. CCing Graham as one of the council members who was in the meeting at the summit where this roadmap was laid out for his comment and ownership ;-) Cheers, Andrew -- Andrew Flegg -- mailto:and...@bleb.org | http://www.bleb.org/ ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
Re: Proposal: Karma-Whores protection mailing list
Till, It is obvious that your angst is against my thumbs-down to your app due to my perceived understanding of optification which is at odds with yours. Nevertheless, resorting to epithets is just lame. If you have other gripes, mention specific cases where there has been gross lapse in testing that have violated the published guidelines. This will help in addressing the issues and misunderstandings. We are all in it to see maemo succeed. I take testing seriously and do this as a way of giving back to the open-source community. your desire to make fixes quickly available to the users is understandable. The way you put things, it sounds like since the first time you didn't have any problems, why should you have them now. Well, I didn't test the app the first time and even if I did, it would have gotten the same thumbs-down. If there are more users who don't care, which actually happened with libzlibrary in Fbreader, the app will end up in Extras with the opt violation. Of course, your app is not large but who knows, in the future it might be. optification is good practice. I am a developer too; but still on the maemo-developer learning curve. The experience with rating your app is not something I would consider a high-point of maemo. Mustali On Sat, Jan 2, 2010 at 7:33 PM, Till Harbaum / Lists li...@harbaum.orgwrote: Hi, it seems that some of the extras-testing testers are not really doing a good job. Thus it seems to happen every now and then that some app gets a thumbs down for things it shouldn't be getting a thumbs down for or where such a verdict is at least questionable. My proposal is simple: Let's setup some mailing list which only real developers are allowed to join (may just be everybody with a working app in any of the repositories). And once someone thinks to be the victim of a karma-whore he may ask for help on that list. If we have at least 10 people on such a list we can easily override any such thumb down. In such a case the developer would explain why he thinks the thumb down is not justified and if enough list members agree and help out the problem will be fixed. Does garage allow for invitation-only mailing lists? What do you think? I really think it's wrong that testers can stop bad developers, but that there's no way for developers to stop bad testers. Till ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers ___ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
