[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Possible to move some KF5 frameworks to invent?
From:       Ben Cooksley <bcooksley () kde ! org>
Date:       2019-08-12 10:46:23
Message-ID: CA+XidOGopRWv-fJYfDhLX5DFrkt-HUFm6qM4-ZkUOfj_pYW92g () mail ! gmail ! com
[Download RAW message or body]

On Mon, Aug 12, 2019 at 10:37 PM Albert Vaca Cintora
<albertvaka@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@kde.org> wrote:
> > 
> > On Mon, Aug 12, 2019 at 6:24 PM Kevin Ottens <ervin@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


[prev in list] [next in list] [prev in thread] [next in thread]