Re: Possible to move some KF5 frameworks to invent?

2019-08-30 Thread René J . V . Bertin
Albert Astals Cid wrote:

> I personally feel the loss of "email gets sent to kde-frameworks-devel on MR"
> is a problem.

And I find that the lack of being able to interact with tickets via email a big 
handicap.

This is also the review system now used by KDevelop where you can no longer 
submit patches that you haven't committed locally? That too is an annoyingly 
cumbersome obstacle in my workflow which will inevitably make me less inclined 
to 
contribute changes.

R.



Re: Possible to move some KF5 frameworks to invent?

2019-08-18 Thread Albert Vaca Cintora
On Mon, Aug 12, 2019, 18:46 Ben Cooksley  wrote:

> On Mon, Aug 12, 2019 at 10:37 PM Albert Vaca Cintora
>  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.


Re: Possible to move some KF5 frameworks to invent?

2019-08-18 Thread Albert Vaca Cintora
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?

On Mon, Aug 12, 2019, 17:39 Ben Cooksley  wrote:

> On Mon, Aug 12, 2019 at 6:24 PM Kevin Ottens  wrote:
> >
> > Hello,
>
> Hi Kevin,
>
> >
> > On Sunday, 11 August 2019 22:14:19 CEST Albert Astals Cid wrote:
> > > With phabricator you can do a "force push" to your review[1], with
> gitlab
> > > you can not[2].
> > > [...]
> > > [2] without having your own fork of a repository, that is annoying for
> > > various reasons
> >
> > I'm genuinely surprised about that claim. Are we sure that it's not a
> setting
> > on our instance forcing this? I'm currently working on a project where
> you can
> > force push in non-protected branches without your own fork.
>
> Our hooks prevent force pushes from taking place within our mainline
> repositories.
>
> This is done for a couple of reasons.
>
> The first, that in order for us to reliably operate things like
> closing of bugs on Bugzilla and sending emails and IRC Notifications,
> it is necessary for the hooks to be able to detect when a commit is
> "new" and therefore needs to be processed for this sort of action.
> Unfortunately due to how Git works, there is no difference between a
> genuinely new commit, and one that has simply been rebased - they're
> both "new" as far as the hooks are concerned. This means we cannot
> allow rebasing within any branch which is subject to notification or
> other hook processing.
>
> The second, is that recovering your work when someone has
> rebased/force pushed the branch underneath you, is something which is
> non-trivial unless you are familiar with the process. Even for those
> who are experienced, it is possible to make mistakes in the process of
> doing so, and either lose commits or mangle the metadata associated
> with the commit (such as the authorship information - an incident
> which happened earlier this year). At the time KDE migrated to Git it
> was decided on a community wide basis that familiarity with this isn't
> something we should expect casual contributors to have.
>
> Those familiar to Git will be aware that it is very much possible to
> limit the scope of hooks like our Notification hooks, while still
> allowing them to be caught when entering branches that are subject to
> Notification. At this time the only proposals i've seen for this have
> been for "everything but master and stable branches" which
> unfortunately is not a scalable solution we can support due to the
> significant variance in schemes used for naming stable branches across
> different projects (not without pushing the maintenance role for
> handling all these different naming schemes on to Sysadmin)
>
> >
> > Regards.
> > --
> > Kevin Ottens, http://ervin.ipsquad.net
> >
> > enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en
>
> Regards,
> Ben
>


Re: Possible to move some KF5 frameworks to invent?

2019-08-17 Thread Ben Cooksley
On Fri, Aug 16, 2019 at 6:30 AM Christoph Cullmann
 wrote:
>
> Hi,

Hi Christoph,

>
> >> perhaps this would be some good BoF at Akademy:
> >>
> >> What is needed to move frameworks development to invent.kde.org.
> >>
> >> (I assume we want to do that some when in the future anyways)
> >
> > At this point my planning expected that Frameworks would move when the
> > rest of KDE moves (which will likely be a massive migration that
> > happens in very quick succession once everything is ready).
>
> is there some timeline known when this might happen?
> And is there some help needed to handle the transition?

