On Tue, Aug 13, 2019 at 12:54 PM Ben Cooksley <bcooks...@kde.org> wrote: > > On Mon, Aug 12, 2019 at 11:48 PM David Faure <fa...@kde.org> wrote: > > > > On lundi 12 août 2019 13:04:29 CEST Ben Cooksley wrote: > > > On Mon, Aug 12, 2019 at 10:54 PM Albert Vaca Cintora > > > > > > <albertv...@gmail.com> wrote: > > > > On Mon, Aug 12, 2019, 18:46 Ben Cooksley <bcooks...@kde.org> wrote: > > > >> 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. > > > > > > > > Maybe that is enough? IMO, it makes sense to not consider a bug is > > > > closed > > > > until the commit that fixes it has been merged to either master or the > > > > current stable branch. > > > > > > Unfortunately not, as both future and past stable branches have been > > > used in the past by distributions as a source of patches for those > > > maintaining LTS releases. > > > > > > Additionally, these branches are authoritative as to what we > > > previously released > > > > That's what tags are for, not branches. > > > > > and are needed in the event we need to make > > > another release of these branches. > > > > Right. But this only happens with recent stable branches, not > > really old stuff like "enterprise3". > > > > In any case, we should be able to make a list of stable branches, > > especially if we can use wildcards like Applications/*. > > Unfortunately the problem isn't with Frameworks, Applications and > Plasma - they're easy to handle and their naming can be scripted > without too much trouble. > The problem lies with Extragear, which has a large number of projects, > all of which have different rules for what a stable branch is named.
As Albert said, the solution would be to establish a common scheme for protected branches. > For these, someone ends up with having to maintain and update that > list as needed. > > Maintaining this list would also be complicated because our hooks have > no idea whether Gitlab considers a branch protected or not - so either > our hooks handle whether force pushes are allowed or not, or we end up > duplicating the knowledge in two places. These are very solvable problems, even with a random-name schemes. We know which branches are/were used as trunk/stable and could have an automated system keeping tracking. We can also determine/manage which branches are marked protected on the gitlab side via the API. HS
