[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: Possible to move some KF5 frameworks to invent?
From:       Ben Cooksley <bcooksley () kde ! org>
Date:       2019-08-13 11:40:10
Message-ID: CA+XidOH-pH1+bzEqyuUXUL4cEyb20gLKmEinyZHZKwRcUjHjBg () mail ! gmail ! com
[Download RAW message or body]

On Tue, Aug 13, 2019 at 11:27 PM Harald Sitter <sitter@kde.org> wrote:
>
> On Tue, Aug 13, 2019 at 12:54 PM Ben Cooksley <bcooksley@kde.org> wrote:
> >
> > On Mon, Aug 12, 2019 at 11:48 PM David Faure <faure@kde.org> wrote:
> > >
> > > On lundi 12 ao=C3=BBt 2019 13:04:29 CEST Ben Cooksley wrote:
> > > > On Mon, Aug 12, 2019 at 10:54 PM Albert Vaca Cintora
> > > >
> > > > <albertvaka@gmail.com> wrote:
> > > > > On Mon, Aug 12, 2019, 18:46 Ben Cooksley <bcooksley@kde.org> wrot=
e:
> > > > >> On Mon, Aug 12, 2019 at 10:37 PM Albert Vaca Cintora
> > > > >>
> > > > >> <albertvaka@gmail.com> wrote:
> > > > >> > Could we use sysadmin/repo-metadata to know which branch is st=
able and
> > > > >> > therefore should be protected and trigger the hooks for closin=
g 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 a=
nd
> > > > >> coming) stable branches are called.
> > > > >
> > > > > Maybe that is enough? IMO, it makes sense to not consider a bug i=
s closed
> > > > > until the commit that fixes it has been merged to either master o=
r the
> > > > > current stable branch.
> > > >
> > > > Unfortunately not, as both future and past stable branches have bee=
n
> > > > 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.

That would be nice if we did have a common scheme.
I'm looking at what we have currently though - which is a situation
where the names are not consistent in any form.

Note also that some of the projects in Extragear are very much fans of
"maintainer rights" and have disregarded general community policy in
the past.

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

At the moment i'm quite wary of building additional systems due to
limited resources to maintain what we do have.
I'd very much rather prefer a solution which isn't reliant on
maintaining additional infrastructure to support it.

>
> HS

Cheers,
Ben
[prev in list] [next in list] [prev in thread] [next in thread]