On Monday 08 March 2010 15:21:13 Benoît HERVIER wrote: > - There is change in rules that happen frequently which seems to > depends on phase of the moon.
Of course there have been changes in the early days as everyone learns from experience. That is part of the fun as well as the challenge of being in on the birth of a new device. Things should be pretty stable now. I remind the testers that any changes to the rules MUST be discussed on -community -- it is the community that defines the rules, not the testing team. > - There is latency in the display things in the maemo.org/packages/ > interface which result of thumb down. Example : Last time i change the > bugtracker link this one was ok in the package but it tooks 3 hours > for this one to be displayed correctly in the web interface -> Result > > : thumb down and comment saying that the bug tracker link is wrong ... In my experience it is very rare to get any comment in the first few hours after promotion! If this happens, just add a comment explaining how the first tester was confused by the web problem. And, of course, this will not happen for all your later updates (nor if you had included the bugtracker in the first release -- it has been a requirement for a long time!). > - Sometimes package is never displayed to the package web interface > .... so cannot promote it. > > - Sometimes promote package result is an php error, which mean that > the package will be not promoted and cannot be anymore without > publishing an other version and try again. > > - Sometimes icon display on the newest package is taken from an older one. > > - Sometimes changelog displayed on the armel version is taken from the > i386 package (occur only when the armel package version of an app is > newer than the i386 one) Make sure bugs are reported. If you have passed testing and cannot promote then I am sure Niels will help. > - I'm not agree with some QA rules, like the fact that you should > point as bug tracker the enter_new.php page so you do not let user > made a search before or display the current know bug, so it ll result > in duplicate bugs. I would also agree that that is a ridiculous requirement. Such a requirement has never been proposed to the -community list so I am sure it is not a requirement. The requirement is for a link for users to use for submitting bugs: no more, no less. Any advice from the testing team on how to do that is advice, not requirement. > - It s look like some users are here just to put thumb down just to > gain some karma. If there are specific comments which are wrong, raise them. > Also about bugzilla : > > - Creating a nice user interface to help user to automatically put > bugs directly on the tracker from their nit is not possible ... as > b.m.o use bugzilla and i cannot modify it to accept creation of new > bug from elsewhere than the ui. > > - Submitting bugs require a lot of patience actually, as i take > several minutes to validate it (servers too slow ?) . > > - Asking a new product or version in b.m.o require delay, as it s not > something automated, but require you to send an email. If you don't like bugzilla, you are welcome to set up and use an alternative bug reporting facility. That would be much less damaging to both you and the community than setting up your own repository. > And the most important things which guide my decision, is that > currently, many thumb down make me angry as there was wrong vote, and > the fact that i m passing more time to package than to develop didn't > help. If the votes are wrong, complain. If they are not, then fix them. Don't split the user's experience. Why do you think the answer is to make every user take more time to find your application than it took you to develop it? Testing, QA and publishing is part of the task of packaging an app -- I don't see any way around that. There are no requirements that the app looks pretty, works intuitively, does anything useful or is approved by Nokia or the operators. All the process is trying to do is to make sure apps don't crash, don't break the user's device, that the user understands what he is getting, and that he has someone to contact in case of problems. > Actually i'm just trying to found the best solution, but i think in a > near future i ll not publish anythings anymore to "extras". Feel free to propose improvements to the process. > 2010/3/8 Matan Ziv-Av <ma...@svgalib.org>: > > Why not have another repository (called extras-authors), describe it as > > repository of programs that their authors think are good enough for > > users, and allow authors sole discretion on promoting their packages from > > extras-devel to extras-authors. As long as the name is neutral, and the > > wiki/forum/mail-list are not full of warnings in size 72 blinking red > > letters that this repository certainly without any doubt will destroy > > your device, I am sure most of those who have seperate repositories will > > prefer to use such repository. I know that I will. > > After all, this is how extras repository worked in chinook/diablo, and I > > think it worked very well. This is really the point of Extras. The QA process is supposed to be lightweight and just to verify that the apps don't "damage" anything (i.e. crash, use battery, etc.). Descriptions and bug trackers are also a reasonable part of the minimal test. Graham _______________________________________________ maemo-developers mailing list maemo-developers@maemo.org https://lists.maemo.org/mailman/listinfo/maemo-developers
