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