Bugzilla recommendation

[Mark Hatle]

On 3/18/11 4:40 PM, Tom Rini wrote:
> On 03/18/2011 02:05 PM, Khem Raj wrote:
>> On Fri, Mar 18, 2011 at 1:55 PM, Mark Hatle<mark.hatle at windriver.com>  wrote:
>>> On 3/18/11 2:41 PM, Koen Kooi wrote:
>>>> Hi,
>>>>
>>>> On oe-devel is was suggested that the TSC make a recommendation of the
>>>> bugzilla situation. I would like to propose the following:
>>>>
>>>> Shutdown the current OE bugzilla and add a html page directing people to
>>>> patchwork and the mailinglist. We can alway reactivate bugzilla when someone
>>>> actually steps up instead of the current "I might..." type of people.
>>>
>>> Shutdown, as in make read-only or?  I'd hate to lose anything that may be
>>> valuable in it.
>>
>> yes make it RO would be better and probably add a header saying where to go.
> 
> I too would vote for RO + header just because there is occasional bits 
> of useful history and discussion in the bugzilla.
> 
>>>> For OE-core we will (re)use the yocto bugzilla, other layers should document
>>>> their bug policy clearly inside the layer README.
>>>>
>>>> I think this accomplishes what RP and I want, no zombie bugzillas and keeps
>>>> the door open for people willing to maintain one. What do you all think of
>>>> this?
>>>
>>> I think we need to be clear when we suggest shutting it down that if someone is
>>> willing to manage a subsystem and take responsibility for work that there be a
>>> way to enable a bug tracking system.  But it's only for components, projects
>>> that have an active maintainer, someone responsible for dealing with the bugs.
>>>
>>
>> Bugzilla is a good tool but we have to commit to using it in process.
>> All patches go there
>> all commit message emails are captured by bugs etc. etc. to make it effective
>> it would need some effort. As I said before I have been feeding it to
>> keep it alive but
>> if its not the preferred tool in work flow then I have no intention to
>> continue spending time on it
>> One problem that it captures better in form of bugs is user reported
>> problems. It requires a lot
>> of discipline to keep that information in mailboxes and every
>> developer has their own
>> way of managing emails they get. It offers good interface for such
>> things. Now we can also use it
>> to track patches tool but then we have to think through it and do we
>> want to do it.
>>
>> I am certainly open for both ways.
> 
> Here-in lies the problem, and I think Koen is correct (except for 
> RO+header rather than remove + redirect).  A bugzilla (and any BTS open 
> to the public) requires not just a good workflow with developers but 
> good and dedicated triage people.  And not just in the sense of "is this 
> in the right category?" but "is this valid, is there enough 
> information".  I think the TSC should recommend that the community have 
> a set of volunteers ready to do that job before we recommend how a BTS 
> should be used for meta-oa / openembedded project repos / branches.
> 

Yes, I agree....  Until there are people, all we can do is suggest for the
places that are people.  The suggestion is to use the Yocto bugzilla.

--Mark