Re: [VOTE] Release Apache Camel Kamelets 4.4.0

[Babak Vahdat]

+1 (binding)

Thanks Andrea!

--
Babak

> Am 19.02.2024 um 15:15 schrieb Andrea Cosentino :
> 
> Hello all,
> 
> This is a vote for releasing camel-kamelets 4.4.0
> 
> This is the first release of camel-kamelets supporting LTS Camel 4.4.0 and
> it contains many new Kamelets and a lot of fixes.
> 
> Kamelets release files:
> https://dist.apache.org/repos/dist/dev/camel/camel-kamelets/4.4.0
> Kamelets staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1681
> Kamelets Tag:
> https://github.com/apache/camel-kamelets/releases/tag/v4.4.0
> 
> Please cast your vote.
> 
> [ ] +1 Release camel-kamelets 4.4.0
> [ ] -1 Veto the release (provide specific comments)
> 
> The vote is open for at least 72 hours.
> 
> Here's my +1.
> 
> Thanks,
> Andrea Cosentino

Re: [VOTE] Release Apache Camel Kamelets 4.4.0

[Claudio Miranda]

+1 (non binding)





-- 
  Claudio Miranda

clau...@claudius.com.br
http://www.claudius.com.br

RE: [VOTE] Release Apache Camel Kamelets 4.4.0

[Nicolas Filotto]

+1 (binding)




De : Claus Ibsen 
Envoyé : lundi 19 février 2024 15:19
À : dev@camel.apache.org 
Cc : us...@camel.apache.org 
Objet : Re: [VOTE] Release Apache Camel Kamelets 4.4.0

CAUTION: This email originated from outside of the organization. Do not click 
links or open attachments unless you recognize the sender and know the content 
is safe.



+1 (binding)

On Mon, Feb 19, 2024 at 3:14 PM Andrea Cosentino  wrote:

> Hello all,
>
> This is a vote for releasing camel-kamelets 4.4.0
>
> This is the first release of camel-kamelets supporting LTS Camel 4.4.0 and
> it contains many new Kamelets and a lot of fixes.
>
> Kamelets release files:
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdist.apache.org%2Frepos%2Fdist%2Fdev%2Fcamel%2Fcamel-kamelets%2F4.4.0=05%7C02%7CNicolas.Filotto%40qlik.com%7C571740b47eec4391705d08dc3155d05d%7Cc21eeb5ff5a644e8a997124f2f7a497c%7C0%7C0%7C638439491830021349%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=Nb%2BoTTEmS6hBmRzvrG5TtsjadjLrxmaIKbPMcPhJQzM%3D=0
> Kamelets staging repository:
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Frepository.apache.org%2Fcontent%2Frepositories%2Forgapachecamel-1681=05%7C02%7CNicolas.Filotto%40qlik.com%7C571740b47eec4391705d08dc3155d05d%7Cc21eeb5ff5a644e8a997124f2f7a497c%7C0%7C0%7C638439491830027809%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=3V9%2BUSHvCQt0U7WQh77fhe0wWadC6Kt9gcCPcpTWzXA%3D=0
> Kamelets Tag:
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fcamel-kamelets%2Freleases%2Ftag%2Fv4.4.0=05%7C02%7CNicolas.Filotto%40qlik.com%7C571740b47eec4391705d08dc3155d05d%7Cc21eeb5ff5a644e8a997124f2f7a497c%7C0%7C0%7C638439491830031070%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=SlWYXH6H1eYEmQsKsdF7Fa86mU7wX%2BmlOYycS5Ll%2BZI%3D=0
>
> Please cast your vote.
>
> [ ] +1 Release camel-kamelets 4.4.0
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Here's my +1.
>
> Thanks,
> Andrea Cosentino
>


--
Claus Ibsen
-
@davsclaus
Camel in Action 2: 
https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.manning.com%2Fibsen2=05%7C02%7CNicolas.Filotto%40qlik.com%7C571740b47eec4391705d08dc3155d05d%7Cc21eeb5ff5a644e8a997124f2f7a497c%7C0%7C0%7C638439491830034194%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C=bfeCfwHf3n%2BIDyyliGRZc4u%2FyPVsnM06na1Hj0CG%2BMw%3D=0

