Possible to move some KF5 frameworks to invent?

[Albert Astals Cid]

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 <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.

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
>