Changes to branch management

[Ben Cooksley]

On Sat, Dec 27, 2014 at 9:09 AM, Matthew Dawson <matthew at mjdsystems.ca> wrote:
> On December 25, 2014 08:21:05 PM Ben Cooksley wrote:
>> > 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.
> I think a combination of 2 + 3 are best.  3 is the best for doing
> collaborative work, where force pushes are not welcome.  As Thomas says, its
> simple and keeps most important branches protected.
>
> However, I think 2 should be included, if and only if a developer gains the
> ability to force push into their personal branches.  When working , a
> developer may want to revise the history as development progress, but before
> moving it into a collaborative zone.  This makes it easy for developers to
> work closer to the main repository without pushing the code elsewhere,
> allowing other developers to quickly see how something is progressing.
>
> If force pushes are something that KDE does not want to allow, then I think
> doing just 3 is best.  I had thought they were disallowed to prevent people
> doing bad things on important branches.  I think for branches specifically
> listed as personal branches, allowing force pushes would be OK with the CoC,
> as developers can continue to monitor progress on a given branch.
> --
> Matthew

Thanks everyone for the feedback.
Support for proposal #3 seems fairly universal from what I can see -
so we'll go ahead and implement that.

Unfortunately allowing force pushes is an extremely messy business
with the hooks - so we're unable to do this (for maintenance reasons
among others).

Thanks,
Ben