<html><head></head><body> <div dir="auto">Hi Albert,</div><div dir="auto">I am Karanjot Singh, one of the developers from the <caret></caret>KEcolab Team. </div><div dir="auto"><br></div>You can configure a list of people that would receive an email when the pipeline status changes. <div dir="auto">See <a href="https://docs.gitlab.com/ee/user/project/integrations/pipeline_status_emails.html" dir="auto">https://docs.gitlab.com/ee/user/project/integrations/pipeline_status_emails.html</a></div><div dir="auto"><br></div><div dir="auto"><a href="https://docs.gitlab.com/ee/user/project/integrations/pipeline_status_emails.html" dir="auto"></a>Cheers,</div><div dir="auto">Karanjot<br> <div><br></div><div><br></div>On Wed, Jan 31, 2024 at 04:39, Albert Astals Cid <<a class="" href="mailto:On Wed, Jan 31, 2024 at 04:39, Albert Astals Cid <<a href=">aacid@kde.org</a>> wrote:<blockquote type="cite" class="protonmail_quote"> El dilluns, 29 de gener de 2024, a les 20:11:20 (CET), Aakarsh MJ va escriure:<br>> Sorry for the late reply,<br>><br>> > > Please remember to keep the list in copy :)<br>><br>> My mistake, I made sure to include all in this reply<br>><br>> > Doing the testing on the tag creation may be a bit too late since we only<br>> ><br>> > create the tag when the application is released, which means if the test<br>> > finds<br>> ><br>> > a regression, it's too late since we've already released.<br>> ><br>> ><br>> > But I guess as a start is not a bad thing, at least we'd know a<br>> > regression<br>> ><br>> > happened :D<br>><br>> Great!<br>><br>> > Speaking of which, how would we know a regression happened? I understand<br>> > the<br>> ><br>> > pipeline would fail, but since "noone" is specifically looking at that<br>> ><br>> > pipeline it would possibly be "lost"? Maybe we can get an email on the<br>> > mailing<br>> ><br>> > list? But I guess that's step #2.<br>><br>> Yes, iirc whenever a pipeline fails the maintainers do receive an email<br>> similar to the following image:<br><br>Are you sure this is how it works?<br><br>For Okular I only get emails when I break it, not when someone else does.<br><br>Cheers,<br> Albert<br><br>> [image: image.png]<br>> and even if the deploy stage fails we would still have artefacts from the<br>> energy measurement stage.<br>><br>> Sincerely,<br>> Aakarsh MJ<br>><br>> On Fri, Jan 26, 2024 at 4:32 AM Albert Astals Cid <aacid@kde.org> wrote:<br>> > El dijous, 25 de gener de 2024, a les 23:37:59 (CET), Aakarsh MJ va<br>> ><br>> > escriure:<br>> > > Hi Albert,<br>> ><br>> > Please remember to keep the list in copy :)<br>> ><br>> > > So we are planning to integrate this in the gitlab pipeline and are<br>> ><br>> > looking<br>> ><br>> > > to leverage `release-tags` (eg tag v 1.0) to identify the release<br>> > > KEcoLab<br>> > > runner would automatically run on and additionally the measurement<br>> ><br>> > process<br>> ><br>> > > can also be run manually at any time.<br>> ><br>> > Doing the testing on the tag creation may be a bit too late since we only<br>> > create the tag when the application is released, which means if the test<br>> > finds<br>> > a regression, it's too late since we've already released.<br>> ><br>> > But I guess as a start is not a bad thing, at least we'd know a regression<br>> > happened :D<br>> ><br>> > Speaking of which, how would we know a regression happened? I understand<br>> > the<br>> > pipeline would fail, but since "noone" is specifically looking at that<br>> > pipeline it would possibly be "lost"? Maybe we can get an email on the<br>> > mailing<br>> > list? But I guess that's step #2.<br>> ><br>> > Cheers,<br>> ><br>> > Albert<br>> ><br>> > > Sincerely,<br>> > > Aakarsh MJ<br>> > ><br>> > > On Tue, Jan 23, 2024 at 4:07 AM Albert Astals Cid <aacid@kde.org> wrote:<br>> > > > El dijous, 18 de gener de 2024, a les 18:17:10 (CET), Aakarsh MJ va<br>> > > ><br>> > > > escriure:<br>> > > > > request "reply all"<br>> > > > ><br>> > > > > Hello everyone, My name is Aakarsh MJ, I’m contacting you on behalf<br>> ><br>> > of<br>> ><br>> > > > the<br>> > > ><br>> > > > > KDE Eco’s KEcoLab team for proposing the integration of KEcoLab into<br>> > > > > Okular’s pipeline. There are 2 proposed models (you can also suggest<br>> > > > > your<br>> > > > > own) which are as follows:<br>> > > > ><br>> > > > > 1) Pre-release Testing:<br>> > > > > * Every release candidate would be tested for energy consumption.<br>> > > > > * Provide information about energy change with the previous versions<br>> ><br>> > to<br>> ><br>> > > > > maintain the Blue Angel’s recommended less than 10% increase from<br>> > > > > the<br>> > > ><br>> > > > time<br>> > > ><br>> > > > > of certification requirement.<br>> > > > ><br>> > > > > 2) Optional Merge Request Testing (MRT)<br>> > > > > * Maintainers can opt to run KEcoLab on specific merge requests<br>> ><br>> > based on<br>> ><br>> > > > > their potential impact on energy consumption.<br>> > > > > * Smaller changes or bug fixes may not require MRT, while large<br>> ><br>> > feature<br>> ><br>> > > > > additions could benefit from energy analysis<br>> > > > > * This approach allows for targeted testing, while at the same time<br>> > > > > ensuring we are not consuming unnecessary energy.<br>> > > > ><br>> > > > > If approved me and sarthak negi will be working on it as part of KDE<br>> ><br>> > SoK<br>> ><br>> > > > > 24. You can also check my proposal(<br>> > > > > https://invent.kde.org/teams/season-of-kde/2024/-/issues/24) and<br>> > > ><br>> > > > sarthak's<br>> > > ><br>> > > > > proposal(https://invent.kde.org/teams/season-of-kde/2024/-/issues/19<br>> ><br>> > )<br>> ><br>> > > > > I am eager to hear your feedback, answer any questions and discuss<br>> ><br>> > the<br>> ><br>> > > > most<br>> > > ><br>> > > > > effective implementation approach. Thanks for your time and<br>> > > ><br>> > > > consideration.<br>> > > ><br>> > > > Would this be a gitlab thing or be in a separate service?<br>> > > ><br>> > > > How would you implement 1) i.e. how do you know what/when a<br>> ><br>> > "pre-release"<br>> ><br>> > > > exactly is?<br>> > > ><br>> > > > Cheers,<br>> > > ><br>> > > > Albert<br><br><br><br><br></blockquote></div></body></html>