Bugzilla recommendation
Khem Raj
raj.khem at gmail.com
Fri Mar 18 21:05:48 UTC 2011
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.
>
>> 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.
> --Mark
>
>> regards,
>>
>> Koen
>>
>> PS: It looks like angstrom will go with Jira for its layer(s) and distro.
>> _______________________________________________ tsc mailing list
>> tsc at lists.openembedded.org
>> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/tsc
>
>
> _______________________________________________
> tsc mailing list
> tsc at lists.openembedded.org
> http://lists.linuxtogo.org/cgi-bin/mailman/listinfo/tsc
>
More information about the tsc
mailing list