KEcoLab's integration into Okular

[Albert Astals Cid]

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 <aacid at kde.org> 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 <aacid at kde.org> 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