Active Topics
-
Install Fonts in N900 (67)
to Maemo 5 / Fremantle by panjgoori - 7 hrs, 47 mins ago -
Nokia Booklet 3G (RX-75) Drivers (60)
to Alternatives by Maemish - 4 days, 14 hrs ago - more...
hqh |
2010-03-11
, 21:14
|
|
Posts: 388 |
Thanked: 842 times |
Joined on Sep 2009
@ Finland
|
#21
|
Originally Posted by benny1967
I fully agree, I was just about to write a post about the same subject. Going directly to "enter new bug" -page really doesn't encourage users to do a search first...
 |
|
2010-03-11
, 22:44
|
|
Posts: 1,070 |
Thanked: 1,604 times |
Joined on Sep 2008
@ Helsinki
|
#22
|
Originally Posted by qole
Yes, there's a bug there, I can reproduce that behavior with your packages and with others as well.
Ok, I think there's a bug here, which is quite ironic. I'm still getting reports that my bugtracker link is broken, and I think it is because the packages interface is pulling that field semi-randomly from various versions of the package, depending on factors I have yet to fathom.
For instance, earlier this morning the package overview page was showing the old broken bugtracker field, and now it is showing the correct one.
...And I just did a refresh of that page, and it is showing the broken link again!
ARGH.
EDIT: It is doing the same thing on the package instance page, too. Randomly pulling the description and bugtracker fields (but not changelog, interestingly) from old versions of the package, or the current version, depending on the whims of The Machine.
Did you filled a bug report ?
 |
|
2010-03-11
, 23:17
|
|
Moderator |
Posts: 7,109 |
Thanked: 8,820 times |
Joined on Oct 2007
@ Vancouver, BC, Canada
|
#23
|
Originally Posted by VDVsx
Did you filled a bug report ?
I hate filing bug reports... Thankfully, I think it is this one: Bug 8694
__________________
qole.org --- twitter --- Easy Debian wiki page
Please don't send me a private message, post to the appropriate thread.
Thank you all for your donations!
qole.org --- twitter --- Easy Debian wiki page
Please don't send me a private message, post to the appropriate thread.
Thank you all for your donations!
| The Following 3 Users Say Thank You to qole For This Useful Post: | ||
 |
|
2010-03-11
, 23:50
|
|
Posts: 754 |
Thanked: 630 times |
Joined on Sep 2009
@ London
|
#24
|
maybe slightly offtopic,sorry for that.
But ive been carrying some the thoughts for past few days and just found an opportunity to share and discuss if relevant.
Is there a way to "thumbs up" a "thumbs down" if a QA person realizes that the problem is resolved/invalid ?
Also just as we can track a thumbs down by raising a bug(if bugzilla is mandated in the future though I dont think this is happening at the moment even for packages with a bugtracker link now ) there should also be a way to track it to completion by the QA/Dev who raised/resolved it. Like DEV assigning back the bug to QA with a resolution so the "thumbs down" can either be removed or toggled to "thumbs up". ( manually or auto )
Basically trying to ensure a package doesnt get a "thumbs down" if somebody just feels it does not meet the criteria ( which may be correct/incorrect) and then carry on and may never revisit.
Keeping a framwework to resolve every reported problem on a package is needed IMHO.
If the bug isnt resolved by DEV, and the package gets to extras ( with 10 votes including enough "core" QA votes ) the bugs list may be published as part of release notes, there can be many other actions that can be discussed also.
That also raises another already raised issue about transfer of existing votes to a "new" version of the package that may fix bugs reported.
feel free to dismiss as non-relevant
But ive been carrying some the thoughts for past few days and just found an opportunity to share and discuss if relevant.
Is there a way to "thumbs up" a "thumbs down" if a QA person realizes that the problem is resolved/invalid ?
Also just as we can track a thumbs down by raising a bug(if bugzilla is mandated in the future though I dont think this is happening at the moment even for packages with a bugtracker link now ) there should also be a way to track it to completion by the QA/Dev who raised/resolved it. Like DEV assigning back the bug to QA with a resolution so the "thumbs down" can either be removed or toggled to "thumbs up". ( manually or auto )
Basically trying to ensure a package doesnt get a "thumbs down" if somebody just feels it does not meet the criteria ( which may be correct/incorrect) and then carry on and may never revisit.
Keeping a framwework to resolve every reported problem on a package is needed IMHO.
If the bug isnt resolved by DEV, and the package gets to extras ( with 10 votes including enough "core" QA votes ) the bugs list may be published as part of release notes, there can be many other actions that can be discussed also.
That also raises another already raised issue about transfer of existing votes to a "new" version of the package that may fix bugs reported.
feel free to dismiss as non-relevant
__________________
Developer of :
Buddy - budget/expense manager ( website )
Showtime - a telly channel listing viewer/reminder ( website )
Travelapp - london underground status/planner ( website )
Batlevel - desktop widget for battery level ( website )
“I hear and I forget. I see and I remember. I do and I understand.”
Developer of :
Buddy - budget/expense manager ( website )
Showtime - a telly channel listing viewer/reminder ( website )
Travelapp - london underground status/planner ( website )
Batlevel - desktop widget for battery level ( website )
“I hear and I forget. I see and I remember. I do and I understand.”
|
|
2010-03-11
, 23:57
|
|
Posts: 1,070 |
Thanked: 1,604 times |
Joined on Sep 2008
@ Helsinki
|
#25
|
Originally Posted by krk969
Currently only the voter can do that.
maybe slightly offtopic,sorry for that.
But ive been carrying some the thoughts for past few days and just found an opportunity to share and discuss if relevant.
Is there a way to "thumbs up" a "thumbs down" if a QA person realizes that the problem is resolved/invalid ?
| The Following User Says Thank You to VDVsx For This Useful Post: | ||
 |
