El dimarts, 13 d’agost de 2019, a les 13:26:43 CEST, Harald Sitter va escriure: > 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.
Actually my suggestion was a common scheme for unprotected branches. Cheers, Albert > > > 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 >