[Labs-l] [NEW] Self-service git repository creation for tools

[Bryan Davis]

On Sat, Aug 27, 2016 at 1:50 PM, Magnus Manske
<magnusmanske at googlemail.com> wrote:
> First of all, thanks! First time I can actually get a list of all the tools
> I am involved in :-)

\o/ Glad you like that feature. I've got some ideas for making it more
useful in the future (sorting, favorites, "needs attention" badges,
etc).

> Now, should I continue using BitBucket (other people might use github, same
> question)?

That's entirely up to each Tool developer. There is no mandate to use
Diffusion or Gerrit or any other particular version control hosting
service. My main aim was to provide a FLOSS hosting solution for Tools
that is as easy (or nearly as easy) as some of the more popular walled
gardens.

> What would be the practical perks for moving to Phabricator?

* FLOSS hosting
* Closer integration with other projects in Wikimedia version control
* Easier discovery of source code for interested contributors {{CN}}

Easier discovery is a bit of a stretch until there are enough tools
hosting their version control in Diffusion that searching there
becomes an obvious first step. There may also be advances in Tool Labs
workflows in the future [T136264] that provide other benefits to
hosting your source in Diffusion like common deployment tooling.
That's future looking however, so its not a tangible benefit today.

> Is there a manual, or even a magic "click here to..." button?

For Striker, no, no manual yet. Docs should start to show up on
Wikitech as soon as some of us start to write them. I am planning to
get something started there next week, but would be delighted to find
out that someone had beaten me to it. :)

For Diffusion, there is a pretty good collection of docs upstream
[diffusion_manual]. I'd like to see some quick "how to" guides for
common tasks on Wikitech too, but first I guess we need to figure out
what tasks are common.

> Does Differential offer tool-specific bug tracking (I assume it does)?

Diffusion doesn't in and of itself provide bug tracking. It does
however integrate nicely with Phabricator's bug tracking features
(Manifest) and code review system (Differential).

Would adding easy creation of a Manifest project for bug tracking be a
useful feature to add? It looks like we have an existing convention of
projects named #Tool-Labs-tools-* which seems like something that was
probably inherited from the old bugzilla layout. We would probably
need to discuss with the #Project-Admins group, but I think we could
have a convention of #Tool-* instead that would make type ahead a bit
nicer. I opened a ticket for this feature enahncement to be discussed
[T144111].

> Does it allow issue reporting without requiring a user account, like BitBucket?

No. The Wikimedia Phabricator install does require authentication to
create or comment on issues. The OAuth integration with the main
Wikimedia wiki farm does however make account creation fairly painless
for most of our community members.

> Or is this intended mainly for tools that don't have a repo yet?

In this early release, I think that yes that main target is Tools that
have not yet setup public version control anywhere.

> Should existing, third-party repos be tracked in toolsadmin and/or Phabricator/Differential?

I have (undocumented) plans to add support for editing and publishing
toolinfo.json compatible descriptions for each tool. When this is
implemented it will support connecting 3rd party hosting to each tool.

Right now it is possible to create a Diffusion repo through the admin
console and then manually set it up as a mirror of an existing GitHub
repo through the management interface in Phabricator. Kunal managed to
do this with one of his tools [R1947]. Currently the configuration of
Phabricator itself only allows connecting to GitHub, but we have one
bug open to allow another external host. I expect as we talk through
the reasonable solutions of that issue that we will either open up to
a slightly larger fixed whitelist and come up with a procedure for
adding more, or determine that automatic external mirroring is
undesirable. If the answer ends up being that Wikimedia can't allow
their main Phabricator to connect to arbitrary 3rd party hosts to
mirror into Diffusion, I think someone can whip up a tool that can
poll, fetch and push to manage mirrors for interested tools in a
weekend. :)


[T136264]: https://phabricator.wikimedia.org/T136264
[diffusion_manual]:
https://secure.phabricator.com/book/phabricator/article/diffusion/
[T144111]: https://phabricator.wikimedia.org/T144111
[R1947]: https://phabricator.wikimedia.org/diffusion/1947/
[T143969]: https://phabricator.wikimedia.org/T143969

Bryan
-- 
Bryan Davis              Wikimedia Foundation    <bd808 at wikimedia.org>
[[m:User:BDavis_(WMF)]]  Sr Software Engineer            Boise, ID USA
irc: bd808                                        v:415.839.6885 x6855