Re: Changes to Phabricator review subscriptions
On Wednesday, May 9, 2018 10:08:28 AM CEST you wrote: > Hi all, > > To improve the user experience around email and in-application > notifications from Phabricator, sysadmin have made some changes to the > configuration of our Herald rules. > > Going forward, instead of subscribing projects to reviews, we will > only be subscribing mailing lists now. So, should we now get all phabricator mail at, say, kimages...@kde.org, or should we create a second mailing list, say krita-p...@kde.org? I do want to receive mail for everything krita-related that happens on phabricator! > For those reviews which have > already been created, they will be updated to reflect the new practice > the next time they are changed. > > This means that individual project members will no longer receive > notifications and emails for every single review or task change that > affects their project. Instead, they will only receive notifications > and emails for reviews they have been individually subscribed to. :-( > > To help this change take full effect, it would be appreciated if > people refrain from adding Projects as reviewers, as that will have > the effect of subscribing the Project to the review as well But what if that's what a project really wants? > (Phabricator does not require you specify a reviewer) I know. Most newcomers don't and do not specify any reviewer, so review requests often fall between the cracks. > Should anyone have any questions regarding this, please open a thread > on the kde-devel@kde.org mailing list. I discovered today that I did not have a subscription to this list and that there are no archives, so I've missed all discussions, if there have been any. I would have expected the discussion to happen on kde-community, but maybe we just have too many mailing lists. -- Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org
Re: Changes to Phabricator review subscriptions
Le 09/05/2018 à 10:33, Boudewijn Rempt a écrit : On Wednesday, May 9, 2018 10:08:28 AM CEST you wrote: Hi all, To improve the user experience around email and in-application notifications from Phabricator, sysadmin have made some changes to the configuration of our Herald rules. Going forward, instead of subscribing projects to reviews, we will only be subscribing mailing lists now. So, should we now get all phabricator mail at, say, kimages...@kde.org, or should we create a second mailing list, say krita-p...@kde.org? I do want to receive mail for everything krita-related that happens on phabricator! For those reviews which have already been created, they will be updated to reflect the new practice the next time they are changed. This means that individual project members will no longer receive notifications and emails for every single review or task change that affects their project. Instead, they will only receive notifications and emails for reviews they have been individually subscribed to. :-( To help this change take full effect, it would be appreciated if people refrain from adding Projects as reviewers, as that will have the effect of subscribing the Project to the review as well But what if that's what a project really wants? That is also exactly what we use to do in GCompris... it's the best solution for us to easily connect the diff to the relevant group of people. Subscribing our current mailing list is surely not what we want. (Phabricator does not require you specify a reviewer) I know. Most newcomers don't and do not specify any reviewer, so review requests often fall between the cracks. Should anyone have any questions regarding this, please open a thread on the kde-devel@kde.org mailing list. I discovered today that I did not have a subscription to this list and that there are no archives, so I've missed all discussions, if there have been any. I would have expected the discussion to happen on kde-community, but maybe we just have too many mailing lists. I am subscribed to this list but didn't see much discussion on the topic before this change announcement. Timothée
Re: Changes to Phabricator review subscriptions
On Wed, May 9, 2018 at 8:33 PM, Boudewijn Rempt wrote: > On Wednesday, May 9, 2018 10:08:28 AM CEST you wrote: >> Hi all, >> >> To improve the user experience around email and in-application >> notifications from Phabricator, sysadmin have made some changes to the >> configuration of our Herald rules. >> >> Going forward, instead of subscribing projects to reviews, we will >> only be subscribing mailing lists now. > > So, should we now get all phabricator mail at, say, kimages...@kde.org, or > should we create a second mailing list, say krita-p...@kde.org? I do want to > receive mail for everything krita-related that happens on phabricator! That decision is up to individual projects. To date most have opted to treat Phabricator like Reviewboard and have it sent to their usual project mailing list. > >> For those reviews which have >> already been created, they will be updated to reflect the new practice >> the next time they are changed. >> >> This means that individual project members will no longer receive >> notifications and emails for every single review or task change that >> affects their project. Instead, they will only receive notifications >> and emails for reviews they have been individually subscribed to. > > :-( > >> >> To help this change take full effect, it would be appreciated if >> people refrain from adding Projects as reviewers, as that will have >> the effect of subscribing the Project to the review as well > > But what if that's what a project really wants? This change was made due to a series of complaints Sysadmin received noting that people were finding their Phabricator notification queues useless, and who had also taken the step of filtering all mail they received from Phabricator to a folder they never read. This defeats the entire purpose of the system, and also means that reviews which require that person's explicit attention were being missed. It also meant people weren't responding to Sysadmin responses to tickets these people had filed. > >> (Phabricator does not require you specify a reviewer) > > I know. Most newcomers don't and do not specify any reviewer, so review > requests often fall between the cracks. It was originally envisioned that every repository should have been caught by one or more Herald rules which would have ensured mailing lists were notified that the review had been created, hence why reviewers weren't needed. > >> Should anyone have any questions regarding this, please open a thread >> on the kde-devel@kde.org mailing list. > > > I discovered today that I did not have a subscription to this list and that > there are no archives, so I've missed all discussions, if there have been any. > I would have expected the discussion to happen on kde-community, but maybe we > just have too many mailing lists. There wasn't a discussion in advance of this change as the perceived impact was minimal (we simply substituted projects for mailing lists in the Herald rules) No Herald rules were removed. Looking at our list of rules it seems that Krita doesn't have any rules so it looks like you may have always been missing out on these notifications! > > > -- > Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org Cheers, Ben
Re: Changes to Phabricator review subscriptions
On Wed, May 9, 2018 at 9:25 PM, Timothée Giet wrote: > Le 09/05/2018 à 10:33, Boudewijn Rempt a écrit : >> >> On Wednesday, May 9, 2018 10:08:28 AM CEST you wrote: >>> >>> Hi all, >>> >>> To improve the user experience around email and in-application >>> notifications from Phabricator, sysadmin have made some changes to the >>> configuration of our Herald rules. >>> >>> Going forward, instead of subscribing projects to reviews, we will >>> only be subscribing mailing lists now. >> >> So, should we now get all phabricator mail at, say, kimages...@kde.org, or >> should we create a second mailing list, say krita-p...@kde.org? I do want >> to >> receive mail for everything krita-related that happens on phabricator! >> >>> For those reviews which have >>> already been created, they will be updated to reflect the new practice >>> the next time they are changed. >>> >>> This means that individual project members will no longer receive >>> notifications and emails for every single review or task change that >>> affects their project. Instead, they will only receive notifications >>> and emails for reviews they have been individually subscribed to. >> >> :-( >> >>> To help this change take full effect, it would be appreciated if >>> people refrain from adding Projects as reviewers, as that will have >>> the effect of subscribing the Project to the review as well >> >> But what if that's what a project really wants? > > > That is also exactly what we use to do in GCompris... it's the best solution > for us to easily connect the diff to the relevant group of people. > Subscribing our current mailing list is surely not what we want. If you could elaborate on your use case here that would be appreciated. Traditionally most development has taken place via mailing lists, so it's interesting to see people who don't follow that model. (To date all Herald rule setup requests have been for mailing lists) I note that GCompris also doesn't appear to have any rules setup, which is possibly why this hasn't come up before. > >> >>> (Phabricator does not require you specify a reviewer) >> >> I know. Most newcomers don't and do not specify any reviewer, so review >> requests often fall between the cracks. >>> >>> Should anyone have any questions regarding this, please open a thread >>> on the kde-devel@kde.org mailing list. >> >> >> I discovered today that I did not have a subscription to this list and >> that >> there are no archives, so I've missed all discussions, if there have been >> any. >> I would have expected the discussion to happen on kde-community, but maybe >> we >> just have too many mailing lists. > > > I am subscribed to this list but didn't see much discussion on the topic > before this change announcement. > > Timothée > > Cheers, Ben
Re: Changes to Phabricator review subscriptions
On Wed, May 9, 2018 at 9:47 PM, Milian Wolff wrote: > On Mittwoch, 9. Mai 2018 10:08:28 CEST Ben Cooksley wrote: >> Hi all, >> >> To improve the user experience around email and in-application >> notifications from Phabricator, sysadmin have made some changes to the >> configuration of our Herald rules. >> >> Going forward, instead of subscribing projects to reviews, we will >> only be subscribing mailing lists now. For those reviews which have >> already been created, they will be updated to reflect the new practice >> the next time they are changed. >> >> This means that individual project members will no longer receive >> notifications and emails for every single review or task change that >> affects their project. Instead, they will only receive notifications >> and emails for reviews they have been individually subscribed to. >> >> To help this change take full effect, it would be appreciated if >> people refrain from adding Projects as reviewers, as that will have >> the effect of subscribing the Project to the review as well >> (Phabricator does not require you specify a reviewer) >> >> Should anyone have any questions regarding this, please open a thread >> on the kde-devel@kde.org mailing list. > > Is there a way to opt-in to the old behavior somehow? Or I can somehow > manually register myself on phabricator to be notified about $anything that > affects a given repo? > > I ask mainly for smaller projects like heaptrack, which don't even have a > mailing list afaik. Please note that anyone who hasn't had a Herald rule explicitly setup for them is unaffected by this (this includes Heaptrack, as well as Krita and GCompris) The changes I made a few hours ago were only to Herald rules. For projects which lack mailing lists (like Kile) we will continue to subscribe Projects (as the level of traffic should be much lower and there is no other option for notifying those involved). This change was principally made for larger projects (who have mailing lists) and whose activity levels and number of people involved make notifications and email to everyone and the mailing list unusable. > > Bye > > -- > Milian Wolff > m...@milianw.de > http://milianw.de Regards, Ben
Re: Changes to Phabricator review subscriptions
Le 09/05/2018 à 12:11, Ben Cooksley a écrit : On Wed, May 9, 2018 at 9:25 PM, Timothée Giet wrote: Le 09/05/2018 à 10:33, Boudewijn Rempt a écrit : On Wednesday, May 9, 2018 10:08:28 AM CEST you wrote: Hi all, To improve the user experience around email and in-application notifications from Phabricator, sysadmin have made some changes to the configuration of our Herald rules. Going forward, instead of subscribing projects to reviews, we will only be subscribing mailing lists now. So, should we now get all phabricator mail at, say, kimages...@kde.org, or should we create a second mailing list, say krita-p...@kde.org? I do want to receive mail for everything krita-related that happens on phabricator! For those reviews which have already been created, they will be updated to reflect the new practice the next time they are changed. This means that individual project members will no longer receive notifications and emails for every single review or task change that affects their project. Instead, they will only receive notifications and emails for reviews they have been individually subscribed to. :-( To help this change take full effect, it would be appreciated if people refrain from adding Projects as reviewers, as that will have the effect of subscribing the Project to the review as well But what if that's what a project really wants? That is also exactly what we use to do in GCompris... it's the best solution for us to easily connect the diff to the relevant group of people. Subscribing our current mailing list is surely not what we want. If you could elaborate on your use case here that would be appreciated. Traditionally most development has taken place via mailing lists, so it's interesting to see people who don't follow that model. (To date all Herald rule setup requests have been for mailing lists) I note that GCompris also doesn't appear to have any rules setup, which is possibly why this hasn't come up before. Thanks a lot Ben for the clarification :) So it seems we are unaffected by the change and can continue to work like we do. To elaborate as you asked for it, we try to use phabricator as much as possible for task management and review request. For review requests we ask people to add GCompris or one of the appropriate subprojects (like GCompris: Improvements) as Group-reviewer. This way all people subscribed to this project/sub-project gets a mail notification, but most importantly has it listed in his https://phabricator.kde.org/differential/ See http://gcompris.net/wiki/Contribution_process , especially "Asking for a Review Request" It seems that Krita is doing the same, since I also see lot of diffs with Krita reviewer in my list and notifications (which I also like to have ;) ) Only "issue" for me is I have some mail duplicates from kde-edu list. It would be great to find a way to avoid them, but if not possible I can live with that. Our devel mailing list is now mostly used for occasional wider dev communication, and for occasional contributors. Cheers, Timothée
Re: Changes to Phabricator review subscriptions
On Wed, May 9, 2018 at 10:45 PM, Timothée Giet wrote: > Le 09/05/2018 à 12:11, Ben Cooksley a écrit : >> >> On Wed, May 9, 2018 at 9:25 PM, Timothée Giet wrote: >>> >>> Le 09/05/2018 à 10:33, Boudewijn Rempt a écrit : On Wednesday, May 9, 2018 10:08:28 AM CEST you wrote: > > Hi all, > > To improve the user experience around email and in-application > notifications from Phabricator, sysadmin have made some changes to the > configuration of our Herald rules. > > Going forward, instead of subscribing projects to reviews, we will > only be subscribing mailing lists now. So, should we now get all phabricator mail at, say, kimages...@kde.org, or should we create a second mailing list, say krita-p...@kde.org? I do want to receive mail for everything krita-related that happens on phabricator! > For those reviews which have > already been created, they will be updated to reflect the new practice > the next time they are changed. > > This means that individual project members will no longer receive > notifications and emails for every single review or task change that > affects their project. Instead, they will only receive notifications > and emails for reviews they have been individually subscribed to. :-( > To help this change take full effect, it would be appreciated if > people refrain from adding Projects as reviewers, as that will have > the effect of subscribing the Project to the review as well But what if that's what a project really wants? >>> >>> >>> That is also exactly what we use to do in GCompris... it's the best >>> solution >>> for us to easily connect the diff to the relevant group of people. >>> Subscribing our current mailing list is surely not what we want. >> >> If you could elaborate on your use case here that would be appreciated. >> Traditionally most development has taken place via mailing lists, so >> it's interesting to see people who don't follow that model. >> >> (To date all Herald rule setup requests have been for mailing lists) >> >> I note that GCompris also doesn't appear to have any rules setup, >> which is possibly why this hasn't come up before. >> > > Thanks a lot Ben for the clarification :) > So it seems we are unaffected by the change and can continue to work like we > do. > To elaborate as you asked for it, we try to use phabricator as much as > possible for task management and review request. > For review requests we ask people to add GCompris or one of the appropriate > subprojects (like GCompris: Improvements) as Group-reviewer. > This way all people subscribed to this project/sub-project gets a mail > notification, but most importantly has it listed in his > https://phabricator.kde.org/differential/ Thanks for that. You should probably ask for a Herald rule to be setup as it can automate parts of this. > > See http://gcompris.net/wiki/Contribution_process , especially "Asking for a > Review Request" > > It seems that Krita is doing the same, since I also see lot of diffs with > Krita reviewer in my list and notifications (which I also like to have ;) ) > > Only "issue" for me is I have some mail duplicates from kde-edu list. It > would be great to find a way to avoid them, but if not possible I can live > with that. Everyone will continue to receive duplicates where they are subscribed to a mailing list which receives review mail and have been subscribed (either by being the named reviewer or explicitly subscribed) for a repository's reviews. This cannot be avoided i'm afraid (Phabricator has no idea who is subscribed to a given list). > > Our devel mailing list is now mostly used for occasional wider dev > communication, and for occasional contributors. > > Cheers, > Timothée Regards, Ben
Re: kdesrc-build: cmake should take local (instead of system-wide) cmake modules
Am 09.05.2018 08:19 schrieb Ben Cooksley: On Wed, May 9, 2018 at 9:28 AM, gregor.mi.sw wrote: On 08.05.2018 23:15, Milian Wolff wrote: On Dienstag, 8. Mai 2018 22:40:39 CEST gregor.mi.sw wrote: Hello, I have a question regarding kdesrc-build and CMake. I setup the build environment variables and ran kdesrc-build and got a compiler error kinfocenter. I investigated /home/gregor/kde/src/build/kde/workspace/kinfocenter/CMakeCache.txt and found the following lines //The directory containing a CMake configuration file for KF5Service. KF5Service_DIR:PATH=/usr/lib64/cmake/KF5Service //The directory containing a CMake configuration file for KF5Solid. KF5Solid_DIR:PATH=/usr/lib64/cmake/KF5Solid //The directory containing a CMake configuration file for KF5Wayland. KF5Wayland_DIR:PATH=/usr/lib64/cmake/KF5Wayland The directories of the needed KF5 frameworks point to the system wide installed ones. I removed the system-wide devel package for solid (because it caused the compiler error) and ran kdesrc-build again: //The directory containing a CMake configuration file for KF5Service. KF5Service_DIR:PATH=/usr/lib64/cmake/KF5Service //The directory containing a CMake configuration file for KF5Solid. KF5Solid_DIR:PATH=/home/gregor/kde/usr/lib64/cmake/KF5Solid //The directory containing a CMake configuration file for KF5Wayland. KF5Wayland_DIR:PATH=/usr/lib64/cmake/KF5Wayland Now it shows the correct (local) path for solid (but not the other ones). Is there an environment variable or something I have to set to tell Cmake to always look for local modules first? Try CMAKE_PREFIX_PATH. See e.g. this old blog post on the matter: https://blogs.kde.org/2008/12/12/how-get-cmake-find-what-you-want-it Thanks for the hint. The variable was already set: CMAKE_PREFIX_PATH=/home/gregor/kde/usr: In the blog post, it is said, that CMAKE_PREFIX_PATH is searched _first_. I find it strange that I had to uninstall the system-wide devel package in order to have cmake pick up the library in /home/gregor/kde/usr. And for the other libraries it still uses /usr. Any idea how to investigate this further? If you have previously run CMake without setting CMAKE_PREFIX_PATH you will need to remove your build directory first, otherwise it will reuse modules it has already found. Hello Ben, I already removed the build dir (forgot to mention that). I assume that it should be sufficient to delete the build dir of the application that should be configured (/home/gregor/kde/src/build/kde/workspace/kinfocenter/) and not also those of the imported libraries (KF5Service, KF5Solid, KF5Wayland etc.). I wonder if there is maybe an additional (global) cmake cache or a special behaviour of kdesrc-build. Gregor
Re: Changes to Phabricator review subscriptions
On woensdag 9 mei 2018 12:45:35 CEST Timothée Giet wrote: > Thanks a lot Ben for the clarification :) > So it seems we are unaffected by the change and can continue to work > like we do. Yes, indeed. No need for us to worry :-) > Our devel mailing list is now mostly used for occasional wider dev > communication, and for occasional contributors. The kimageshop list is barely used at this time, mostly only to post links to the weekly meeting notes... -- Boudewijn Rempt | https://www.valdyas.org | https://www.krita.org
Re: Changes to Phabricator review subscriptions
1. What is the canonical way to be notified of Phabricator changes for projects you're interested in? Subscribe to that project's mailing list? Can you clarify what this means for someone who joins or "watches" a project in Phabricator? Should we stop doing that? 2. If someone is subscribed to the project's mailing list and also joins the project in Phabricator, will they continue to receive duplicate emails? 3. Who should be listed as reviewers for diffs? Only individual people? Nobody? 4. What does this mean for projects like Dolphin or Spectacle that don't have mailing lists? Nate On 05/09/2018 02:08 AM, Ben Cooksley wrote: Hi all, To improve the user experience around email and in-application notifications from Phabricator, sysadmin have made some changes to the configuration of our Herald rules. Going forward, instead of subscribing projects to reviews, we will only be subscribing mailing lists now. For those reviews which have already been created, they will be updated to reflect the new practice the next time they are changed. This means that individual project members will no longer receive notifications and emails for every single review or task change that affects their project. Instead, they will only receive notifications and emails for reviews they have been individually subscribed to. To help this change take full effect, it would be appreciated if people refrain from adding Projects as reviewers, as that will have the effect of subscribing the Project to the review as well (Phabricator does not require you specify a reviewer) Should anyone have any questions regarding this, please open a thread on the kde-devel@kde.org mailing list. Regards, Ben Cooksley KDE Sysadmin
Re: Changes to Phabricator review subscriptions
On Thu, 10 May 2018, 02:08 Nate Graham, wrote: > 1. What is the canonical way to be notified of Phabricator changes for > projects you're interested in? Subscribe to that project's mailing list? > Can you clarify what this means for someone who joins or "watches" a > project in Phabricator? Should we stop doing that? > I would recommend subscribing to the individual Projects mailing lists yes. Joining or watching a Project would still result in email and notifications where the Project is a reviewer. Tasks are unaffected by this. > 2. If someone is subscribed to the project's mailing list and also joins > the project in Phabricator, will they continue to receive duplicate emails? > They shouldn't receive duplicates anymore. The only exception where duplicates would be received is if the user is individually subscribed to tasks or reviews. > 3. Who should be listed as reviewers for diffs? Only individual people? > Nobody? > Individuals. For smaller Projects it may still be practical for the Project to be the reviewer, however this does not scale for larger ones such as Frameworks and Plasma (where the complaints came from) > 4. What does this mean for projects like Dolphin or Spectacle that don't > have mailing lists? > Dolphin appears to be using the kfm-devel mailing list. Projects that don't have mailing lists (and which are small by nature) will continue to have the Project subscribed for reviews. > Nate > Cheers, Ben > > On 05/09/2018 02:08 AM, Ben Cooksley wrote: > > Hi all, > > > > To improve the user experience around email and in-application > > notifications from Phabricator, sysadmin have made some changes to the > > configuration of our Herald rules. > > > > Going forward, instead of subscribing projects to reviews, we will > > only be subscribing mailing lists now. For those reviews which have > > already been created, they will be updated to reflect the new practice > > the next time they are changed. > > > > This means that individual project members will no longer receive > > notifications and emails for every single review or task change that > > affects their project. Instead, they will only receive notifications > > and emails for reviews they have been individually subscribed to. > > > > To help this change take full effect, it would be appreciated if > > people refrain from adding Projects as reviewers, as that will have > > the effect of subscribing the Project to the review as well > > (Phabricator does not require you specify a reviewer) > > > > Should anyone have any questions regarding this, please open a thread > > on the kde-devel@kde.org mailing list. > > > > Regards, > > Ben Cooksley > > KDE Sysadmin > > > >
Re: Changes to Phabricator review subscriptions
Thanks for the responses, Ben. I'm a bit concerned that all of this raises the barrier to entry for new contributors. Now they'll have to match up Phabricator projects with mailing lists, which do not have a 1:1 mapping. How is someone interested in Dolphin supposed to know that they need to subscribe to the kfm-dev mailing list to follow the development? It doesn't have the word "Dolphin" in it or even have a description set on https://mail.kde.org/mailman/listinfo. And Dolphin's own Phabricator page doesn't mention anything about it. I appreciate the desire to cut down on duplicates and email overload (truly!) but are we sure this is the right approach? If we want to continue with this, I'd like to see some work put into updating our documentation on https://community.kde.org/Get_Involved/development#Communicating_with_the_team and https://community.kde.org/Infrastructure/Phabricator and for individual Phabricator project pages. Also, was this discussed somewhere before the change was rolled out? I didn't see anything about it on kde-devel. Nate On Wed, 09 May 2018 12:21:57 -0700 Ben Cooksley wrote > On Thu, 10 May 2018, 02:08 Nate Graham, wrote: > > 1. What is the canonical way to be notified of Phabricator changes for > projects you're interested in? Subscribe to that project's mailing list? > Can you clarify what this means for someone who joins or "watches" a > project in Phabricator? Should we stop doing that? > > > > > I would recommend subscribing to the individual Projects mailing lists yes. > > > Joining or watching a Project would still result in email and notifications > where the Project is a reviewer. Tasks are unaffected by this. > > > > 2. If someone is subscribed to the project's mailing list and also joins > the project in Phabricator, will they continue to receive duplicate emails? > > > > > They shouldn't receive duplicates anymore. > > > The only exception where duplicates would be received is if the user is > individually subscribed to tasks or reviews. > > > > 3. Who should be listed as reviewers for diffs? Only individual people? > Nobody? > > > > > Individuals. For smaller Projects it may still be practical for the Project > to be the reviewer, however this does not scale for larger ones such as > Frameworks and Plasma (where the complaints came from) > > > > 4. What does this mean for projects like Dolphin or Spectacle that don't > have mailing lists? > > > > > Dolphin appears to be using the kfm-devel mailing list. > > > Projects that don't have mailing lists (and which are small by nature) will > continue to have the Project subscribed for reviews. > > > > > > Nate > > > > > Cheers, > Ben > > > > > On 05/09/2018 02:08 AM, Ben Cooksley wrote: > > Hi all, > > > > To improve the user experience around email and in-application > > notifications from Phabricator, sysadmin have made some changes to the > > configuration of our Herald rules. > > > > Going forward, instead of subscribing projects to reviews, we will > > only be subscribing mailing lists now. For those reviews which have > > already been created, they will be updated to reflect the new practice > > the next time they are changed. > > > > This means that individual project members will no longer receive > > notifications and emails for every single review or task change that > > affects their project. Instead, they will only receive notifications > > and emails for reviews they have been individually subscribed to. > > > > To help this change take full effect, it would be appreciated if > > people refrain from adding Projects as reviewers, as that will have > > the effect of subscribing the Project to the review as well > > (Phabricator does not require you specify a reviewer) > > > > Should anyone have any questions regarding this, please open a thread > > on the kde-devel@kde.org mailing list. > > > > Regards, > > Ben Cooksley > > KDE Sysadmin > > > > > > > >
Re: Changes to Phabricator review subscriptions
Nate Graham ha scritto: > Thanks for the responses, Ben. > > I'm a bit concerned that all of this raises the barrier to entry for new > contributors. Now they'll have to match up Phabricator projects with mailing > lists, which do not have a 1:1 mapping. How is someone interested in Dolphin > supposed to know that they need to subscribe to the kfm-dev mailing list to > follow the development? It doesn't have the word "Dolphin" in it or even have > a description set on https://mail.kde.org/mailman/listinfo. And Dolphin's own > Phabricator page doesn't mention anything about it. Then it's time to set the the description of the list then. Also: https://www.kde.org/applications/system/dolphin/ -- Luigi
Re: Changes to Phabricator review subscriptions
On Wed, 09 May 2018 12:46:30 -0700 Luigi Toscano wrote > Nate Graham ha scritto: > > Thanks for the responses, Ben. > > > > I'm a bit concerned that all of this raises the barrier to entry for new > > contributors. Now they'll have to match up Phabricator projects with > > mailing lists, which do not have a 1:1 mapping. How is someone interested > > in Dolphin supposed to know that they need to subscribe to the kfm-dev > > mailing list to follow the development? It doesn't have the word "Dolphin" > > in it or even have a description set on > > https://mail.kde.org/mailman/listinfo. And Dolphin's own Phabricator page > > doesn't mention anything about it. > > Then it's time to set the the description of the list then. Who has access to do that? This is really an issue with information availability. It's all available in pieces in different places, rather than all "under one roof", so to speak. It's important to centralize wherever possible so that people get the full picture. Nate
Re: kdesrc-build: cmake should take local (instead of system-wide) cmake modules
On Wed, May 09, 2018 at 01:12:10PM +0200, gregor.mi.sw wrote: > Am 09.05.2018 08:19 schrieb Ben Cooksley: > > On Wed, May 9, 2018 at 9:28 AM, gregor.mi.sw > > wrote: > >> On 08.05.2018 23:15, Milian Wolff wrote: > >>> On Dienstag, 8. Mai 2018 22:40:39 CEST gregor.mi.sw wrote: > > Hello, > > I have a question regarding kdesrc-build and CMake. > > I setup the build environment variables and ran kdesrc-build and got > a > compiler error kinfocenter. > > Now it shows the correct (local) path for solid (but not the other > ones). > Is > there an environment variable or something I have to set to tell > Cmake to > always look for local modules first? This is all sort of odd. Regarding the difficulty finding CMake packages, kdesrc-build sets CMAKE_PREFIX_PATH already, based on your chosen install location (set by 'prefix' or the compatibility 'kdedir' option). If you're installing to /usr or /usr/local then maybe that is why CMake is finding system libraries? Roman Gilg actually recently submitted a patch to fix this (https://phabricator.kde.org/D12739), if that's what the problem is. > >>> Try CMAKE_PREFIX_PATH. See e.g. this old blog post on the matter: > >>> > >>> https://blogs.kde.org/2008/12/12/how-get-cmake-find-what-you-want-it > >> > >> > >> Thanks for the hint. The variable was already set: > >> > >> CMAKE_PREFIX_PATH=/home/gregor/kde/usr: > >> > >> In the blog post, it is said, that CMAKE_PREFIX_PATH is searched > >> _first_. I > >> find it strange that I had to uninstall the system-wide devel package > >> in > >> order to have cmake pick up the library in /home/gregor/kde/usr. And > >> for the > >> other libraries it still uses /usr. Any idea how to investigate this > >> further? > > > > If you have previously run CMake without setting CMAKE_PREFIX_PATH you > > will need to remove your build directory first, otherwise it will > > reuse modules it has already found. > > Hello Ben, I already removed the build dir (forgot to mention that). I > assume that it should be sufficient to delete the build dir of the > application that should be configured > (/home/gregor/kde/src/build/kde/workspace/kinfocenter/) and not also > those of the imported libraries (KF5Service, KF5Solid, KF5Wayland etc.). > I wonder if there is maybe an additional (global) cmake cache or a > special behaviour of kdesrc-build. There's no special behavior for kdesrc-build here (though there is a cache, default .kdesrc-build-data in the same directory as your kdesrc-buildrc). However the CMake package to find when a CMake module config file is loaded is based on the CMake paths when the module config file was *installed*. So all imported libraries would have be reinstalled to fully fix the paths. I've had these problems over the years and I've almost always found it easier just to remove the CMake module config files entirely before reinstalling to force it to be regenerated. It may be easiest to remove the install directory completely and use "kdesrc-build --refresh-build" to avoid interference from previously-installed cruft. Regards, - Michael Pyne
