<div dir="auto">FWIW, we also use a single "incoming"-style repo for PRs at work. Fork-per-PR is definitely not the only model that can work.</div><div class="gmail_extra"><br><div class="gmail_quote">On Jul 14, 2017 8:22 PM, "Thomas De Schampheleire" <<a href="mailto:patrickdepinguin@gmail.com">patrickdepinguin@gmail.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">2017-07-13 20:15 GMT+02:00 Dominik Ruf <<a href="mailto:dominikruf@gmail.com">dominikruf@gmail.com</a>>:<br>
><br>
><br>
> Thomas De Schampheleire <<a href="mailto:patrickdepinguin@gmail.com">patrickdepinguin@gmail.com</a>> schrieb am Do., 13.<br>
> Juli 2017 um 11:30 Uhr:<br>
>><br>
>> Hi Dominik,<br>
>><br>
>> 2017-07-12 22:11 GMT+02:00 Dominik Ruf <<a href="mailto:dominikruf@gmail.com">dominikruf@gmail.com</a>>:<br>
>> > Hi,<br>
>> ><br>
>> > I think we should start to eat our own dog food.<br>
>> > Meaning, we should use our own kallithea for pull requests instead of<br>
>> > bitbucket.<br>
>> > For this to work, users need to be able to create forks on<br>
>> > <a href="https://kallithea-scm.org/repos/" rel="noreferrer" target="_blank">https://kallithea-scm.org/<wbr>repos/</a>.<br>
>> > So I suggest creating a 'users' repo group, where each user gets his own<br>
>> > repo group named after him. There he can create forks and pull requests.<br>
>> ><br>
>> > What do do you think?<br>
>><br>
>> I fully agree about using our own Kallithea. We discussed about it too<br>
>> at the Antwerp meeting early 2016, notes are at<br>
>><br>
>> <a href="https://bitbucket.org/conservancy/kallithea/wiki/DeveloperMeeting2016January" rel="noreferrer" target="_blank">https://bitbucket.org/<wbr>conservancy/kallithea/wiki/<wbr>DeveloperMeeting2016January</a><br>
>> pasted for convenience here:<br>
>><br>
>> -------------<br>
>> Dogfooding: Should we do Kallithea code pull requests to our own<br>
>> Kallithea?<br>
>><br>
>> - Just do it!<br>
>> - need a way to "patch-bomb" pull requests from Ook to the mailing<br>
>> list to give transparency / visibility<br>
>> - would be nice to also 'read' comments sent by e-mail and apply to<br>
>> the web interface<br>
>> our own Kallithea is (currently) not set up for public hosting or self<br>
>> registration - that could block 'new contributors', so<br>
>> auto-registrations should be interesting, should create accounts for<br>
>> contributors<br>
><br>
> Thanks<br>
>><br>
>><br>
>> Andrew created accounts for Jan, Søren and Mathias<br>
><br>
> I do have an account as well. But I can't create repo groups.<br>
> Weirdly though, I see a 'Add Repository' button, but do not want to create a<br>
> repository on top level.<br>
>><br>
>> meanwhile: we should probably have an option to send an email to a<br>
>> newly created user that their account has been created so that they<br>
>> reset password for themselves<br>
>> Andrew has played with OAuth-based registration, but that went<br>
>> nowhere… (turbogears with repoze.who may help here)<br>
><br>
> In case you missed it, there is a PR from me as well.<br>
> <a href="https://bitbucket.org/conservancy/kallithea/pull-requests/258/wip-oauth-v3/diff" rel="noreferrer" target="_blank">https://bitbucket.org/<wbr>conservancy/kallithea/pull-<wbr>requests/258/wip-oauth-v3/diff</a><br>
> I could create a v4 of that, but I'd like to spend some time on it again<br>
> first.<br>
<br>
Thanks, I haven't looked at that yet.<br>
<br>
But, I think we should try and prioritize in order to effectively<br>
proceed as a community. This means: first bringing out the stable<br>
release 0.3.3 (I'm working on that), then finalizing bootstrap (asking<br>
the entire community to focus on testing and reviewing) and bringing<br>
out 0.9, and then finish off the other open pull requests. I'm afraid<br>
that if we dive into OAuth now, we'll be taking away resources from<br>
the planned releases.<br>
<br>
That does not mean we cannot start using OOK: as a first start we<br>
could create accounts manually, and enable the emails when people<br>
create PRs. That should be enough initially.<br>
<br>
[..]<br>
<br>
>><br>
>> I have used it for a number of PRs in the past, via the kallithea-incoming<br>
>> repo.<br>
><br>
> I'm not a fan of the incoming repo. I'm not sure how this suppost to work.<br>
> I mean, if everybody pushes their different branches into this single repo,<br>
> it becomes really confusing, don't you think?<br>
<br>
It's the way we review at work, but then again, we have a tool that<br>
actually creates the PRs via API, so there is less confusion possible.<br>
Separate repos do solve the confusion problem, indeed.<br>
<br>
However, we need to be careful about disk space too. I guess the<br>
multitude of Kallithea repositories is not such a big problem, but if<br>
users can create other repositories we need to be more careful. I<br>
don't think it is the intention that OOK becomes a public repository<br>
host. Perhaps we can restrict each user to have one repository<br>
'kallithea' and nothing else.<br>
<br>
With one kallithea-incoming, this problem does not exist.<br>
Mads, Andrew, what is your view?<br>
<br>
Best regards,<br>
Thomas<br>
______________________________<wbr>_________________<br>
kallithea-general mailing list<br>
<a href="mailto:kallithea-general@sfconservancy.org">kallithea-general@<wbr>sfconservancy.org</a><br>
<a href="https://lists.sfconservancy.org/mailman/listinfo/kallithea-general" rel="noreferrer" target="_blank">https://lists.sfconservancy.<wbr>org/mailman/listinfo/<wbr>kallithea-general</a><br>
</blockquote></div></div>