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 <aa...@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
