Page MenuHomePhabricator

Provide an easy way for Tool Labs tools to expose their source code
Closed, ResolvedPublic

Description

A way that does not require using git - there are already plenty of those. Something much simpler that allows public access to source code, with an easy way to verify that you aren't leaking any private information.

Related Objects

StatusAssignedTask
OpenNone
Resolved bd808
Resolved bd808
Resolved bd808
Resolvedmmodell
Resolvedmmodell
Resolved bd808
Resolved dpatrick
Resolved bd808
Resolvedmmodell
Resolvedjcrespo
Resolved bd808
Resolved bd808
Resolved bd808
Resolved bd808
Resolved bd808
Resolved bd808
ResolvedAklapper
ResolvedAklapper
ResolvedAklapper
ResolvedAklapper
ResolvedAklapper

Event Timeline

yuvipanda raised the priority of this task from to Medium.
yuvipanda updated the task description. (Show Details)
yuvipanda added subscribers: Krenair, scfc, Andrew and 4 others.

We have no objections to this from a legal perspective. Unless I am mistaken, this appears to be primarily a technical change to provide users with an option to do so. Thanks, Zhou

I thought the easiest way for Tool Labs tools to expose their source code would have been a "Fork me on Gerrit" ribbon...

So problems with Gerrit are:

  1. No self-serve repo creation / forking
  2. The UI is... somewhat new user hostile
  3. The workflow is optimized for large projects, and is quite painful if you are a one / two person project

Also,

  1. Some people just do not care about version control - consider it too much pain for too little gain. They are wrong, of course (:P) but we should accomodate those people in some form too, maybe.
ZhouZ moved this task from Backlog to Legal Done on the WMF-Legal board.Apr 14 2016, 1:04 AM
Restricted Application added a subscriber: JEumerus. · View Herald TranscriptApr 14 2016, 1:04 AM
Qgil moved this task from To triage to Team radar on the Developer-Advocacy board.May 3 2016, 10:09 AM
-jem- added a subscriber: -jem-.Sep 23 2016, 7:26 PM
Qgil added a subscriber: Qgil.Oct 27 2016, 1:33 PM

Would this task be a good topic for the Wikimedia-Developer-Summit (2017) ? If so, the deadline to submit new proposals is next Monday, October 31: https://www.mediawiki.org/wiki/Wikimedia_Developer_Summit/Call_for_participation

waldyrious added a subscriber: waldyrious.
scfc moved this task from Triage to Backlog on the Toolforge board.Dec 4 2016, 8:11 PM
Legoktm added a subscriber: Legoktm.Feb 4 2017, 7:40 AM

So problems with Gerrit are:

  1. No self-serve repo creation / forking
  2. The UI is... somewhat new user hostile
  3. The workflow is optimized for large projects, and is quite painful if you are a one / two person project

I believe with the combination of striker + diffusion, none of these concerns are as applicable. (#2 is partly true due to the split across striker and diffusion but eh).

Is not requiring the usage of git still a requirement for this task?

Is not requiring the usage of git still a requirement for this task?

If it is, then I think we would have to close it as WONTFIX honestly. I do still sort of feel that there could be more end-user friendly tools than gerrit/diffusion. An easy way to fork an existing project is still conspicuously missing in our current setup. We may get lucky and get more features that would help here as a by-product of T136264: Evaluate Kubernetes based workflow replacement options for SGE. The PaaS products I have used in the past provided good tools for separating secrets from code which is really the biggest blocker to just setting up something that rsyncs tool code to a place where anyone can browse and copy from it. A "Heroku-like" still would not enforce secret separation, but it would at least provide clear best practices for secret management.

Well the original premise of this task that @yuvipanda created was "A way that does not require using git". @yuvipanda, could you describe what kind of system you were imagining?

All of the things I was thinking of and can think of now seem terrible and seem to enable our current set of terrible practices. I'll leave it to the current stewards of tools to figure out what to do :) I do agree that enforcing a vcs seems best possible option.

bd808 closed this task as Resolved.Jul 12 2017, 12:10 AM
bd808 claimed this task.
bd808 added a subscriber: yuvipanda.

All of the things I was thinking of and can think of now seem terrible and seem to enable our current set of terrible practices. I'll leave it to the current stewards of tools to figure out what to do :) I do agree that enforcing a vcs seems best possible option.

Let's call this "implemented" via the self-service diffusion repos then. Could it be even easier, yes. Should we leave this open forever like Bug 1 to remind us that the work is never really {{done}}, no thanks.

Restricted Application edited projects, added User-bd808; removed Toolforge. · View Herald TranscriptJul 12 2017, 12:10 AM