<div dir="ltr"><div dir="ltr">Sorry for the late reply,<br><br><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> Please remember to keep the list in copy :)<br></blockquote><div><br></div><div>My mistake, I made sure to include all in this reply<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Doing the testing on the tag creation may be a bit too late since we only </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> create the tag when the application is released, which means if the test finds </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> a regression, it's too late since we've already released.</blockquote>
<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> But I guess as a start is not a bad thing, at least we'd know a regression </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> happened :D <br></blockquote></div></div><div><br></div><div>Great!<br><br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Speaking of which, how would we know a regression happened? I understand the </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> pipeline would fail, but since "noone" is specifically looking at that </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> pipeline it would possibly be "lost"? Maybe we can get an email on the mailing </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
> list? But I guess that's step #2.</blockquote>
</div><div><br></div><div>Yes, iirc whenever a pipeline fails the maintainers do receive an email similar to the following image:<br><img src="cid:ii_lrzaspq60" alt="image.png" width="398" height="442"><br></div><div>and even if the deploy stage fails we would still have artefacts from the energy measurement stage. <br><br></div><div>Sincerely,<br></div><div>Aakarsh MJ<br></div><div><br></div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Fri, Jan 26, 2024 at 4:32 AM Albert Astals Cid <<a href="mailto:aacid@kde.org">aacid@kde.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">El dijous, 25 de gener de 2024, a les 23:37:59 (CET), Aakarsh MJ va 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 looking<br>
> to leverage `release-tags` (eg tag v 1.0) to identify the release KEcoLab<br>
> runner would automatically run on and additionally the measurement process<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 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 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 mailing <br>
list? But I guess that's step #2.<br>
<br>
Cheers,<br>
  Albert<br>
<br>
> <br>
> Sincerely,<br>
> Aakarsh MJ<br>
> <br>
> On Tue, Jan 23, 2024 at 4:07 AM Albert Astals Cid <<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>> 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 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 to<br>
> > > maintain the Blue Angel’s recommended less than 10% increase from 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 based on<br>
> > > their potential impact on energy consumption.<br>
> > > * Smaller changes or bug fixes may not require MRT, while large feature<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 SoK<br>
> > > 24. You can also check my proposal(<br>
> > > <a href="https://invent.kde.org/teams/season-of-kde/2024/-/issues/24" rel="noreferrer" target="_blank">https://invent.kde.org/teams/season-of-kde/2024/-/issues/24</a>) and<br>
> > <br>
> > sarthak's<br>
> > <br>
> > > proposal(<a href="https://invent.kde.org/teams/season-of-kde/2024/-/issues/19" rel="noreferrer" target="_blank">https://invent.kde.org/teams/season-of-kde/2024/-/issues/19</a>)<br>
> > > <br>
> > > I am eager to hear your feedback, answer any questions and discuss 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 "pre-release"<br>
> > exactly is?<br>
> > <br>
> > Cheers,<br>
> > <br>
> >   Albert<br>
<br>
<br>
<br>
<br>
</blockquote></div></div>