[Systems] Bug trackers for downstream issues discussion

[Pablo Flores]

Thanks for your answers. I wanted to point out that tagging bugs can be
useful, but it's not enough for fitting deployments' needs. For instance,
it's a need having deployment's target version for the issues, and
following specific steps in the workflow like intermediate steps for
approving due dates and hours to be spent, or having the deployment's
approval before closing the ticket. Some of these things are SLA-related,
and that's why they aren't considered in SL bugtracker. An option could be
developing interoperation between SL bugtracker and some AC/deployment's
internal system, but for this (in case it's a good idea) it would also be
needed making changes to SL bugtracker.

It's a complex issue and maybe the best would be discussing it together
when Rubén and me are in Boston (26th to 29th). Can we make it possible?

Regards,
Pablo Flores
activitycentral.com



2012/3/14 Chris Leonard <cjlhomeaddress at gmail.com>

> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/private/systems/attachments/20120317/e099d606/attachment.html>