Eating our own dog food

Konstantin Veretennicov kveretennicov at gmail.com
Fri Jul 14 20:18:04 UTC 2017


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.

On Jul 14, 2017 8:22 PM, "Thomas De Schampheleire" <
patrickdepinguin at gmail.com> wrote:

> 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
> _______________________________________________
> kallithea-general mailing list
> kallithea-general at sfconservancy.org
> https://lists.sfconservancy.org/mailman/listinfo/kallithea-general
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sfconservancy.org/pipermail/kallithea-general/attachments/20170714/b23331e4/attachment-0001.html>


More information about the kallithea-general mailing list