Bugzilla recommendation

[Koen Kooi]

Op 18 mrt 2011, om 22:40 heeft Tom Rini het volgende geschreven:

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

I meant whatever gives the clearest message to people trying to file a bug there. If the landing page can be made really clear, good.

regards,

Koen

> 
>>>> 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.
> 
> -- 
> Tom Rini
> Mentor Graphics Corporation
> 
> _______________________________________________
> tsc mailing list
> tsc at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/tsc