The information transmitted is intended only for the person or entity to which 
it is addressed and may contain confidential and/or privileged material. Any 
review, retransmission, dissemination or other use of, or taking of any action 
in reliance upon, this information by persons or entities other than the 
intended recipient is prohibited. If you received this in error, please contact 
the sender and delete the material from any computer. Our Privacy & Cookie 
Notice describes how 
we handle personal information.
QlikTech France SARL (Société à responsabilité limitée), registered in France 
with number 499 265 940 R.C.S. Nanterre, and whose registered office is Tour 
Initiale, 1 Terrasse Bellini 5th Floor 92919 La Defense, Cedex Paris, France

Re: [VOTE] Release Apache Camel Kamelets 4.4.0

[Claus Ibsen]

+1 (binding)

On Mon, Feb 19, 2024 at 3:14 PM Andrea Cosentino  wrote:

> Hello all,
>
> This is a vote for releasing camel-kamelets 4.4.0
>
> This is the first release of camel-kamelets supporting LTS Camel 4.4.0 and
> it contains many new Kamelets and a lot of fixes.
>
> Kamelets release files:
> https://dist.apache.org/repos/dist/dev/camel/camel-kamelets/4.4.0
> Kamelets staging repository:
> https://repository.apache.org/content/repositories/orgapachecamel-1681
> Kamelets Tag:
> https://github.com/apache/camel-kamelets/releases/tag/v4.4.0
>
> Please cast your vote.
>
> [ ] +1 Release camel-kamelets 4.4.0
> [ ] -1 Veto the release (provide specific comments)
>
> The vote is open for at least 72 hours.
>
> Here's my +1.
>
> Thanks,
> Andrea Cosentino
>


-- 
Claus Ibsen
-
@davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

[VOTE] Release Apache Camel Kamelets 4.4.0

[Andrea Cosentino]

Hello all,

This is a vote for releasing camel-kamelets 4.4.0

This is the first release of camel-kamelets supporting LTS Camel 4.4.0 and
it contains many new Kamelets and a lot of fixes.

Kamelets release files:
https://dist.apache.org/repos/dist/dev/camel/camel-kamelets/4.4.0
Kamelets staging repository:
https://repository.apache.org/content/repositories/orgapachecamel-1681
Kamelets Tag:
https://github.com/apache/camel-kamelets/releases/tag/v4.4.0

Please cast your vote.

[ ] +1 Release camel-kamelets 4.4.0
[ ] -1 Veto the release (provide specific comments)

The vote is open for at least 72 hours.

Here's my +1.

Thanks,
Andrea Cosentino

Re: Excessive use on the "git-websites" runners?

[Claus Ibsen]

Hi

Yeah ideally those CVEs should be in 1 merge to main - so they were
released together.

And frankly the website is rebuild from scratch each time, instead of being
able to update only parts of it.
The CVEs only affect the security page + a new page per CVE.

I stopped one of the builds, as there is a 2nd build in the queue to
publish the last CVE.
That should put your job ahead of ours.





On Mon, Feb 19, 2024 at 1:37 PM Andrea Cosentino  wrote:

