KEcoLab's integration into Okular

[Aakarsh MJ]

Hi Albert,

Once again sorry for the delay in response me and karan were attending Conf
KDE India so were a bit preoccupied with that

>Try following the steps, you will see that you can't do step 1 because
that is
>not something we have in KDE (I guess one could bother sysadmin about it,
but
>that's not scalable).

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

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.

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.

Sincerely,
Aakarsh MJ

On Thu, Feb 1, 2024 at 3:18 AM Albert Astals Cid <aacid at kde.org> wrote:

> El dimecres, 31 de gener de 2024, a les 4:48:04 (CET), DrQuark va escriure:
> > Hi Albert,
> > I am Karanjot Singh, one of the developers from the KEcolab Team.
> >
> >
> > You can configure a list of people that would receive an email when the
> > pipeline status changes.
> > See
> https://docs.gitlab.com/ee/user/project/integrations/pipeline_status_em
> > ails.html
>
> Try following the steps, you will see that you can't do step 1 because
> that is
> not something we have in KDE (I guess one could bother sysadmin about it,
> but
> that's not scalable).
>
> Cheers,
>   Albert
>
> >
> >
> > Cheers,
> > Karanjot
> >
> >
> >
> >
> >
> > On Wed, Jan 31, 2024 at 04:39, Albert Astals Cid <aacid at kde.org> wrote:
> >
> > 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
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/okular-devel/attachments/20240209/a8a04a0a/attachment.htm>