Changes to branch management

[Ben Cooksley]

On Thu, Dec 25, 2014 at 5:04 AM, Jan Kundrát <jkt at kde.org> wrote:
> On Wednesday, 24 December 2014 01:57:15 CEST, Ben Cooksley wrote:
>>
>> Unfortunately i'm not sure if Gitolite's ACL mechanisms let us
>> differentiate between tags and branches so if we allow anyone to
>> delete branches they'll probably be able to do the same for tags.
>
>
> Are the generated config files or the scripts for generating gitolite's
> config files available somewhere? The Gitolite setup I'm familiar with uses
> explicit qualifiers such as "refs/heads/" and "refs/tags/" when setting up
> ACLs. Do you use something different on git.k.o? If not, then managing tags
> separately from branches should come for free.

The generated files themselves are only available in the private
gitolite-admin repository.
You can find the "script" which is a Redmine/Chiliproject plugin in my
scratch space on git.kde.org.

Our config file template goes something like this though:

repo <reponame>
    RWCD = <repo admins>
    RW   [0-9](.+) = @all
    -    [0-9](.+) = @all
    RW   KDE/(.+)  = @all
    -    KDE/(.+)  = @all
    RWC  = @all

Changing it to use explicit syntax shouldn't cause any major breakages
though - but considering that the release managers are not always
repository admins I would be reluctant to restrict the management of
tags to repo admins only.

>
> The way I see it, there are two reasonable alternatives with the current
> setup:
>
> 1) Everybody can create, delete and force-push to all branches except the
> "reserved" ones (kde/*, master, stable,... see the list).
>
> 2) People are free to create, delete and force-push to all branches below
> my/$username/ (in my case, tat would be my/jkt/foo for example). Only repo
> owners can create, delete and force-push to arbitrary branch names.

In essence, yes - those are the two possible options we have.
Force pushing will *still* be prohibited under this proposal as it
stands (and would be a CoC violation if done).

>
> Deciding which of these to use should be just a matter of style. Both seem
> very sensible to me, and they will definitely present an improvement over
> the current status where people can create, but not cleanup afterwards.

Agreed. Can we have a show of hands / etc as to which one would suit
people best?

I will add a 3rd possibility though.

3) People are free to create and delete to all branches below work/*.
Creation and deletion of branches outside this would be limited to
project admins (release managers). It also allows other developers to
cleanup as needed so it doesn't all fall on the repository admin /
sysadmin.

This removes developer usernames from the branch names - which is
probably better for long term collaborative branches (which i've seen
used in a number of projects) and doesn't make a difference for short
term branches.

>
> With kind regards,
>
> Jan

Thanks,
Ben

>
> --
> Trojitá, a fast Qt IMAP e-mail client -- http://trojita.flaska.net/