Possible to move some KF5 frameworks to invent?

[Harald Sitter]

On Tue, Aug 13, 2019 at 12:54 PM Ben Cooksley <bcooksley at kde.org> wrote:
>
> On Mon, Aug 12, 2019 at 11:48 PM David Faure <faure at 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
> > >
> > > <albertvaka at gmail.com> wrote:
> > > > On Mon, Aug 12, 2019, 18:46 Ben Cooksley <bcooksley at kde.org> wrote:
> > > >> On Mon, Aug 12, 2019 at 10:37 PM Albert Vaca Cintora
> > > >>
> > > >> <albertvaka at 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