hqh | # 21 | 2010-03-11, 21:14 | Report

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...

VDVsx | # 22 | 2010-03-11, 22:44 | Report

Yes, there's a bug there, I can reproduce that behavior with your packages and with others as well.

Did you filled a bug report ?

qole | # 23 | 2010-03-11, 23:17 | Report

I hate filing bug reports...

Thankfully, I think it is this one: Bug 8694

krk969 | # 24 | 2010-03-11, 23:50 | Report

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

VDVsx | # 25 | 2010-03-11, 23:57 | Report

Currently only the voter can do that.

noobmonkey | # 26 | 2010-03-12, 00:22 | Report

might make sense that by voting, the person then allows admin or maintainer emails for updates?

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?

attila77 | # 27 | 2010-03-19, 13:54 | Report

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.

Texrat | # 28 | 2010-03-19, 14:04 | Report

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.