Re: [eigen] questions about Bugzilla workflow

[ Thread Index | Date Index | More lists.tuxfamily.org/eigen Archives ]


2010/10/16 Benoit Jacob <jacob.benoit.1@xxxxxxxxx>:
> 2010/10/16 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...
>
> ah ok. But i think that Bugzilla supports bug aliases so you would
> only have to enter, say, 3.0-beta3. Let me set this up.

....actually, since we're talking about milestones, e.g. 3.0 or 3.1,
you'd only have to type 3.0 or 3.1 which is really quick to type.

Benoit

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



Mail converted by MHonArc 2.6.19+ http://listengine.tuxfamily.org/