github, phabricator: a new threadZ

[Ben Cooksley]

On Thu, Aug 10, 2017 at 7:02 PM, Harald Sitter <sitter at kde.org> wrote:
> I for one would pick the alternative which is not using our
> infrastructure and instead click two buttons so I don't have to file
> paperwork manually nor have to wait for said paperwork to get faxed to
> HQ for approval. i.e. not waiting trumps waiting in my world.

The reason why it's restricted right now is because creating a
repository with Gitolite requires the ability to push to
gitolite-admin, which also means you can change SSH Keys and thus
become them as far as the system is concerned.

I dislike your use of terminology there regarding paperwork being
faxed to HQ - Sysadmin hasn't ever declined a developers request for a
repository. We have on occasion suggested different names, to keep to
conventions (for Plasmoids and packaging repositories for instance) or
where a developer has chosen a heavily generic and non-descriptive
names.

Repository names that don't follow conventions or which are
non-descriptive are harmful as they interfere with the discoverability
of code.

Oh, and you're neglecting to mention that scratch repositories very
much still exist, and require basically no effort to use. Not even a
Sysadmin ticket.

>
> On Wed, Aug 9, 2017 at 8:05 PM, Albert Astals Cid <aacid at kde.org> wrote:
>> El dimecres, 9 d’agost de 2017, a les 13:50:46 CEST, Harald Sitter va
>> escriure:
>>> On Wed, Aug 9, 2017 at 1:39 PM, Boudewijn Rempt <boud at valdyas.org> wrote:
>>> > On Wed, 9 Aug 2017, Riccardo Iaconelli wrote:
>>> >> This is a new thread entirely, but incidentally also something we
>>> >> should also think about. Why many KDE developers choose github instead
>>> >> of scratch KDE repositories to start new software, where it could
>>> >> happily be hosted within KDE infrastructure?
>>> >
>>> > Our infra doesn't offer scratch repos anymore, does it?
>>>
>>> It does, they were slated for removal with the transition to phab,
>>> since that hasn't happend yet though I assume scratch repos are still
>>> a thing. Albeit, a thing that is meant to be removed with (currently)
>>> no replacement planned
>>
>> That was not the plan, the plan (unless it has changed since last time i
>> asked) is to have a team of "trusted people" that can create repos on

That group has for the most part been established already, and is
known as #Community_Admins.
It's full membership can be seen at
https://phabricator.kde.org/project/members/27/

Once we move to using Phabricator for hosting repositories they'll
have the power to create a repository in about 4 clicks.

They currently have the power to fully edit tasks (including
visibility and edit rights), create and edit all projects, setup short
urls (go.kde.org), manage global Herald rules and setup top level Wiki
namespaces on Phabricator among other things.

>> phabricator, so basically you'd open a ticket and you'd get a repo created in
>> a matter of minutes, not automagic, but surely you can continue coding for 15
>> minutes while you wait for your repository to be created.

In terms of a scratch repositories, we just haven't figured out how
those should be handled in Phabricator yet. Given the fact people have
issue with how they work now, one of the possible solutions floated at
the time was that we would retire them.

It is possible a more limited version of the create repository flow
will be offered to developers who aren't community admins which will
set repositories up (but not allow editing them), but this would
require custom code (likely as a Phabricator extension).

>>
>> Cheers,
>>   Albert
>>
>>> which is why for example I do not create any
>>> new ones and instead use github. Although TBH the UX of creating a
>>> scratch has also left me wanting as it entails me googling how to
>>> setup a scratch every single time.
>>>
>>> HS
>>
>>

Regards,
Ben