Re: [eigen] questions about Bugzilla workflow

[Gael Guennebaud <gael.guennebaud@xxxxxxxxx>]

On Sat, Oct 16, 2010 at 2:19 PM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
> 2010/10/16 Gael Guennebaud <gael.guennebaud@xxxxxxxxx>:
>> Hi,
>>
>> On Sat, Oct 16, 2010 at 5:12 AM, Benoit Jacob <jacob.benoit.1@xxxxxxxxx> wrote:
>>> Hi,
>>>
>>> I have 2 questions about how we should be working with Bugzilla:
>>>
>>> 1. Should there be a "nobody" assignee? Currently, every bug is forced
>>> to be assigned to someone. There's a default assignee for each
>>> component.
>>>  - good: this means that no bug is left with nobody caring for it
>>>  - bad: this wrongly suggests that the assignee said he would fix it,
>>> and can send prospective contributors the wrong signal
>>>
>>> So: should we create a dummy "nobody" account, to whom we could assign
>>> bugs that aren't owned by anyone? If yes, should we make that the
>>> default assignee for all new bugs, or should we keep our system of
>>> assigning new bugs to real people by default, and letting them
>>> (re)assign to "nobody" if needed?
>>
>> indeed, I was not 100% comfortable with automatic default assignees so
>> I think that's a good idea.
>
> OK. What's your opinion on the second "if yes..." question I asked?
> Default to "nobody" as assignee?

yes of course.

>
>>
>>
>>> 2. Are "milestones" useful? We have to file tracking bugs for each
>>> milestone anyway as that is the only way (AFAIK) of getting certain
>>> useful features such as dependency tree/graph. So what's the value of
>>> "milestones" compared to setting "blocks:" on the tracking bug?
>>
>> 1 - with milestones you don't have to remember/search for the respective bug ID
>
> Then it's enough to put a "target milestone" on the tracking bug, no
> need to set it on every bug; alternatively, the same result can be
> achieved by putting links to the tracking bug where people will
> naturally look for it (wiki,etc).

??? I probably was not clear. I meant that, when I fill a bug, it is
much faster and simpler for me to set a target milestone than editing
the "block" parameter, because for the later I have to open a new
windows, search for the respective "target bug", and finally gets back
to the original windows and enter its ID without making a typo...

gael


>> 2 - with milestones you can have a list of all blocking issues for
>> each milestone integrated in a wiki page.
>
> Hm I'm not sure what a milestone gives you here that a tracking bug
> doesn't? First, the dependency tree is such a list,
> http://eigen.tuxfamily.org/bz/showdependencytree.cgi?id=25&hide_resolved=1
>
> Second, if you were thinking about search results, you can do that
> also with just a tracking bug, although you only get the bugs that are
> directly blocking, i.e. it doesn't go recursively:
>
> http://eigen.tuxfamily.org/bz/buglist.cgi?query_format=advanced&field0-0-0=blocked&bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&type0-0-0=anywords&value0-0-0=48
>
> To construct this kind of search, under Search click "Advanced Search"
> and then at the bottom, "Advanced Searching Using Boolean Charts".
>
>
>>
>> For 1, we could workaround it using aliases. For 2, the dependency
>> graph is probably fine too, maybe unless there are too many bugs and
>> the graph gets too big, I don't know.
>>
>> So I would say more or less even, though milestones look slightly easier to me.
>>
>> gael
>>
>>> Benoit
>>>
>>>
>>>
>>
>>
>>
>
>
>