Possible to move some KF5 frameworks to invent?

[Albert Vaca Cintora]

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?

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20190812/8f8c30a8/attachment.htm>