Changes to branch management

[Matthew Dawson]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20141226/e57c6592/attachment.sig>