At the moment the timeline is dependent on three pre-requisites being fulfilled.
Those are:
1) Completion of the replacement to our anongit system
2) Completion of the Identity <-> Gitlab sync component, to ensure
changes to group (as well as people's names and email addresses)
3) Finalisation of the process to import all our existing repositories
into Gitlab

At this time, the replacement anongit system is partially written,
with some parts still left to finish. With regards to the Identity
sync, that has been fully planned, but no code has been written yet.

The importing of the repositories is the simplest of the three items
to put together, and has also been fully planned (the actual creation
of the repositories and importing their contents is part of Gitlab's
core functionality, we just have to provide an file system
representation of how the repositories are to be laid out). Part of
this also required preparing a plan on how the repositories will be
structured (layout wise) on Gitlab - which has also been completed.

>
> Btw., thanks already for all the work you and others did on improving
> our infrastructure!
>
> Greetings
> Christoph

Cheers,
Ben

>
> --
> Ignorance is bliss...
> https://cullmann.io | https://kate-editor.org


Re: Possible to move some KF5 frameworks to invent?

2019-08-15 Thread Christoph Cullmann

Hi,


perhaps this would be some good BoF at Akademy:

What is needed to move frameworks development to invent.kde.org.

(I assume we want to do that some when in the future anyways)


At this point my planning expected that Frameworks would move when the
rest of KDE moves (which will likely be a massive migration that
happens in very quick succession once everything is ready).


is there some timeline known when this might happen?
And is there some help needed to handle the transition?

Btw., thanks already for all the work you and others did on improving
our infrastructure!

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org


Re: Possible to move some KF5 frameworks to invent?

2019-08-14 Thread Ben Cooksley
On Wed, Aug 14, 2019 at 8:25 AM Albert Astals Cid  wrote:
>
> 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  wrote:
> > >
> > > On Mon, Aug 12, 2019 at 11:48 PM David Faure  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
> > > > >
> > > > >  wrote:
> > > > > > On Mon, Aug 12, 2019, 18:46 Ben Cooksley  wrote:
> > > > > >> On Mon, Aug 12, 2019 at 10:37 PM Albert Vaca Cintora
> > > > > >>
> > > > > >>  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.

This would definitely be something that would be easy to maintain on
the Infrastructure side, while also making it clear to anyone working
with it that force pushes are a possibility.

>
> Cheers,
>   Albert

Cheers,
Ben

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


Re: Possible to move some KF5 frameworks to invent?

2019-08-14 Thread Ben Cooksley
On Wed, Aug 14, 2019 at 9:07 AM Christoph Cullmann
 wrote:
>
> Hi,
>
> >> > 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.
>
> perhaps this would be some good BoF at Akademy:
>
> What is needed to move frameworks development to invent.kde.org.
>
> (I assume we want to do that some when in the future anyways)

At this point my planning expected that Frameworks would move when the
rest of KDE moves (which will likely be a massive migration that
happens in very quick succession once everything is ready).

>
> Greetings
> Christoph

Cheers,
Ben

>
> --
> Ignorance is bliss...
> https://cullmann.io | https://kate-editor.org


Re: Possible to move some KF5 frameworks to invent?

2019-08-13 Thread Christoph Cullmann

Hi,


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


perhaps this would be some good BoF at Akademy:

What is needed to move frameworks development to invent.kde.org.

(I assume we want to do that some when in the future anyways)

Greetings
Christoph

--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org


Re: Possible to move some KF5 frameworks to invent?

2019-08-13 Thread 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  wrote:
> >
> > On Mon, Aug 12, 2019 at 11:48 PM David Faure  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
> > > >
> > > >  wrote:
> > > > > On Mon, Aug 12, 2019, 18:46 Ben Cooksley  wrote:
> > > > >> On Mon, Aug 12, 2019 at 10:37 PM Albert Vaca Cintora
> > > > >>
> > > > >>  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
> 






Re: Possible to move some KF5 frameworks to invent?

2019-08-13 Thread Ben Cooksley
On Tue, Aug 13, 2019 at 11:27 PM Harald Sitter  wrote:
>
> On Tue, Aug 13, 2019 at 12:54 PM Ben Cooksley  wrote:
> >
> > On Mon, Aug 12, 2019 at 11:48 PM David Faure  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
> > > >
> > > >  wrote:
> > > > > On Mon, Aug 12, 2019, 18:46 Ben Cooksley  wrote:
> > > > >> On Mon, Aug 12, 2019 at 10:37 PM Albert Vaca Cintora
> > > > >>
> > > > >>  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.

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


