Eating our own dog food

Thomas De Schampheleire patrickdepinguin at gmail.com
Fri Jul 14 18:22:31 UTC 2017


2017-07-13 20:15 GMT+02:00 Dominik Ruf <dominikruf at gmail.com>:
>
>
> Thomas De Schampheleire <patrickdepinguin at gmail.com> schrieb am Do., 13.
> Juli 2017 um 11:30 Uhr:
>>
>> Hi Dominik,
>>
>> 2017-07-12 22:11 GMT+02:00 Dominik Ruf <dominikruf at gmail.com>:
>> > Hi,
>> >
>> > I think we should start to eat our own dog food.
>> > Meaning, we should use our own kallithea for pull requests instead of
>> > bitbucket.
>> > For this to work, users need to be able to create forks on
>> > https://kallithea-scm.org/repos/.
>> > So I suggest creating a 'users' repo group, where each user gets his own
>> > repo group named after him. There he can create forks and pull requests.
>> >
>> > What do do you think?
>>
>> I fully agree about using our own Kallithea. We discussed about it too
>> at the Antwerp meeting early 2016, notes are at
>>
>> https://bitbucket.org/conservancy/kallithea/wiki/DeveloperMeeting2016January
>> pasted for convenience here:
>>
>> -------------
>> Dogfooding: Should we do Kallithea code pull requests to our own
>> Kallithea?
>>
>> - Just do it!
>> - need a way to "patch-bomb" pull requests from Ook to the mailing
>> list to give transparency / visibility
>> - would be nice to also 'read' comments sent by e-mail and apply to
>> the web interface
>> our own Kallithea is (currently) not set up for public hosting or self
>> registration - that could block 'new contributors', so
>> auto-registrations should be interesting, should create accounts for
>> contributors
>
> Thanks
>>
>>
>> Andrew created accounts for Jan, Søren and Mathias
>
> I do have an account as well. But I can't create repo groups.
> Weirdly though, I see a 'Add Repository' button, but do not want to create a
> repository on top level.
>>
>> meanwhile: we should probably have an option to send an email to a
>> newly created user that their account has been created so that they
>> reset password for themselves
>> Andrew has played with OAuth-based registration, but that went
>> nowhere… (turbogears with repoze.who may help here)
>
> In case you missed it, there is a PR from me as well.
> https://bitbucket.org/conservancy/kallithea/pull-requests/258/wip-oauth-v3/diff
> I could create a v4 of that, but I'd like to spend some time on it again
> first.

Thanks, I haven't looked at that yet.

But, I think we should try and prioritize in order to effectively
proceed as a community. This means: first bringing out the stable
release 0.3.3 (I'm working on that), then finalizing bootstrap (asking
the entire community to focus on testing and reviewing) and bringing
out 0.9, and then finish off the other open pull requests. I'm afraid
that if we dive into OAuth now, we'll be taking away resources from
the planned releases.

That does not mean we cannot start using OOK: as a first start we
could create accounts manually, and enable the emails when people
create PRs. That should be enough initially.

[..]

>>
>> I have used it for a number of PRs in the past, via the kallithea-incoming
>> repo.
>
> I'm not a fan of the incoming repo. I'm not sure how this suppost to work.
> I mean, if everybody pushes their different branches into this single repo,
> it becomes really confusing, don't you think?

It's the way we review at work, but then again, we have a tool that
actually creates the PRs via API, so there is less confusion possible.
Separate repos do solve the confusion problem, indeed.

However, we need to be careful about disk space too. I guess the
multitude of Kallithea repositories is not such a big problem, but if
users can create other repositories we need to be more careful. I
don't think it is the intention that OOK becomes a public repository
host. Perhaps we can restrict each user to have one repository
'kallithea' and nothing else.

With one kallithea-incoming, this problem does not exist.
Mads, Andrew, what is your view?

Best regards,
Thomas


More information about the kallithea-general mailing list