> I don't think it would work on our website, but Zoran could have more
> information about this.
>
> What we could do, it's maybe limit the number of builds on git-websites
> nodes concurrently.
>
> Il giorno lun 19 feb 2024 alle ore 13:30 Christofer Dutz <
> christofer.d...@c-ware.de> ha scritto:
>
> > Hi,
> >
> > as the PLC4X build also uses that, perhas what we did would be also an
> > option for you?
> > We build the website on our own VM, but stash the built website … then on
> > the git-websites agent, we simply unstash what was built on our VM and
> > deploy that … this reduces the lock we have on shared infra to the
> minimum
> > …  We’re also doing the same with deploying snapshots: We build on our VM
> > and use one of the ubuntu agents to deploy.
> >
> > Cause running a build on a PR, should probably not require staging of
> > website changes … as soon as the PR is merged, then of course.
> >
> > Chris
> >
> >
> > Von: Andrea Cosentino 
> > Datum: Montag, 19. Februar 2024 um 13:20
> > An: dev 
> > Betreff: Re: Excessive use on the "git-websites" runners?
> > Usually there is not that much activities. There were 3 PRs related to
> cves
> > and some related to the last release done during the weekend. So this
> > should be just a temporary saturation. We don't have other way of
> > publishing the website except using that mechanism.
> >
> > Il lun 19 feb 2024, 13:13 Christofer Dutz  ha
> > scritto:
> >
> > > Hi all,
> > >
> > > I’m currently trying to finish up some stuff for the upcoming PLC4X
> > > release. However am having problems because every time I want to update
> > our
> > > website, I have to wait a long, long time, because all 3 runners in the
> > > “git-websites” class (websites1, websites2 and websites3) are blocked
> > with
> > > really long running builds of Apache Camel.
> > >
> > > Most all have the tags associated with PRs … so I am asking myself: Do
> > > these builds have to be on git-websites? If not … it would be
> appreciated
> > > if you wouldn’t keep on blocking all runners. Of is currently something
> > out
> > > of the ordinary going on?
> > >
> > > Chris
> > >
> >
>


-- 
Claus Ibsen
-
@davsclaus
Camel in Action 2: https://www.manning.com/ibsen2

Re: Excessive use on the "git-websites" runners?

[Andrea Cosentino]

I don't think it would work on our website, but Zoran could have more
information about this.

What we could do, it's maybe limit the number of builds on git-websites
nodes concurrently.

Il giorno lun 19 feb 2024 alle ore 13:30 Christofer Dutz <
christofer.d...@c-ware.de> ha scritto:

> Hi,
>
> as the PLC4X build also uses that, perhas what we did would be also an
> option for you?
> We build the website on our own VM, but stash the built website … then on
> the git-websites agent, we simply unstash what was built on our VM and
> deploy that … this reduces the lock we have on shared infra to the minimum
> …  We’re also doing the same with deploying snapshots: We build on our VM
> and use one of the ubuntu agents to deploy.
>
> Cause running a build on a PR, should probably not require staging of
> website changes … as soon as the PR is merged, then of course.
>
> Chris
>
>
> Von: Andrea Cosentino 
> Datum: Montag, 19. Februar 2024 um 13:20
> An: dev 
> Betreff: Re: Excessive use on the "git-websites" runners?
> Usually there is not that much activities. There were 3 PRs related to cves
> and some related to the last release done during the weekend. So this
> should be just a temporary saturation. We don't have other way of
> publishing the website except using that mechanism.
>
> Il lun 19 feb 2024, 13:13 Christofer Dutz  ha
> scritto:
>
> > Hi all,
> >
> > I’m currently trying to finish up some stuff for the upcoming PLC4X
> > release. However am having problems because every time I want to update
> our
> > website, I have to wait a long, long time, because all 3 runners in the
> > “git-websites” class (websites1, websites2 and websites3) are blocked
> with
> > really long running builds of Apache Camel.
> >
> > Most all have the tags associated with PRs … so I am asking myself: Do
> > these builds have to be on git-websites? If not … it would be appreciated
> > if you wouldn’t keep on blocking all runners. Of is currently something
> out
> > of the ordinary going on?
> >
> > Chris
> >
>

AW: Excessive use on the "git-websites" runners?

[Christofer Dutz]

Hi,

as the PLC4X build also uses that, perhas what we did would be also an option 
for you?
We build the website on our own VM, but stash the built website … then on the 
git-websites agent, we simply unstash what was built on our VM and deploy that 
… this reduces the lock we have on shared infra to the minimum …  We’re also 
doing the same with deploying snapshots: We build on our VM and use one of the 
ubuntu agents to deploy.

