maemo.org - Talk - Validity criteria for bugtrackers and bugtrackers links

maemo.org - Talk (https://talk.maemo.org/index.php)

- Community (https://talk.maemo.org/forumdisplay.php?f=16)

- - Validity criteria for bugtrackers and bugtrackers links (https://talk.maemo.org/showthread.php?t=46844)

Re: Validity criteria for bugtrackers and bugtrackers links

Quote:

Originally Posted by benny1967 (Post 564301)

The Moblin bugzilla (and maybe others) has an interesting feature: It has a "file new bug for <product>" link at the end of a page when you search for bugs in <product>. If a developer wants to make sure that users actually read existing bugs reports before filing new ones, linking directly to the query (=the search results) in the bugtracker field wouldn't, IMHO, not only be acceptable, but even better than directly linking to the "enter new bug" form.

what's your opinion?

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

Re: Validity criteria for bugtrackers and bugtrackers links

Quote:

Originally Posted by qole (Post 564239)

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.

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 ?

Re: Validity criteria for bugtrackers and bugtrackers links

Quote:

Originally Posted by VDVsx (Post 564399)

Did you filled a bug report ?

:( I hate filing bug reports...

Thankfully, I think it is this one: Bug 8694

Re: Validity criteria for bugtrackers and bugtrackers links

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 :)

Re: Validity criteria for bugtrackers and bugtrackers links

Quote:

Originally Posted by krk969 (Post 564468)

Currently only the voter can do that.

Re: Validity criteria for bugtrackers and bugtrackers links

Quote:

Originally Posted by VDVsx (Post 564476)

Currently only the voter can do that.

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?

Re: Validity criteria for bugtrackers and bugtrackers links

X-posted from the -dev list... thoughts welcome

Quote:

XSBC-Bugtracker: mailto:x@y.net

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.

Re: Validity criteria for bugtrackers and bugtrackers links

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.