Possible to move some KF5 frameworks to invent?

[Ben Cooksley]

On Mon, Aug 12, 2019 at 10:37 PM Albert Vaca Cintora
<albertvaka at gmail.com> wrote:
>
> Could we use sysadmin/repo-metadata to know which branch is stable and therefore should be protected and trigger the hooks for closing bugs, etc?

Unfortunately that only tells us what the current stable branch is -
it doesn't let us know what the other (either historical or up and
coming) stable branches are called.

Cheers,
Ben

>
> On Mon, Aug 12, 2019, 17:39 Ben Cooksley <bcooksley at kde.org> wrote:
>>
>> On Mon, Aug 12, 2019 at 6:24 PM Kevin Ottens <ervin at kde.org> wrote:
>> >
>> > Hello,
>>
>> Hi Kevin,
>>
>> >
>> > On Sunday, 11 August 2019 22:14:19 CEST Albert Astals Cid wrote:
>> > > With phabricator you can do a "force push" to your review[1], with gitlab
>> > > you can not[2].
>> > > [...]
>> > > [2] without having your own fork of a repository, that is annoying for
>> > > various reasons
>> >
>> > I'm genuinely surprised about that claim. Are we sure that it's not a setting
>> > on our instance forcing this? I'm currently working on a project where you can
>> > force push in non-protected branches without your own fork.
>>
>> Our hooks prevent force pushes from taking place within our mainline
>> repositories.
>>
>> This is done for a couple of reasons.
>>
>> The first, that in order for us to reliably operate things like
>> closing of bugs on Bugzilla and sending emails and IRC Notifications,
>> it is necessary for the hooks to be able to detect when a commit is
>> "new" and therefore needs to be processed for this sort of action.
>> Unfortunately due to how Git works, there is no difference between a
>> genuinely new commit, and one that has simply been rebased - they're
>> both "new" as far as the hooks are concerned. This means we cannot
>> allow rebasing within any branch which is subject to notification or
>> other hook processing.
>>
>> The second, is that recovering your work when someone has
>> rebased/force pushed the branch underneath you, is something which is
>> non-trivial unless you are familiar with the process. Even for those
>> who are experienced, it is possible to make mistakes in the process of
>> doing so, and either lose commits or mangle the metadata associated
>> with the commit (such as the authorship information - an incident
>> which happened earlier this year). At the time KDE migrated to Git it
>> was decided on a community wide basis that familiarity with this isn't
>> something we should expect casual contributors to have.
>>
>> Those familiar to Git will be aware that it is very much possible to
>> limit the scope of hooks like our Notification hooks, while still
>> allowing them to be caught when entering branches that are subject to
>> Notification. At this time the only proposals i've seen for this have
>> been for "everything but master and stable branches" which
>> unfortunately is not a scalable solution we can support due to the
>> significant variance in schemes used for naming stable branches across
>> different projects (not without pushing the maintenance role for
>> handling all these different naming schemes on to Sysadmin)
>>
>> >
>> > Regards.
>> > --
>> > Kevin Ottens, http://ervin.ipsquad.net
>> >
>> > enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en
>>
>> Regards,
>> Ben