Fate vs Bugzilla for feature tracking
Aaron J. Seigo
aseigo at kde.org
Fri Jan 23 22:04:38 GMT 2009
On Friday 23 January 2009, Ingo Klöcker wrote:
> On Friday 23 January 2009, Aaron J. Seigo wrote:
> > On Friday 23 January 2009, Michael Leupold wrote:
> > > On Friday 23 January 2009 04:37:01 Aaron J. Seigo wrote:
> > we have reports with svn commit messages that had the wrong BUG:#
> > entry (i've done that a couple times myself.. i'm human like everyone
> > else). being able to just delete those from the report instead of
> > having a "oops! wrong report, ignore that one!" comment would be
> > helpful.
> >
> > basically, this is about improving the quality and accuracy of the
> > conversation associated with a bug report.
>
> In Bugzilla one can mark comments as private effectively hiding them
> from non-authorized users. I'm not sure about the initial description,
> but since internally it's comment #0 it should be possible to hide it
> as well. Obviously, users with the appropriate rights would still see
> those comments.
>
> Would this be sufficient?
no: i'd still see them, other devs would still see them. i want to remove
mistakes / incorrect posts / innapropriate posts; nobody needs to see them
ever.
"delete" is not exactly advanced functionality in the world of software, so i
don't really see the reason to "fake it" by marking comment as private.
> > > > * ability to view lists of reports based on user account; this
> > > > would allow us to use bugs.kde.org as a dev communication tool
> > > > for things like patches. right now, it's completely unuseful for
> > > > that because all bugs go into one place and so we get a mess of
> > > > user, downstream and contributor reports.
> > >
> > > Lists of reports based on user account are already possible.
> >
> > but "user account" lacks any semantic meaning, so i can't get a list
> > of "all bugs containing patches from OSVs". i don't want to see just
> > Helio's or Binner's patches; i want to see *all OSV patches*.
> >
> > and i shouldn't need to know that Binner is an OSV downstream, nor
> > should i need to know his email address .. i should just be able to
> > get "patch reports from user accounts of type $TYPE"
>
> This is trivial with groups (obviously users can be member of several
> groups) in Bugzilla.
>
> Go to https://bugs.kde.org/query.cgi?format=advanced and have a look at
> the combo box in the Advanced Searching Using Boolean Charts section at
> the bottom.
neat. so we need to:
* make groups
* put people into them
* create some meaningful stored searches so we can just click on a link
instead of waste our life with that search form
> > > Lists based on
> > > account categorization of course depends on implementing that
> > > feature.
> >
> > exactly.
>
> Nothing needs to be implemented. All we have to do is add a few groups
> and then put the registered accounts in those groups.
that's good news.
> > > Bugzilla provides an "insider" group and private comments. I guess
> > > this
> >
> > i don't care about private comments. i just want a separate thread
> > that only developers/maintainers of the project can add to. everyone
> > should be able to read all comments.
>
> This could be done by creating a blocking clone of the original bug
> report. This clone would only be editable by developers/maintainers,
> but visible to everybody. In fact, that's how we use Bugzilla were I
> work. Our customers report bugs, those bugs are reviewed and, if they
> are valid, a development bug is created as clone of the original
> report.
when i want to pick something up off the floor, i face the other direction and
bend over backwards. once i grab the item, i then do a handstand and flip back
over onto my feet.
:P
seriously, i don't want to spend my time working around a tool that sould
simply work properly in the first place.
if a support tool takes too much time, training and effort it is a failure. it
will not be used by enough people enough of the time to make it pay.
> > nor should i have to remember email addresses.
>
> You can use the name instead of the email address. If several names
> match you get a list of matching names.
useful to know, thanks.
> > imho the CC and Assign
> > To lists should be editable drop downs pre-populated with all
> > accounts that are marked as associated to the project.
>
> Do editable drop downs even exist in HTML?
hm. good question. have i mentioned yet that i hate web interfaces?
> > the entries in the Target listing right now are now terrifically
> > useful either; the distinction between "by 4.3 freeze" and "by 4.3
> > release" is, for this particular need, academic and unuseful to me.
>
> Not sure what you are trying to say. Targets can be defined per product,
> so you can define the targets you want for Plasma.
i was just looking at the current list of Targets in the search form, and
there were some rather odd entries.
> > > > * rss feeds; right now we use mailing lists and they are ok-ish
> > > > but clumsy
> > >
> > > Sorry, I don't understand what you mean/want the rss for.
> >
> > i want to be able to follow reports or streams of reports in
> > akregator. as an added bonus, this means that i can reply to them
> > inline right there without opening an other window (a web browser)
> > and get to see them right there as they appear in a web browser.
> >
> > i just want notifications of "this changed", be able to click on that
> > entry in the list and see it in the rss reader. i don't really want
> > an email dropped in my box. a rich cilent could also address this
> > need, of course.
>
> At the bottom of the search result page there is an inconspicuous "Feed"
> link
ah, that's a good start, anyways ... now if it updates when someone changes a
bug we'd be golden :)
--
Aaron J. Seigo
humru othro a kohnu se
GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43
KDE core developer sponsored by Qt Software
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 197 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20090123/e65ed5cd/attachment.sig>
More information about the kde-core-devel
mailing list