[Systems] Bug trackers for downstream issues discussion

[Chris Leonard]

2012/3/14 Bernie Innocenti <bernie at sugarlabs.org>:
> On Wed, 2012-03-14 at 15:24 -0300, Pablo Flores wrote:
>
>>       * If we use a public bugtracker, no matter if it's bugs.sl.org
>>         or another one, we have a mandatory need, which is being able
>>         to customize it to the workflow of the deployments. This
>>         includes adding specific fields and statuses in the
>>         bugtracker. Those customizations may vary from deployment to
>>         deployment. So, for being able to use a public bugtracker with
>>         deployments, AC should be able to customize it as much as
>>         needed. Would this be possible to do with a shared bugtracker
>>         or would it be better that AC sets up its own (public) one?
>
> I think that adding custom tags to bugs such as the current "dextrose"
> keyword is a good thing. Trac allows creating custom queries based on
> any keyword, resulting in useful tools for project management:
>
>  http://bugs.sugarlabs.org/wiki/Dextrose
>
>
> However, when Seeta used bugs.sugarlabs.org a couple of years ago, they
> started adding all sorts of components, keywords, milestones and
> versions to existing bugs. Seeta engineers started reassigning existing
> bugs to a faceless "seeta" user or adding mysterious keywords that
> nobody outside Seeta could interpret. Many Sugar developers found all
> this bug-tracker churn quite annoying and asked me to make them stop.
>
> So I think that it's ok to extend our public bug tracker in ways that
> make it more useful for everybody. Silbe already has admin rights on
> bugs.sugarlabs.org and I trust his judgment on what constitutes an
> acceptable configuration change for the Sugar community.

FWIW, I'm inclined to agree with Bernie's assessment, but I do not
live and breathe in the bug tracker the way the developers do and so
their opinions should be weighted more than mine..

I do want to express my appreciation for AC seeking to consult with SL
on leveraging infrastructure as a means of achieving greater
transparency.  Anish and I have made some progress with adding a
"dextrose diff" project to Pootle to be merged on top of SL sugar.po
for the convenience of language teams using Dextrose builds.

cjl