Re: Possible to move some KF5 frameworks to invent?

2019-08-13 Thread Harald Sitter
On Tue, Aug 13, 2019 at 12:54 PM Ben Cooksley  wrote:
>
> On Mon, Aug 12, 2019 at 11:48 PM David Faure  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
> > >
> > >  wrote:
> > > > On Mon, Aug 12, 2019, 18:46 Ben Cooksley  wrote:
> > > >> On Mon, Aug 12, 2019 at 10:37 PM Albert Vaca Cintora
> > > >>
> > > >>  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


Re: Possible to move some KF5 frameworks to invent?

2019-08-13 Thread Ben Cooksley
On Mon, Aug 12, 2019 at 11:48 PM David Faure  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
> >
> >  wrote:
> > > On Mon, Aug 12, 2019, 18:46 Ben Cooksley  wrote:
> > >> On Mon, Aug 12, 2019 at 10:37 PM Albert Vaca Cintora
> > >>
> > >>  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, fa...@kde.org, http://www.davidfaure.fr
> Working on KDE Frameworks 5
>
>
>

Cheers,
Ben


Re: Possible to move some KF5 frameworks to invent?

2019-08-13 Thread Kevin Ottens
Hello,

On Monday, 12 August 2019 13:48:46 CEST David Faure wrote:
> In any case, we should be able to make a list of stable branches,
> especially if we can use wildcards like Applications/*.

And that's kind of the way GitLab works IIUC. By default only master is 
protected, but you can set extra rules based on such a wildcards scheme. 
Beside, this would put some order to that naming going forward, I see that as 
a bonus.

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.


Re: Possible to move some KF5 frameworks to invent?

2019-08-12 Thread Albert Astals Cid
El dilluns, 12 d’agost de 2019, a les 11:38:50 CEST, Ben Cooksley va escriure:
> Those familiar to Git will be aware that it is very much possible to
> limit the scope of hooks like our Notification hooks, while still
> allowing them to be caught when entering branches that are subject to
> Notification. At this time the only proposals i've seen for this have
> been for "everything but master and stable branches" which
> unfortunately is not a scalable solution we can support due to the
> significant variance in schemes used for naming stable branches across
> different projects (not without pushing the maintenance role for
> handling all these different naming schemes on to Sysadmin)

You have not read my email then ;)

I suggested to do it the other way around and allow force push on branches 
named review_*

This solves the problem of "naming of important branches is not consistent" by 
making consistent the "naming of the non important branches"

Cheers,
  Albert

> 
> >
> > Regards.
> > --
> > Kevin Ottens, http://ervin.ipsquad.net
> >
> > enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en
> 
> Regards,
> Ben
> 






Re: Possible to move some KF5 frameworks to invent?

2019-08-12 Thread David Faure
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
> 
>  wrote:
> > On Mon, Aug 12, 2019, 18:46 Ben Cooksley  wrote:
> >> On Mon, Aug 12, 2019 at 10:37 PM Albert Vaca Cintora
> >> 
> >>  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/*.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: Possible to move some KF5 frameworks to invent?

2019-08-12 Thread Ben Cooksley
On Mon, Aug 12, 2019 at 10:54 PM Albert Vaca Cintora
 wrote:
>
>
> On Mon, Aug 12, 2019, 18:46 Ben Cooksley  wrote:
>>
>> On Mon, Aug 12, 2019 at 10:37 PM Albert Vaca Cintora
>>  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, and are needed in the event we need to make
another release of these branches.

We therefore need to operate notification hooks on all stable
branches, past, present and future.

Cheers,
Ben


Re: Possible to move some KF5 frameworks to invent?

2019-08-12 Thread Ben Cooksley
On Mon, Aug 12, 2019 at 10:37 PM Albert Vaca Cintora
 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.

Cheers,
Ben

>
> On Mon, Aug 12, 2019, 17:39 Ben Cooksley  wrote:
>>
>> On Mon, Aug 12, 2019 at 6:24 PM Kevin Ottens  wrote:
>> >
>> > Hello,
>>
>> Hi Kevin,
>>
>> >
>> > On Sunday, 11 August 2019 22:14:19 CEST Albert Astals Cid wrote:
>> > > With phabricator you can do a "force push" to your review[1], with gitlab
>> > > you can not[2].
>> > > [...]
>> > > [2] without having your own fork of a repository, that is annoying for
>> > > various reasons
>> >
>> > I'm genuinely surprised about that claim. Are we sure that it's not a 
>> > setting
>> > on our instance forcing this? I'm currently working on a project where you 
>> > can
>> > force push in non-protected branches without your own fork.
>>
>> Our hooks prevent force pushes from taking place within our mainline
>> repositories.
>>
>> This is done for a couple of reasons.
>>
>> The first, that in order for us to reliably operate things like
>> closing of bugs on Bugzilla and sending emails and IRC Notifications,
>> it is necessary for the hooks to be able to detect when a commit is
>> "new" and therefore needs to be processed for this sort of action.
>> Unfortunately due to how Git works, there is no difference between a
>> genuinely new commit, and one that has simply been rebased - they're
>> both "new" as far as the hooks are concerned. This means we cannot
>> allow rebasing within any branch which is subject to notification or
>> other hook processing.
>>
>> The second, is that recovering your work when someone has
>> rebased/force pushed the branch underneath you, is something which is
>> non-trivial unless you are familiar with the process. Even for those
>> who are experienced, it is possible to make mistakes in the process of
>> doing so, and either lose commits or mangle the metadata associated
>> with the commit (such as the authorship information - an incident
>> which happened earlier this year). At the time KDE migrated to Git it
>> was decided on a community wide basis that familiarity with this isn't
>> something we should expect casual contributors to have.
>>
>> Those familiar to Git will be aware that it is very much possible to
>> limit the scope of hooks like our Notification hooks, while still
>> allowing them to be caught when entering branches that are subject to
>> Notification. At this time the only proposals i've seen for this have
>> been for "everything but master and stable branches" which
>> unfortunately is not a scalable solution we can support due to the
>> significant variance in schemes used for naming stable branches across
>> different projects (not without pushing the maintenance role for
>> handling all these different naming schemes on to Sysadmin)
>>
>> >
>> > Regards.
>> > --
>> > Kevin Ottens, http://ervin.ipsquad.net
>> >
>> > enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en
>>
>> Regards,
>> Ben


Re: Possible to move some KF5 frameworks to invent?

2019-08-12 Thread Ben Cooksley
On Mon, Aug 12, 2019 at 6:24 PM Kevin Ottens  wrote:
>
> Hello,

Hi Kevin,

>
> On Sunday, 11 August 2019 22:14:19 CEST Albert Astals Cid wrote:
> > With phabricator you can do a "force push" to your review[1], with gitlab
> > you can not[2].
> > [...]
> > [2] without having your own fork of a repository, that is annoying for
> > various reasons
>
> I'm genuinely surprised about that claim. Are we sure that it's not a setting
> on our instance forcing this? I'm currently working on a project where you can
> force push in non-protected branches without your own fork.

Our hooks prevent force pushes from taking place within our mainline
repositories.

This is done for a couple of reasons.

The first, that in order for us to reliably operate things like
closing of bugs on Bugzilla and sending emails and IRC Notifications,
it is necessary for the hooks to be able to detect when a commit is
"new" and therefore needs to be processed for this sort of action.
Unfortunately due to how Git works, there is no difference between a
genuinely new commit, and one that has simply been rebased - they're
both "new" as far as the hooks are concerned. This means we cannot
allow rebasing within any branch which is subject to notification or
other hook processing.

The second, is that recovering your work when someone has
rebased/force pushed the branch underneath you, is something which is
non-trivial unless you are familiar with the process. Even for those
who are experienced, it is possible to make mistakes in the process of
doing so, and either lose commits or mangle the metadata associated
with the commit (such as the authorship information - an incident
which happened earlier this year). At the time KDE migrated to Git it
was decided on a community wide basis that familiarity with this isn't
something we should expect casual contributors to have.

Those familiar to Git will be aware that it is very much possible to
limit the scope of hooks like our Notification hooks, while still
allowing them to be caught when entering branches that are subject to
Notification. At this time the only proposals i've seen for this have
been for "everything but master and stable branches" which
unfortunately is not a scalable solution we can support due to the
significant variance in schemes used for naming stable branches across
different projects (not without pushing the maintenance role for
handling all these different naming schemes on to Sysadmin)

>
> Regards.
> --
> Kevin Ottens, http://ervin.ipsquad.net
>
> enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en

Regards,
Ben


Re: Possible to move some KF5 frameworks to invent?

2019-08-12 Thread Kevin Ottens
Hello,

On Sunday, 11 August 2019 22:14:19 CEST Albert Astals Cid wrote:
> With phabricator you can do a "force push" to your review[1], with gitlab
> you can not[2].
> [...]
> [2] without having your own fork of a repository, that is annoying for
> various reasons

I'm genuinely surprised about that claim. Are we sure that it's not a setting 
on our instance forcing this? I'm currently working on a project where you can 
force push in non-protected branches without your own fork.

Regards.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud patron of KDE, https://hc.enioka.com/en

signature.asc
Description: This is a digitally signed message part.


Re: Possible to move some KF5 frameworks to invent?

2019-08-11 Thread Harald Sitter
On Mon, Aug 12, 2019 at 12:23 AM David Faure  wrote:
>
> On dimanche 11 août 2019 22:14:19 CEST Albert Astals Cid wrote:
> > without having your own fork of a repository, that is annoying for various
> > reasons
>
> If creating a fork can be scripted, then that could be a fallback solution
> (to the problem of "committing everywhere" like some of us do).

https://docs.gitlab.com/ce/api/projects.html#fork-project

there are gitlab CLIs in various languages which I expect already
implement this in an easy to use fashion

HS


Re: Possible to move some KF5 frameworks to invent?

2019-08-11 Thread David Faure
On dimanche 11 août 2019 22:14:19 CEST Albert Astals Cid wrote:
> without having your own fork of a repository, that is annoying for various
> reasons

If creating a fork can be scripted, then that could be a fallback solution
(to the problem of "committing everywhere" like some of us do).

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: Possible to move some KF5 frameworks to invent?

2019-08-11 Thread David Faure
On dimanche 11 août 2019 12:33:19 CEST Christoph Cullmann wrote:
> Hi,
> 
> is it possible to move individual framework modules over to
> invent.kde.org or will that be
> done at once somewhen in the future?
> 
> Would be interested to move syntax-highlighting and ktexteditor if that
> is possible.
> But if that shall be done as bulk in the future I can wait ;=)

I object to "some frameworks" moving, it will complicate all automation.

If we move frameworks, then we move all of them in one go.

-- 
David Faure, fa...@kde.org, http://www.davidfaure.fr
Working on KDE Frameworks 5





Re: Possible to move some KF5 frameworks to invent?

2019-08-11 Thread Albert Astals Cid
El diumenge, 11 d’agost de 2019, a les 21:00:13 CEST, Ben Cooksley va escriure:
> On Mon, Aug 12, 2019 at 2:53 AM Albert Astals Cid  wrote:
> >
> > El diumenge, 11 d’agost de 2019, a les 12:33:19 CEST, Christoph Cullmann va 
> > escriure:
> > > Hi,
> > >
> > > is it possible to move individual framework modules over to
> > > invent.kde.org or will that be
> > > done at once somewhen in the future?
> >
> > Seems kde-frameworks-devel would be a better list to ask about this.
> >
> > >
> > > Would be interested to move syntax-highlighting and ktexteditor if that
> > > is possible.
> > > But if that shall be done as bulk in the future I can wait ;=)
> >
> > I personally feel the loss of "email gets sent to kde-frameworks-devel on 
> > MR" is a problem.
> >
> > Also i remember dfaure not being very thrilled about the "not possible to 
> > force push to 'my branches' on the main repo" issue.
> 
> There has been no change with regard to force pushes - they were
> restricted on main line repositories back when we initially moved to
> Git and have continued to be restricted through our move to
> Phabricator (from Reviewboard) and now on to Gitlab.

Yes and no.

Yes, there's been no change with regard to force pushes

*BUT*

With phabricator you can do a "force push" to your review[1], with gitlab you 
can not[2].

So while technically there has no been a change, the resulting workflow is now 
that you can't do the same you used to do.

So having a regexp (e.g. something like all branches starting by review_*) that 
allowed all those branches to be force pushed would help being able to maintain 
the workflow in which without having to fork a repository you can update your 
commits for reviews.

Cheers,
  Albert

[1] i.e. you make changes to your commit, run arc diff again and the new commit 
shows up in the existing review as a single commit
[2] without having your own fork of a repository, that is annoying for various 
reasons

> 
> >
> > Cheers,
> >   Albert
> 
> Regards,
> Ben
> 
> >
> > >
> > > Greetings
> > > Christoph
> > >
> > >
> >
> >
> >
> >
> 






Re: Possible to move some KF5 frameworks to invent?

2019-08-11 Thread Ben Cooksley
On Mon, Aug 12, 2019 at 2:53 AM Albert Astals Cid  wrote:
>
> El diumenge, 11 d’agost de 2019, a les 12:33:19 CEST, Christoph Cullmann va 
> escriure:
> > Hi,
> >
> > is it possible to move individual framework modules over to
> > invent.kde.org or will that be
> > done at once somewhen in the future?
>
> Seems kde-frameworks-devel would be a better list to ask about this.
>
> >
> > Would be interested to move syntax-highlighting and ktexteditor if that
> > is possible.
> > But if that shall be done as bulk in the future I can wait ;=)
>
> I personally feel the loss of "email gets sent to kde-frameworks-devel on MR" 
> is a problem.
>
> Also i remember dfaure not being very thrilled about the "not possible to 
> force push to 'my branches' on the main repo" issue.

There has been no change with regard to force pushes - they were
restricted on main line repositories back when we initially moved to
Git and have continued to be restricted through our move to
Phabricator (from Reviewboard) and now on to Gitlab.

>
> Cheers,
>   Albert

Regards,
Ben

>
> >
> > Greetings
> > Christoph
> >
> >
>
>
>
>


Re: Possible to move some KF5 frameworks to invent?

2019-08-11 Thread Christoph Cullmann

On 2019-08-11 16:53, Albert Astals Cid wrote:

El diumenge, 11 d’agost de 2019, a les 12:33:19 CEST, Christoph
Cullmann va escriure:

Hi,

is it possible to move individual framework modules over to
invent.kde.org or will that be
done at once somewhen in the future?


Seems kde-frameworks-devel would be a better list to ask about this.

You are right ;=)





Would be interested to move syntax-highlighting and ktexteditor if 
that

is possible.
But if that shall be done as bulk in the future I can wait ;=)


I personally feel the loss of "email gets sent to kde-frameworks-devel
on MR" is a problem.


Hmm, shouldn't we be able to fix that with adding some 
"kde-frameworks-devel" user
to our gitlab instance that configures it's notification mail address 
for the KDE

group to kde-frameworks-devel@?



Also i remember dfaure not being very thrilled about the "not possible
to force push to 'my branches' on the main repo" issue.
Therefore I CC'ed David, as he needs to be ok with this anyways doing 
the

whole release work.

Greetings
Christoph



Cheers,
  Albert



Greetings
Christoph




--
Ignorance is bliss...
https://cullmann.io | https://kate-editor.org


Re: Possible to move some KF5 frameworks to invent?

2019-08-11 Thread Albert Astals Cid
El diumenge, 11 d’agost de 2019, a les 12:33:19 CEST, Christoph Cullmann va 
escriure:
> Hi,
> 
> is it possible to move individual framework modules over to 
> invent.kde.org or will that be
> done at once somewhen in the future?

Seems kde-frameworks-devel would be a better list to ask about this.

> 
> Would be interested to move syntax-highlighting and ktexteditor if that 
> is possible.
> But if that shall be done as bulk in the future I can wait ;=)

I personally feel the loss of "email gets sent to kde-frameworks-devel on MR" 
is a problem.

Also i remember dfaure not being very thrilled about the "not possible to force 
push to 'my branches' on the main repo" issue.

Cheers,
  Albert

> 
> Greetings
> Christoph
> 
>