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