Fate vs Bugzilla for feature tracking

Fri Jan 23 19:49:46 GMT 2009

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:
> > > * ability to delete comments and close reports permanently
> >
> > Not sure about that. Closing bugs permanently might be useful for
> > stubborn users reopening closed bugs
>
> and bugs opened for no other purpose than to be a dick. sorry, this
> is not a "might be" but "would have been very useful numerous times
> in the past already" feature. that's why i filed it under "must
> haves"
>
> > but I'm not sure about the "deleting comments"
> > part. Ideally we could keep all information but still have only the
> > useful part visible.
>
> sure, i don't care if it's archived or not. i just want to be able to
> remove comments from the report as displayed permanently.
>
> this also isn't just about situations of abuse, either. there is the
> case where you make a comment that contains factual error. oops! in
> the current system you then have to post another comment correcting
> that one. threading would help, but even nicer would be able to just
> hit "Delete" or even "Edit" and correct that issue.
>
> 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?

Moreover Bugzilla has support for groups. This can be used to hide bugs 
from certain groups or to make them non-editable.

http://www.bugzilla.org/docs/3.2/en/html/groups.html

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

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

> > > * ability to have developer discussion of a report in a separate
> > > thread from user input. it's madenning to not be able to have
> > > peer discussions without being interupted by random joe user who
> > > stops by to share his brilliance.
> >
> > 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.

> > > the "probably already doable but currently clumsy":
> > >
> > > * ability to mark, as a project committer only!, a feature for
> > > acceptance and have that feed into a feature plan report. from
> > > that report, i should be able to defer features to the next
> > > release and otherwise do simple feature plan managemet
> >
> > I think we're just not using that feature yet. Bugzilla's target
> > milestone feature should be enough to implement it.
>
> a "target milestone" as a single drop down choice would be feasible
> but also fairly limiting. marking something for acceptance should
> also note other items such as who is taking it on (can be done by
> Assigning the bug), the priority of that feature (the Priority
> attribute could work here, but it's pretty course grained at the
> moment), and all these attributes should be right next to each other.
> i don't want to be scrolling up and down the page to make this
> happen.

I guess flags could be used for this. The ability to request flags and 
to accept/deny flags is separately configurable per group.

With respect to not having to scroll up/down, changing the 
placement/order of the different controls on the bug view is a matter 
of tweaking the skin we use.

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

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

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

> and yes, it's these kinds of things that add up, one on top of the
> other, to make using bugzilla order of magnitude slower that it
> should be for what is really very basic workflow issues.
>
> > Predefined feature plan reports are indeed nice-to-have.
>
> without them, target milesone marking is next to useless because it
> makes finding those items harder to find and therefore harder to
> manage. so it's not really a "nice-to-have" imho, it's a requirement
> if Target is to be seriously used.
>
> you can do searches on Target, though, so feature plans could be as
> simple as a stored search with some sensible structure for the
> results.

Exactly. And since search results can be exported as XML it's easy to 
create a new feature plan from such a search result.

> > > * ability to mark, as a distro or other blessed downstream
> > > entity, items as must haves along with their personal "useful by"
> > > date (for a distro that would probably be the next version
> > > release date); i should then be able to view these as separate
> > > reports from everything else.
> >
> > Not sure. After all we're having fixed release dates.
>
> it's useful to know how our release date matches up with their
> "useful by" date when planning. how close the "useful by" date is to
> our next release determines whether or not i need to put effort into
> it for the next release, if i need to task some extraordinary efforts
> to it or just delay.

[snip]

> > Apart from that
> > adding extra marks shouldn't be hard.
>
> this particular marking needs to be per-user, not global to the
> report. i need to know how many of what sort of user account needs
> this feature how badly and by when. that's the information that
> enables me to make good decisions.

I'm not aware of this being possible with Bugzilla.

> > > * 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. The following is the link I got for product Plasma:
https://bugs.kde.org/buglist.cgi?bug_file_loc=&bug_file_loc_type=allwordssubstr&bug_id=&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&bugidtype=include&chfieldfrom=&chfieldto=Now&chfieldvalue=&email1=&email2=&emailassigned_to1=1&emailassigned_to2=1&emailcc2=1&emailreporter2=1&emailtype1=substring&emailtype2=substring&field-1-0-0=product&field-1-1-0=bug_status&field0-0-0=%255BBug%20creation%255D&keywords=&keywords_type=allwords&long_desc=&long_desc_type=substring&product=plasma&query_format=advanced&remaction=&short_desc=&short_desc_type=allwordssubstr&type-1-0-0=anyexact&type-1-1-0=anyexact&type0-0-0=noop&value-1-0-0=plasma&value-1-1-0=UNCONFIRMED%2CNEW%2CASSIGNED%2CREOPENED&value0-0-0=&votes=&title=Bug%20List&ctype=atom

I could successfully open it in Akregator.

Regards,
Ingo

-------------- 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/cb2121d2/attachment.sig>