[PATCH] pullrequests: add support for custom pull request id prefix

[Thomas De Schampheleire]

On Mon, Apr 20, 2015 at 11:35 PM, Mads Kiilerich <mads at kiilerich.com> wrote:
> On 04/20/2015 05:55 AM, Thomas De Schampheleire wrote:
>>
>> On Sun, Apr 19, 2015 at 6:16 PM, Mads Kiilerich <mads at kiilerich.com>
>> wrote:
>>
>
>>> I would probably take a patch that moved the hardcoded # naming to a
>>> method
>>> on the PullRequest db model, similar to how we have .url . It would be
>>> very
>>> much like the existing .pull_request_id field so perhaps name it
>>> .nice_id?
>>
>> Shouldn't it be symmetrical: pull_request_nice_id or something like that?
>
>
> Probably ... but that is a long name and I'm lazy ;-)
>
> Right ...
>
>>
>>> It is a bit weird that Kallithea pull request numbers are global.
>>> Especially
>>> in a site that is hosting repos for multiple independent users, it would
>>> make sense to have per repo numbering. Would that solve your case? Will
>>> your
>>> repos in the different instances be named differently?
>>
>> No, the different instances would operate on the same repositories
>> with the same names (note that we're not using Kallithea for repo
>> hosting, it is a mirror).
>
>
> Using it as a mirror is fine ... but having multiple independent instances
> does not seem like something I can recommend. It would make more sense to
> have multiple servers on the same database in some failover loadbalancing
> setup.

The reason we planned doing such a setup is that the network
latency/bandwidth between sites is not always very good. If there is
one single Kallithea instance in a given site, the developers from
that site get a good experience, while the developers from a remote
site may suffer high latencies. With a local database + instance this
would be mitigated.

Your suggestion of the same database and multiple Kallithea instances:
how exactly does this work? Is all locking in place? And since the
database is in one place: don't you suffer from the same network
latency issue?

>
>> Also, global IDs have the benefit of being completely standalone. If
>> we have per-repo IDs, I cannot tell you 'look at pull request 5',
>> because I would have to tell you which repo to look in.
>
>
> In general I think it is a good thing to have to specify which repo a PR is
> for.
>
> Your case of multiple series for the same repo with the same numbering
> scheme ... that is just ... no! Just say no! ;-)
>
> Anyway, I think you can do what you want with some upstreamed refactorings
> and some system for monkeypatching extensions.

I will try implementing this system anyway, and look forward to your
suggestions on the deployment model.

Thanks,
Thomas