[Labs-l] Coren joining WMF Ops department as Tools Labs contractor

[Tim Landscheidt]

(anonymous) wrote:

> [...]

>> You can look at his TODO list here:
>> https://www.mediawiki.org/wiki/Wikimedia_Labs/TODO

> I'm confused about the mention of having a bug tracker dedicated to the
> tools project.
> IMHO, we should use bugzilla.wikimedia.org (we can of course have new
> sections, etc.)
> Installing another bugzilla instance for tools seems an error.

ACK.  No to mention the necessary maintenance, just think
about the confusion when someone refers to "bug 4711 in
Bugzilla".  And while a human might be able to guess the in-
tent, what would Gerrit do? :-)

"Marc A. Pelletier" <marc at uberbox.org> wrote:

>> With regards to maintainers using it to track issues for their tools, we can do this on a per component basis with auto cc lists that any Bugzilla admin can edit.

> My original impression is that this would, in practice,
> turns out to be more operational trouble than maintaining a
> project-specific bugtracker.

> One of the requirements from the tool users is to have a
> ticket tracker to provide support for the tools they write;
> in general, /who/ maintains those tools is meant to be
> mutable, and tracked from within the Tools project (and may
> not map well with the bugtracker's users in the general
> case).

> For instance, the intent is to allow the Tools project users
> to create and alter new tools (think: bugzilla products,
> possibly with many components) without the requirement of
> sysadmin intervention in most scenarios - synchronizing the
> creation of those tools in the Labs with updates to the
> central bugzilla is /possible/, but I fear it might
> introduce a brittleness we certainly don't want in one of
> the primary work tools of the engineering team.

> Now, if we make that as a service to the Tools lab users
> running in the project, the management problem is
> constrained.

> I'm not attached to the idea, but I certainly think it's the
> simpler solution.

I think your assumption that all tools need to have a syn-
chronized Bugzilla product/component is wrong.  Using
Bugzilla is mostly interesting for developers using Gerrit
as a repository, or those explicitly demanding a tracker.
There are tools that are developed at GitHub and other
places that take advantage of the trackers offered there and
shouldn't be forced to use Bugzilla.

https://jira.toolserver.org/secure/BrowseProjects.jspa?selectedCategory=all
lists 84 projects, many of which stale or of only historical
interest.  I think that is a number that the existing
Bugzilla can master, and I don't think it's high enough to
warrant the extra effort of a separate instance.

Tim