Cause running a build on a PR, should probably not require staging of website 
changes … as soon as the PR is merged, then of course.

Chris


Von: Andrea Cosentino 
Datum: Montag, 19. Februar 2024 um 13:20
An: dev 
Betreff: Re: Excessive use on the "git-websites" runners?
Usually there is not that much activities. There were 3 PRs related to cves
and some related to the last release done during the weekend. So this
should be just a temporary saturation. We don't have other way of
publishing the website except using that mechanism.

Il lun 19 feb 2024, 13:13 Christofer Dutz  ha
scritto:

> Hi all,
>
> I’m currently trying to finish up some stuff for the upcoming PLC4X
> release. However am having problems because every time I want to update our
> website, I have to wait a long, long time, because all 3 runners in the
> “git-websites” class (websites1, websites2 and websites3) are blocked with
> really long running builds of Apache Camel.
>
> Most all have the tags associated with PRs … so I am asking myself: Do
> these builds have to be on git-websites? If not … it would be appreciated
> if you wouldn’t keep on blocking all runners. Of is currently something out
> of the ordinary going on?
>
> Chris
>

Re: Excessive use on the "git-websites" runners?

[Andrea Cosentino]

I think Zoran Regvart is able to give more advice on this, but yes, the
build should be on git-websites labeled nodes.

But again, this is a really a particular case: there were 3 CVEs and two
blog posts all in once.

Also, when a PR is merged, the website build starts immediately and it
takes a while.

Il giorno lun 19 feb 2024 alle ore 13:20 Andrea Cosentino 
ha scritto:

> Usually there is not that much activities. There were 3 PRs related to
> cves and some related to the last release done during the weekend. So this
> should be just a temporary saturation. We don't have other way of
> publishing the website except using that mechanism.
>
> Il lun 19 feb 2024, 13:13 Christofer Dutz  ha
> scritto:
>
>> Hi all,
>>
>> I’m currently trying to finish up some stuff for the upcoming PLC4X
>> release. However am having problems because every time I want to update our
>> website, I have to wait a long, long time, because all 3 runners in the
>> “git-websites” class (websites1, websites2 and websites3) are blocked with
>> really long running builds of Apache Camel.
>>
>> Most all have the tags associated with PRs … so I am asking myself: Do
>> these builds have to be on git-websites? If not … it would be appreciated
>> if you wouldn’t keep on blocking all runners. Of is currently something out
>> of the ordinary going on?
>>
>> Chris
>>
>

Re: Excessive use on the "git-websites" runners?

[Andrea Cosentino]

Usually there is not that much activities. There were 3 PRs related to cves
and some related to the last release done during the weekend. So this
should be just a temporary saturation. We don't have other way of
publishing the website except using that mechanism.

Il lun 19 feb 2024, 13:13 Christofer Dutz  ha
scritto:

> Hi all,
>
> I’m currently trying to finish up some stuff for the upcoming PLC4X
> release. However am having problems because every time I want to update our
> website, I have to wait a long, long time, because all 3 runners in the
> “git-websites” class (websites1, websites2 and websites3) are blocked with
> really long running builds of Apache Camel.
>
> Most all have the tags associated with PRs … so I am asking myself: Do
> these builds have to be on git-websites? If not … it would be appreciated
> if you wouldn’t keep on blocking all runners. Of is currently something out
> of the ordinary going on?
>
> Chris
>

Excessive use on the "git-websites" runners?

[Christofer Dutz]

Hi all,

I’m currently trying to finish up some stuff for the upcoming PLC4X release. 
However am having problems because every time I want to update our website, I 
have to wait a long, long time, because all 3 runners in the “git-websites” 
class (websites1, websites2 and websites3) are blocked with really long running 
builds of Apache Camel.

Most all have the tags associated with PRs … so I am asking myself: Do these 
builds have to be on git-websites? If not … it would be appreciated if you 
wouldn’t keep on blocking all runners. Of is currently something out of the 
ordinary going on?

Chris