Possible to move some KF5 frameworks to invent?

Ben Cooksley bcooksley at kde.org
Tue Aug 13 11:53:53 BST 2019


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.

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.

>
> --
> David Faure, faure at kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>
>

Cheers,
Ben




More information about the kde-core-devel mailing list