|
2010-03-12
, 00:22
|
|
Posts: 3,203 |
Thanked: 1,391 times |
Joined on Nov 2009
@ Worthing, England
|
#26
|
Originally Posted by VDVsx
might make sense that by voting, the person then allows admin or maintainer emails for updates?
Currently only the voter can do that.
In some cases it could be well voted up, but a critical bug is located at the last minute and the maintainer wants it voted down too?
__________________
----------- Follow me on Twitter here
----------- My Photography Website and Blog is here
----------- Author of the N900 Health Check Application ----------- New Version in Extras Devel (Dec 2010 - 2.9.10)
----------- Are you on the N900 World Map? - http://pininthemap.com/maemo - masterpin: shotgun
----------- What apps do you want to see on the n900 or in MeeGo in the future? -
----------- Follow me on Twitter here
----------- My Photography Website and Blog is here
----------- Author of the N900 Health Check Application ----------- New Version in Extras Devel (Dec 2010 - 2.9.10)
----------- Are you on the N900 World Map? - http://pininthemap.com/maemo - masterpin: shotgun
----------- What apps do you want to see on the n900 or in MeeGo in the future? -
|
|
2010-03-19
, 13:54
|
|
Posts: 3,319 |
Thanked: 5,610 times |
Joined on Aug 2008
@ Finland
|
#27
|
X-posted from the -dev list... thoughts welcome
In retrospect, I think that the mailto scheme is actually the correct one and
that the 'historical' plain mail address is the one more likely to cause
trouble in the future. Let me elaborate: if we use automatic
tools/applications (extras-assistant, appwatch, something based on texrat's
framework, you name it), defining an URL there is the right thing to do: if
it's a mailto: scheme, the browser will open the mail client, so it will work.
With putting simple mail addresses in there, any potential automated client
(including the maemo.org interface) will have to make this analysis whether
the giver string is a mail address, whether it's correct, etc, etc. I'm
inclined to say the bugtracker should be a proper URL (whether http or mailto
doesn't matter as long as it can be automatically handled with a browser). The
maemo.org interface will have to take this into account either way. Of course,
should we reach an agreement of such a change, we should probably send out a
notification mail to all package maintainers using the 'old' scheme in the
bugtracker fields (not that difficult to find with grep). Comments welcome.
XSBC-Bugtracker: mailto:x@y.net
that the 'historical' plain mail address is the one more likely to cause
trouble in the future. Let me elaborate: if we use automatic
tools/applications (extras-assistant, appwatch, something based on texrat's
framework, you name it), defining an URL there is the right thing to do: if
it's a mailto: scheme, the browser will open the mail client, so it will work.
With putting simple mail addresses in there, any potential automated client
(including the maemo.org interface) will have to make this analysis whether
the giver string is a mail address, whether it's correct, etc, etc. I'm
inclined to say the bugtracker should be a proper URL (whether http or mailto
doesn't matter as long as it can be automatically handled with a browser). The
maemo.org interface will have to take this into account either way. Of course,
should we reach an agreement of such a change, we should probably send out a
notification mail to all package maintainers using the 'old' scheme in the
bugtracker fields (not that difficult to find with grep). Comments welcome.
__________________
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
Blogging about mobile linux - The Penguin Moves!
Maintainer of PyQt (see introduction and docs), AppWatch, QuickBrownFox, etc
| The Following 3 Users Say Thank You to attila77 For This Useful Post: | ||
 |
|
2010-03-19
, 14:04
|
|
Posts: 11,700 |
Thanked: 10,045 times |
Joined on Jun 2006
@ North Texas, USA
|
#28
|
attila77, that makes perfect sense (and thanks for the nod).
IMO we need to design with automation in mind, even if that automation isn't available, currently practical, etc. Designing around manual methods and then trying to slap on automation creates a nighmare for the poor guys doing that work (been there done that). On the other hand, if we consider an automated solution as we design the process and incorporate the right hooks, it can still be done manually, easily, and is ready if/when automation layers can be added.
Last edited by Texrat; 2010-03-19 at 14:08.
IMO we need to design with automation in mind, even if that automation isn't available, currently practical, etc. Designing around manual methods and then trying to slap on automation creates a nighmare for the poor guys doing that work (been there done that). On the other hand, if we consider an automated solution as we design the process and incorporate the right hooks, it can still be done manually, easily, and is ready if/when automation layers can be added.
__________________
Nokia Developer Champion
Different <> Wrong | Listen - Judgment = Progress | People + Trust = Success
My personal site: http://texrat.net
Nokia Developer Champion
Different <> Wrong | Listen - Judgment = Progress | People + Trust = Success
My personal site: http://texrat.net
Last edited by Texrat; 2010-03-19 at 14:08.
| The Following User Says Thank You to Texrat For This Useful Post: | ||