<div dir="ltr"><div><div>Hi Albert,<br><br>Once again sorry for the delay in response me and karan were attending Conf KDE India so were a bit preoccupied with that<br><br>>Try following the steps, you will see that you can't do step 1 because that is<br>>not something we have in KDE (I guess one could bother sysadmin about it, but<br>>that's not scalable).<br><br>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<br><br>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.<br><br>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.<br><br></div>Sincerely,<br></div>Aakarsh MJ<br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, Feb 1, 2024 at 3:18 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 dimecres, 31 de gener de 2024, a les 4:48:04 (CET), DrQuark va escriure:<br>
> Hi Albert,<br>
> I am Karanjot Singh, one of the developers from the KEcolab Team. <br>
> <br>
> <br>
> You can configure a list of people that would receive an email when the<br>
> pipeline status changes. <br>
> See <a href="https://docs.gitlab.com/ee/user/project/integrations/pipeline_status_em" rel="noreferrer" target="_blank">https://docs.gitlab.com/ee/user/project/integrations/pipeline_status_em</a><br>
> ails.html<br>
<br>
Try following the steps, you will see that you can't do step 1 because that is <br>
not something we have in KDE (I guess one could bother sysadmin about it, but <br>
that's not scalable).<br>
<br>
Cheers,<br>
  Albert<br>
<br>
> <br>
> <br>
> Cheers,<br>
> Karanjot<br>
> <br>
> <br>
> <br>
> <br>
> <br>
> On Wed, Jan 31, 2024 at 04:39, Albert Astals Cid <<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>> wrote:<br>
> <br>
> El dilluns, 29 de gener de 2024, a les 20:11:20 (CET), Aakarsh MJ va <br>
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<br>
> > > 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>
> <br>
> > similar to the following image:<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 <<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>> 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<br>
> > > 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<br>
> > > 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 <<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>> <br>
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<br>
> > > > > > behalf<br>
> > > <br>
> > > of<br>
> > > <br>
> > > > > the<br>
> > > > > <br>
> > > > > > KDE Eco’s KEcoLab team for proposing the integration of KEcoLab<br>
> > > > > > into<br>
> > > > > > Okular’s pipeline. There are 2 proposed models (you can also<br>
> > > > > > 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<br>
> > > > > > 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<br>
> > > > > > 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<br>
> > > > > > KDE<br>
> > > <br>
> > > SoK<br>
> > > <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/" rel="noreferrer" target="_blank">https://invent.kde.org/teams/season-of-kde/2024/-/issues/</a><br>
> > > > > > 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>