Re: KEcoLab's integration into Okular
Hi Albert, Once again sorry for the delay in response me and karan were attending Conf KDE India so were a bit preoccupied with that >Try following the steps, you will see that you can't do step 1 because that is >not something we have in KDE (I guess one could bother sysadmin about it, but >that's not scalable). Yes you are correct we'll have to ask sysadmins for this. For this we would create a template to make this easy to achieve where we can have a comma seperated list of email addresses to notify when the pipeline breaks. Although this would be the last step for integration In regards to concern around scalability at present we were only looking to work with select projects owing to limited availability of hardware and also bearing in mind measuring too many projects can overload the system under test. Also on 14 February we would be having our monthly KDE Eco meetup and from what I have been told joseph will contact you in regards to this so maybe we can go into more details over this which would help in a smoother conversation. Sincerely, Aakarsh MJ On Thu, Feb 1, 2024 at 3:18 AM Albert Astals Cid wrote: > El dimecres, 31 de gener de 2024, a les 4:48:04 (CET), DrQuark va escriure: > > Hi Albert, > > I am Karanjot Singh, one of the developers from the KEcolab Team. > > > > > > You can configure a list of people that would receive an email when the > > pipeline status changes. > > See > https://docs.gitlab.com/ee/user/project/integrations/pipeline_status_em > > ails.html > > Try following the steps, you will see that you can't do step 1 because > that is > not something we have in KDE (I guess one could bother sysadmin about it, > but > that's not scalable). > > Cheers, > Albert > > > > > > > Cheers, > > Karanjot > > > > > > > > > > > > On Wed, Jan 31, 2024 at 04:39, Albert Astals Cid wrote: > > > > El dilluns, 29 de gener de 2024, a les 20:11:20 (CET), Aakarsh MJ va > escriure: > > > Sorry for the late reply, > > > > > > > > Please remember to keep the list in copy :) > > > > > > My mistake, I made sure to include all in this reply > > > > > > > Doing the testing on the tag creation may be a bit too late since we > > > > only > > > > > > > > create the tag when the application is released, which means if the > test > > > > finds > > > > > > > > a regression, it's too late since we've already released. > > > > > > > > > > > > But I guess as a start is not a bad thing, at least we'd know a > > > > regression > > > > > > > > happened :D > > > > > > Great! > > > > > > > Speaking of which, how would we know a regression happened? I > understand > > > > the > > > > > > > > pipeline would fail, but since "noone" is specifically looking at > that > > > > > > > > pipeline it would possibly be "lost"? Maybe we can get an email on > the > > > > mailing > > > > > > > > list? But I guess that's step #2. > > > > > > Yes, iirc whenever a pipeline fails the maintainers do receive an email > > > > > similar to the following image: > > Are you sure this is how it works? > > > > For Okular I only get emails when I break it, not when someone else does. > > > > Cheers, > > Albert > > > > > [image: image.png] > > > and even if the deploy stage fails we would still have artefacts from > the > > > energy measurement stage. > > > > > > Sincerely, > > > Aakarsh MJ > > > > > > On Fri, Jan 26, 2024 at 4:32 AM Albert Astals Cid > wrote: > > > > El dijous, 25 de gener de 2024, a les 23:37:59 (CET), Aakarsh MJ va > > > > > > > > escriure: > > > > > Hi Albert, > > > > > > > > Please remember to keep the list in copy :) > > > > > > > > > So we are planning to integrate this in the gitlab pipeline and are > > > > > > > > looking > > > > > > > > > to leverage `release-tags` (eg tag v 1.0) to identify the release > > > > > KEcoLab > > > > > runner would automatically run on and additionally the measurement > > > > > > > > process > > > > > > > > > can also be run manually at any time. > > > > > > > > Doing the testing on the tag creation may be a bit too late since we > > > > only > > > > create the tag when the application is released, which means if the > test > > > > finds > > > > a regression, it's too late since we've already released. > > > > > > > > But I guess as a start is not a bad thing, at least we'd know a > > > > regression > > > > happened :D > > > > > > > > Speaking of which, how would we know a regression happened? I > understand > > > > the > > > > pipeline would fail, but since "noone" is specifically looking at > that > > > > pipeline it would possibly be "lost"? Maybe we can get an email on > the > > > > mailing > > > > list? But I guess that's step #2. > > > > > > > > Cheers, > > > > > > > > Albert > > > > > > > > > Sincerely, > > > > > Aakarsh MJ > > > > > > > > > > On Tue, Jan 23, 2024 at 4:07 AM Albert Astals Cid > wrote: > > > > > > El dijous, 18 de gener de 2024, a les 18:17:10 (CET), Aakarsh MJ > va > > > > > > > > > > > > escriure: > > > > > > > request "reply all" > > > > > > > > > > > > >
Re: KEcoLab's integration into Okular
<<< text/html; charset=utf-8: Unrecognized >>> publicKey - thestrangequarks@protonmail.com - 0xA1F859C9.asc Description: application/pgp-keys signature.asc Description: OpenPGP digital signature
Re: KEcoLab's integration into Okular
El dimecres, 31 de gener de 2024, a les 4:48:04 (CET), DrQuark va escriure: > Hi Albert, > I am Karanjot Singh, one of the developers from the KEcolab Team. > > > You can configure a list of people that would receive an email when the > pipeline status changes. > See https://docs.gitlab.com/ee/user/project/integrations/pipeline_status_em > ails.html Try following the steps, you will see that you can't do step 1 because that is not something we have in KDE (I guess one could bother sysadmin about it, but that's not scalable). Cheers, Albert > > > Cheers, > Karanjot > > > > > > On Wed, Jan 31, 2024 at 04:39, Albert Astals Cid wrote: > > El dilluns, 29 de gener de 2024, a les 20:11:20 (CET), Aakarsh MJ va escriure: > > Sorry for the late reply, > > > > > > Please remember to keep the list in copy :) > > > > My mistake, I made sure to include all in this reply > > > > > Doing the testing on the tag creation may be a bit too late since we > > > only > > > > > > create the tag when the application is released, which means if the test > > > finds > > > > > > a regression, it's too late since we've already released. > > > > > > > > > But I guess as a start is not a bad thing, at least we'd know a > > > regression > > > > > > happened :D > > > > Great! > > > > > Speaking of which, how would we know a regression happened? I understand > > > the > > > > > > pipeline would fail, but since "noone" is specifically looking at that > > > > > > pipeline it would possibly be "lost"? Maybe we can get an email on the > > > mailing > > > > > > list? But I guess that's step #2. > > > > Yes, iirc whenever a pipeline fails the maintainers do receive an email > > > similar to the following image: > Are you sure this is how it works? > > For Okular I only get emails when I break it, not when someone else does. > > Cheers, > Albert > > > [image: image.png] > > and even if the deploy stage fails we would still have artefacts from the > > energy measurement stage. > > > > Sincerely, > > Aakarsh MJ > > > > On Fri, Jan 26, 2024 at 4:32 AM Albert Astals Cid wrote: > > > El dijous, 25 de gener de 2024, a les 23:37:59 (CET), Aakarsh MJ va > > > > > > escriure: > > > > Hi Albert, > > > > > > Please remember to keep the list in copy :) > > > > > > > So we are planning to integrate this in the gitlab pipeline and are > > > > > > looking > > > > > > > to leverage `release-tags` (eg tag v 1.0) to identify the release > > > > KEcoLab > > > > runner would automatically run on and additionally the measurement > > > > > > process > > > > > > > can also be run manually at any time. > > > > > > Doing the testing on the tag creation may be a bit too late since we > > > only > > > create the tag when the application is released, which means if the test > > > finds > > > a regression, it's too late since we've already released. > > > > > > But I guess as a start is not a bad thing, at least we'd know a > > > regression > > > happened :D > > > > > > Speaking of which, how would we know a regression happened? I understand > > > the > > > pipeline would fail, but since "noone" is specifically looking at that > > > pipeline it would possibly be "lost"? Maybe we can get an email on the > > > mailing > > > list? But I guess that's step #2. > > > > > > Cheers, > > > > > > Albert > > > > > > > Sincerely, > > > > Aakarsh MJ > > > > > > > > On Tue, Jan 23, 2024 at 4:07 AM Albert Astals Cid wrote: > > > > > El dijous, 18 de gener de 2024, a les 18:17:10 (CET), Aakarsh MJ va > > > > > > > > > > escriure: > > > > > > request "reply all" > > > > > > > > > > > > Hello everyone, My name is Aakarsh MJ, I’m contacting you on > > > > > > behalf > > > > > > of > > > > > > > > the > > > > > > > > > > > KDE Eco’s KEcoLab team for proposing the integration of KEcoLab > > > > > > into > > > > > > Okular’s pipeline. There are 2 proposed models (you can also > > > > > > suggest > > > > > > your > > > > > > own) which are as follows: > > > > > > > > > > > > 1) Pre-release Testing: > > > > > > * Every release candidate would be tested for energy consumption. > > > > > > * Provide information about energy change with the previous > > > > > > versions > > > > > > to > > > > > > > > > maintain the Blue Angel’s recommended less than 10% increase from > > > > > > the > > > > > > > > > > time > > > > > > > > > > > of certification requirement. > > > > > > > > > > > > 2) Optional Merge Request Testing (MRT) > > > > > > * Maintainers can opt to run KEcoLab on specific merge requests > > > > > > based on > > > > > > > > > their potential impact on energy consumption. > > > > > > * Smaller changes or bug fixes may not require MRT, while large > > > > > > feature > > > > > > > > > additions could benefit from energy analysis > > > > > > * This approach allows for targeted testing, while at the same > > > > > > time > > > > > > ensuring we are not consuming unnecessary energy. > > > > > > > > > > > > If approved me and
Re: KEcoLab's integration into Okular
El dilluns, 29 de gener de 2024, a les 20:11:20 (CET), Aakarsh MJ va escriure: > Sorry for the late reply, > > > > Please remember to keep the list in copy :) > > My mistake, I made sure to include all in this reply > > > Doing the testing on the tag creation may be a bit too late since we only > > > > create the tag when the application is released, which means if the test > > finds > > > > a regression, it's too late since we've already released. > > > > > > But I guess as a start is not a bad thing, at least we'd know a > > regression > > > > happened :D > > Great! > > > Speaking of which, how would we know a regression happened? I understand > > the > > > > pipeline would fail, but since "noone" is specifically looking at that > > > > pipeline it would possibly be "lost"? Maybe we can get an email on the > > mailing > > > > list? But I guess that's step #2. > > Yes, iirc whenever a pipeline fails the maintainers do receive an email > similar to the following image: Are you sure this is how it works? For Okular I only get emails when I break it, not when someone else does. Cheers, Albert > [image: image.png] > and even if the deploy stage fails we would still have artefacts from the > energy measurement stage. > > Sincerely, > Aakarsh MJ > > On Fri, Jan 26, 2024 at 4:32 AM Albert Astals Cid wrote: > > El dijous, 25 de gener de 2024, a les 23:37:59 (CET), Aakarsh MJ va > > > > escriure: > > > Hi Albert, > > > > Please remember to keep the list in copy :) > > > > > So we are planning to integrate this in the gitlab pipeline and are > > > > looking > > > > > to leverage `release-tags` (eg tag v 1.0) to identify the release > > > KEcoLab > > > runner would automatically run on and additionally the measurement > > > > process > > > > > can also be run manually at any time. > > > > Doing the testing on the tag creation may be a bit too late since we only > > create the tag when the application is released, which means if the test > > finds > > a regression, it's too late since we've already released. > > > > But I guess as a start is not a bad thing, at least we'd know a regression > > happened :D > > > > Speaking of which, how would we know a regression happened? I understand > > the > > pipeline would fail, but since "noone" is specifically looking at that > > pipeline it would possibly be "lost"? Maybe we can get an email on the > > mailing > > list? But I guess that's step #2. > > > > Cheers, > > > > Albert > > > > > Sincerely, > > > Aakarsh MJ > > > > > > On Tue, Jan 23, 2024 at 4:07 AM Albert Astals Cid wrote: > > > > El dijous, 18 de gener de 2024, a les 18:17:10 (CET), Aakarsh MJ va > > > > > > > > escriure: > > > > > request "reply all" > > > > > > > > > > Hello everyone, My name is Aakarsh MJ, I’m contacting you on behalf > > > > of > > > > > > the > > > > > > > > > KDE Eco’s KEcoLab team for proposing the integration of KEcoLab into > > > > > Okular’s pipeline. There are 2 proposed models (you can also suggest > > > > > your > > > > > own) which are as follows: > > > > > > > > > > 1) Pre-release Testing: > > > > > * Every release candidate would be tested for energy consumption. > > > > > * Provide information about energy change with the previous versions > > > > to > > > > > > > maintain the Blue Angel’s recommended less than 10% increase from > > > > > the > > > > > > > > time > > > > > > > > > of certification requirement. > > > > > > > > > > 2) Optional Merge Request Testing (MRT) > > > > > * Maintainers can opt to run KEcoLab on specific merge requests > > > > based on > > > > > > > their potential impact on energy consumption. > > > > > * Smaller changes or bug fixes may not require MRT, while large > > > > feature > > > > > > > additions could benefit from energy analysis > > > > > * This approach allows for targeted testing, while at the same time > > > > > ensuring we are not consuming unnecessary energy. > > > > > > > > > > If approved me and sarthak negi will be working on it as part of KDE > > > > SoK > > > > > > > 24. You can also check my proposal( > > > > > https://invent.kde.org/teams/season-of-kde/2024/-/issues/24) and > > > > > > > > sarthak's > > > > > > > > > proposal(https://invent.kde.org/teams/season-of-kde/2024/-/issues/19 > > > > ) > > > > > > > I am eager to hear your feedback, answer any questions and discuss > > > > the > > > > > > most > > > > > > > > > effective implementation approach. Thanks for your time and > > > > > > > > consideration. > > > > > > > > Would this be a gitlab thing or be in a separate service? > > > > > > > > How would you implement 1) i.e. how do you know what/when a > > > > "pre-release" > > > > > > exactly is? > > > > > > > > Cheers, > > > > > > > > Albert
Re: KEcoLab's integration into Okular
Sorry for the late reply, > > Please remember to keep the list in copy :) > My mistake, I made sure to include all in this reply > Doing the testing on the tag creation may be a bit too late since we only > create the tag when the application is released, which means if the test > finds > a regression, it's too late since we've already released. > But I guess as a start is not a bad thing, at least we'd know a > regression > happened :D > Great! > Speaking of which, how would we know a regression happened? I understand > the > pipeline would fail, but since "noone" is specifically looking at that > pipeline it would possibly be "lost"? Maybe we can get an email on the > mailing > list? But I guess that's step #2. Yes, iirc whenever a pipeline fails the maintainers do receive an email similar to the following image: [image: image.png] and even if the deploy stage fails we would still have artefacts from the energy measurement stage. Sincerely, Aakarsh MJ On Fri, Jan 26, 2024 at 4:32 AM Albert Astals Cid wrote: > El dijous, 25 de gener de 2024, a les 23:37:59 (CET), Aakarsh MJ va > escriure: > > Hi Albert, > > Please remember to keep the list in copy :) > > > So we are planning to integrate this in the gitlab pipeline and are > looking > > to leverage `release-tags` (eg tag v 1.0) to identify the release KEcoLab > > runner would automatically run on and additionally the measurement > process > > can also be run manually at any time. > > Doing the testing on the tag creation may be a bit too late since we only > create the tag when the application is released, which means if the test > finds > a regression, it's too late since we've already released. > > But I guess as a start is not a bad thing, at least we'd know a regression > happened :D > > Speaking of which, how would we know a regression happened? I understand > the > pipeline would fail, but since "noone" is specifically looking at that > pipeline it would possibly be "lost"? Maybe we can get an email on the > mailing > list? But I guess that's step #2. > > Cheers, > Albert > > > > > Sincerely, > > Aakarsh MJ > > > > On Tue, Jan 23, 2024 at 4:07 AM Albert Astals Cid wrote: > > > El dijous, 18 de gener de 2024, a les 18:17:10 (CET), Aakarsh MJ va > > > > > > escriure: > > > > request "reply all" > > > > > > > > Hello everyone, My name is Aakarsh MJ, I’m contacting you on behalf > of > > > > > > the > > > > > > > KDE Eco’s KEcoLab team for proposing the integration of KEcoLab into > > > > Okular’s pipeline. There are 2 proposed models (you can also suggest > > > > your > > > > own) which are as follows: > > > > > > > > 1) Pre-release Testing: > > > > * Every release candidate would be tested for energy consumption. > > > > * Provide information about energy change with the previous versions > to > > > > maintain the Blue Angel’s recommended less than 10% increase from the > > > > > > time > > > > > > > of certification requirement. > > > > > > > > 2) Optional Merge Request Testing (MRT) > > > > * Maintainers can opt to run KEcoLab on specific merge requests > based on > > > > their potential impact on energy consumption. > > > > * Smaller changes or bug fixes may not require MRT, while large > feature > > > > additions could benefit from energy analysis > > > > * This approach allows for targeted testing, while at the same time > > > > ensuring we are not consuming unnecessary energy. > > > > > > > > If approved me and sarthak negi will be working on it as part of KDE > SoK > > > > 24. You can also check my proposal( > > > > https://invent.kde.org/teams/season-of-kde/2024/-/issues/24) and > > > > > > sarthak's > > > > > > > proposal(https://invent.kde.org/teams/season-of-kde/2024/-/issues/19 > ) > > > > > > > > I am eager to hear your feedback, answer any questions and discuss > the > > > > > > most > > > > > > > effective implementation approach. Thanks for your time and > > > > > > consideration. > > > > > > Would this be a gitlab thing or be in a separate service? > > > > > > How would you implement 1) i.e. how do you know what/when a > "pre-release" > > > exactly is? > > > > > > Cheers, > > > > > > Albert > > > > >
Re: KEcoLab's integration into Okular
El dijous, 25 de gener de 2024, a les 23:37:59 (CET), Aakarsh MJ va escriure: > Hi Albert, Please remember to keep the list in copy :) > So we are planning to integrate this in the gitlab pipeline and are looking > to leverage `release-tags` (eg tag v 1.0) to identify the release KEcoLab > runner would automatically run on and additionally the measurement process > can also be run manually at any time. Doing the testing on the tag creation may be a bit too late since we only create the tag when the application is released, which means if the test finds a regression, it's too late since we've already released. But I guess as a start is not a bad thing, at least we'd know a regression happened :D Speaking of which, how would we know a regression happened? I understand the pipeline would fail, but since "noone" is specifically looking at that pipeline it would possibly be "lost"? Maybe we can get an email on the mailing list? But I guess that's step #2. Cheers, Albert > > Sincerely, > Aakarsh MJ > > On Tue, Jan 23, 2024 at 4:07 AM Albert Astals Cid wrote: > > El dijous, 18 de gener de 2024, a les 18:17:10 (CET), Aakarsh MJ va > > > > escriure: > > > request "reply all" > > > > > > Hello everyone, My name is Aakarsh MJ, I’m contacting you on behalf of > > > > the > > > > > KDE Eco’s KEcoLab team for proposing the integration of KEcoLab into > > > Okular’s pipeline. There are 2 proposed models (you can also suggest > > > your > > > own) which are as follows: > > > > > > 1) Pre-release Testing: > > > * Every release candidate would be tested for energy consumption. > > > * Provide information about energy change with the previous versions to > > > maintain the Blue Angel’s recommended less than 10% increase from the > > > > time > > > > > of certification requirement. > > > > > > 2) Optional Merge Request Testing (MRT) > > > * Maintainers can opt to run KEcoLab on specific merge requests based on > > > their potential impact on energy consumption. > > > * Smaller changes or bug fixes may not require MRT, while large feature > > > additions could benefit from energy analysis > > > * This approach allows for targeted testing, while at the same time > > > ensuring we are not consuming unnecessary energy. > > > > > > If approved me and sarthak negi will be working on it as part of KDE SoK > > > 24. You can also check my proposal( > > > https://invent.kde.org/teams/season-of-kde/2024/-/issues/24) and > > > > sarthak's > > > > > proposal(https://invent.kde.org/teams/season-of-kde/2024/-/issues/19) > > > > > > I am eager to hear your feedback, answer any questions and discuss the > > > > most > > > > > effective implementation approach. Thanks for your time and > > > > consideration. > > > > Would this be a gitlab thing or be in a separate service? > > > > How would you implement 1) i.e. how do you know what/when a "pre-release" > > exactly is? > > > > Cheers, > > > > Albert
Re: KEcoLab's integration into Okular
El dijous, 18 de gener de 2024, a les 18:17:10 (CET), Aakarsh MJ va escriure: > request "reply all" > > Hello everyone, My name is Aakarsh MJ, I’m contacting you on behalf of the > KDE Eco’s KEcoLab team for proposing the integration of KEcoLab into > Okular’s pipeline. There are 2 proposed models (you can also suggest your > own) which are as follows: > > 1) Pre-release Testing: > * Every release candidate would be tested for energy consumption. > * Provide information about energy change with the previous versions to > maintain the Blue Angel’s recommended less than 10% increase from the time > of certification requirement. > > 2) Optional Merge Request Testing (MRT) > * Maintainers can opt to run KEcoLab on specific merge requests based on > their potential impact on energy consumption. > * Smaller changes or bug fixes may not require MRT, while large feature > additions could benefit from energy analysis > * This approach allows for targeted testing, while at the same time > ensuring we are not consuming unnecessary energy. > > If approved me and sarthak negi will be working on it as part of KDE SoK > 24. You can also check my proposal( > https://invent.kde.org/teams/season-of-kde/2024/-/issues/24) and sarthak's > proposal(https://invent.kde.org/teams/season-of-kde/2024/-/issues/19) > > I am eager to hear your feedback, answer any questions and discuss the most > effective implementation approach. Thanks for your time and consideration. Would this be a gitlab thing or be in a separate service? How would you implement 1) i.e. how do you know what/when a "pre-release" exactly is? Cheers, Albert
KEcoLab's integration into Okular
request "reply all" Hello everyone, My name is Aakarsh MJ, I’m contacting you on behalf of the KDE Eco’s KEcoLab team for proposing the integration of KEcoLab into Okular’s pipeline. There are 2 proposed models (you can also suggest your own) which are as follows: 1) Pre-release Testing: * Every release candidate would be tested for energy consumption. * Provide information about energy change with the previous versions to maintain the Blue Angel’s recommended less than 10% increase from the time of certification requirement. 2) Optional Merge Request Testing (MRT) * Maintainers can opt to run KEcoLab on specific merge requests based on their potential impact on energy consumption. * Smaller changes or bug fixes may not require MRT, while large feature additions could benefit from energy analysis * This approach allows for targeted testing, while at the same time ensuring we are not consuming unnecessary energy. If approved me and sarthak negi will be working on it as part of KDE SoK 24. You can also check my proposal( https://invent.kde.org/teams/season-of-kde/2024/-/issues/24) and sarthak's proposal(https://invent.kde.org/teams/season-of-kde/2024/-/issues/19) I am eager to hear your feedback, answer any questions and discuss the most effective implementation approach. Thanks for your time and consideration.
