Re: Possible to move some KF5 frameworks to invent?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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?
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 > >
Possible to move some KF5 frameworks to invent?
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 ;=) Greetings Christoph -- Ignorance is bliss... https://cullmann.io | https://kate-editor.org