Changes to branch management

Ben Cooksley bcooksley at kde.org
Wed Dec 24 01:11:46 GMT 2014


On Wed, Dec 24, 2014 at 4:40 AM, Boudewijn Rempt <boud at valdyas.org> wrote:
> On Wed, 24 Dec 2014, Ben Cooksley wrote:
>
>> Hi all,
>>
>> As the other thread has gotten a bit congested with various threads, I
>> thought I would split up the topics to make things a bit easier to
>> manage.
>>
>> The first seems the least contentious: allowing all developers to
>> delete branches on our mainline repositories, except for certain
>> protected branches (like "master" and "KDE/*" for instance).
>>
>> Any suggestions or variations on this?
>>
>> Note: the protected branches really do need to be universal across all
>> repositories to be effective - otherwise the effort required to add
>> the protection will introduce an extremely high maintenance burden.
>
>
> Would it be possible to add the Calligra/* release branches to that list, or
> should we better rename them toe KDE/*?

That brings the list of protected branches requested thus far to:

master
frameworks
KDE/*
Applications/*
Plasma/*
Calligra/*

Any others?

Please bear in mind that for each item added to the list, we need two
lines in the Gitolite configuration - per repository.
We have 747 declared (mainline) repositories at the moment.

(Fortunately the generation of this file is scripted from the
projects.kde.org database)

>
>> I'll also add that there is never a risk of work being lost courtesy
>> of the backup refs. The hooks automatically create these refs
>> (including the unix time of the event) whenever a destructive event is
>> made to a ref. The hooks will also explicitly prohibit any attempt to
>> alter the backup refs - they're read only and untouchable.
>>
>> These can be manually fetched using "git fetch" if necessary to
>> restore a branch which is mistakenly deleted.
>
>
> That's reassuring :-)

Yes, we've had this mechanism in place since our current generation of
hooks went live (Jan 2011).

>
> Boud

Thanks,
Ben




More information about the kde-core-devel mailing list