You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@pekko.apache.org by Samuele Resca <sa...@gmail.com> on 2023/08/14 10:06:57 UTC
[DISCUSS] Dependency updates in Apache Pekko Core + modules
Hi,
I'm opening a discussion regarding dependencies updates in Apache Pekko
Core + modules. I saw that most of the Apache Pekko codebases already have
the .scala-steward.conf file for automatically updating dependencies.
Few questions that I have on top of my head:
- Do we want to automate the stay current process in Apache Pekko (core +
modules)?
- Do we want scala-steward running on Apache Pekko Core + modules? Is
there any other alternative system used by ASF projects?
- Which subset of dependency do we want to update? (i.e: excluding
intra-dependencies between Pekko modules)
- Do we have a preference for the schedule (see: pullRequests.frequency)?
Thanks in advance.
Samuele
Re: [DISCUSS] Dependency updates in Apache Pekko Core + modules
Posted by He Pin <he...@apache.org>.
I vote for it +1
On 2023/09/06 17:24:57 PJ Fanning wrote:
> I would like to press on and add entries for our main repos to
> https://github.com/VirtusLab/scala-steward-repos/blob/main/repos-github.md
>
> * pekko
> * pekko-http
> * pekko-connectors
> * possibly more
>
> There are some Apache repos already managed this way.
>
> We can set up our own job later but it would be nice to get moving on this and using the VirtusLab integration is trivial to set up. We can undo it if we get too much noise in terms of generated PRs.
>
>
>
> On 2023/08/14 12:53:06 PJ Fanning wrote:
> > We intend to use Scala Steward. There doesn't appear to anything that matches Scala Steward's feature set for Scala based projects.
> >
> > The simplest approach is to add entries to this page and there is an automated job that will raise PRs:
> > https://github.com/VirtusLab/scala-steward-repos/blob/main/repos-github.md
> >
> > Matthew de Detrich has expressed a preference for us to run our own Scala Steward job.
> >
> > With dependencies between Pekko modules, we intend to follow:
> >
> > https://pekko.apache.org/docs/pekko/current/project/downstream-upgrade-strategy.html
> >
> > With 3rd party dependencies, we will be conservative. If there are security issues, we will almost certainly upgrade to a secure version. Enabling Scala Steward will raise awareness of 3rd party jar releases but merging the PRs will not be automatic. They will need careful review.
> >
> >
> >
> > On 2023/08/14 10:06:57 Samuele Resca wrote:
> > > Hi,
> > >
> > > I'm opening a discussion regarding dependencies updates in Apache Pekko
> > > Core + modules. I saw that most of the Apache Pekko codebases already have
> > > the .scala-steward.conf file for automatically updating dependencies.
> > > Few questions that I have on top of my head:
> > > - Do we want to automate the stay current process in Apache Pekko (core +
> > > modules)?
> > > - Do we want scala-steward running on Apache Pekko Core + modules? Is
> > > there any other alternative system used by ASF projects?
> > > - Which subset of dependency do we want to update? (i.e: excluding
> > > intra-dependencies between Pekko modules)
> > > - Do we have a preference for the schedule (see: pullRequests.frequency)?
> > >
> > > Thanks in advance.
> > > Samuele
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@pekko.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: [DISCUSS] Dependency updates in Apache Pekko Core + modules
Posted by Matthew de Detrich <ma...@aiven.io.INVALID>.
> Scala Steward creates PRs in our repos so the GitHub Actions CI that
we have set up in our repos will run as normal on those PRs. These PR
CI runs will have full access to our repo secrets.
Afaik this is not the case, I actually experienced this issue when setting
up
Scala Steward at my company and to solve this issue we had to create
our own runner as I am suggesting (you can see
https://github.com/Aiven-Open/guardian-for-apache-kafka/pull/478
as an example of what a custom runner looks like).
The issue with using the public Scala Steward is that the public Scala
Steward user is not part of the apache github org and so it cannot access
our secrets, from the POV of our github its just an external user creating
PR's
against our repository and secrets can never be exposed to external users.
I just created an INFRA ticket at
https://issues.apache.org/jira/browse/INFRA-24961
so lets see where it lands, if it takes too long then we can just fallback
to the public
Scala Steward.
On Wed, Sep 6, 2023 at 11:31 PM PJ Fanning <fa...@gmail.com> wrote:
> Reasonable point about starting with just pekko and pekko-http.
>
> Scala Steward creates PRs in our repos so the GitHub Actions CI that
> we have set up in our repos will run as normal on those PRs. These PR
> CI runs will have full access to our repo secrets. It could be that
> someone in the Apache GitHub org will need to press a button on the PR
> to allow it to run the CI - I've seen this when PRs originate from
> users who are not part of the Apache GitHub org.
>
> On Wed, 6 Sept 2023 at 22:22, Matthew de Detrich
> <ma...@aiven.io.invalid> wrote:
> >
> > Also I forgot to mention that the advantage of having our own runner for
> > Scala Steward vs the default public VirtuisLabs one is that a runner in
> our
> > own org has access to all of the github secrets which can be important
> for
> > some integration tests (pekko-connectors has such a test).
> >
> > It basically allows us to test that dependency upgrades don't break
> > something.
> >
> > On Wed, Sep 6, 2023 at 11:19 PM Matthew de Detrich <
> > matthew.dedetrich@aiven.io> wrote:
> >
> > > > I would like to press on and add entries for our main repos to
> > >
> https://github.com/VirtusLab/scala-steward-repos/blob/main/repos-github.md
> > >
> > > * pekko
> > > * pekko-http
> > > * pekko-connectors
> > > * possibly more
> > >
> > > For pekko/pekko-http this can work since the 1.0.x branches have been
> > > setup but for other repos we need to create the branches yet since we
> > > shouldn't be getting dependency updates for the 1.0.x series unless
> they
> > > contain CVE's/
> > >
> > > On Wed, Sep 6, 2023 at 7:25 PM PJ Fanning <fa...@apache.org>
> wrote:
> > >
> > >> I would like to press on and add entries for our main repos to
> > >>
> https://github.com/VirtusLab/scala-steward-repos/blob/main/repos-github.md
> > >>
> > >> * pekko
> > >> * pekko-http
> > >> * pekko-connectors
> > >> * possibly more
> > >>
> > >> There are some Apache repos already managed this way.
> > >>
> > >> We can set up our own job later but it would be nice to get moving on
> > >> this and using the VirtusLab integration is trivial to set up. We can
> undo
> > >> it if we get too much noise in terms of generated PRs.
> > >>
> > >>
> > >>
> > >> On 2023/08/14 12:53:06 PJ Fanning wrote:
> > >> > We intend to use Scala Steward. There doesn't appear to anything
> that
> > >> matches Scala Steward's feature set for Scala based projects.
> > >> >
> > >> > The simplest approach is to add entries to this page and there is an
> > >> automated job that will raise PRs:
> > >> >
> > >>
> https://github.com/VirtusLab/scala-steward-repos/blob/main/repos-github.md
> > >> >
> > >> > Matthew de Detrich has expressed a preference for us to run our own
> > >> Scala Steward job.
> > >> >
> > >> > With dependencies between Pekko modules, we intend to follow:
> > >> >
> > >> >
> > >>
> https://pekko.apache.org/docs/pekko/current/project/downstream-upgrade-strategy.html
> > >> >
> > >> > With 3rd party dependencies, we will be conservative. If there are
> > >> security issues, we will almost certainly upgrade to a secure version.
> > >> Enabling Scala Steward will raise awareness of 3rd party jar releases
> but
> > >> merging the PRs will not be automatic. They will need careful review.
> > >> >
> > >> >
> > >> >
> > >> > On 2023/08/14 10:06:57 Samuele Resca wrote:
> > >> > > Hi,
> > >> > >
> > >> > > I'm opening a discussion regarding dependencies updates in Apache
> > >> Pekko
> > >> > > Core + modules. I saw that most of the Apache Pekko codebases
> already
> > >> have
> > >> > > the .scala-steward.conf file for automatically updating
> dependencies.
> > >> > > Few questions that I have on top of my head:
> > >> > > - Do we want to automate the stay current process in Apache Pekko
> > >> (core +
> > >> > > modules)?
> > >> > > - Do we want scala-steward running on Apache Pekko Core +
> modules? Is
> > >> > > there any other alternative system used by ASF projects?
> > >> > > - Which subset of dependency do we want to update? (i.e: excluding
> > >> > > intra-dependencies between Pekko modules)
> > >> > > - Do we have a preference for the schedule (see:
> > >> pullRequests.frequency)?
> > >> > >
> > >> > > Thanks in advance.
> > >> > > Samuele
> > >> > >
> > >> >
> > >> >
> ---------------------------------------------------------------------
> > >> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > >> > For additional commands, e-mail: dev-help@pekko.apache.org
> > >> >
> > >> >
> > >>
> > >> ---------------------------------------------------------------------
> > >> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > >> For additional commands, e-mail: dev-help@pekko.apache.org
> > >>
> > >>
> > >
> > > --
> > >
> > > Matthew de Detrich
> > >
> > > *Aiven Deutschland GmbH*
> > >
> > > Immanuelkirchstraße 26, 10405 Berlin
> > >
> > > Amtsgericht Charlottenburg, HRB 209739 B
> > >
> > > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> > >
> > > *m:* +491603708037
> > >
> > > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> > >
> >
> >
> > --
> >
> > Matthew de Detrich
> >
> > *Aiven Deutschland GmbH*
> >
> > Immanuelkirchstraße 26, 10405 Berlin
> >
> > Amtsgericht Charlottenburg, HRB 209739 B
> >
> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> >
> > *m:* +491603708037
> >
> > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>
--
Matthew de Detrich
*Aiven Deutschland GmbH*
Immanuelkirchstraße 26, 10405 Berlin
Amtsgericht Charlottenburg, HRB 209739 B
Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
*m:* +491603708037
*w:* aiven.io *e:* matthew.dedetrich@aiven.io
Re: [DISCUSS] Dependency updates in Apache Pekko Core + modules
Posted by Matthew de Detrich <ma...@aiven.io.INVALID>.
Also one other additional thing I would like to mention is that while
I apologize for dropping the ball a bit on setting up scala steward
(have a lot of things on my plate at the moment), the benefits for
Scala Steward are not going to be that great for pekko core/pekko-http
because both of these projects have minimal dependencies (on the
top of my head pekko core only has logback/slf4j, netty and maybe an
additional one that I am missing).
The biggest benefit scala steward will give is to repositories like
pekko-connectors and in light of what I said before in this case I really
do think its a good idea to setup the Scala Steward within the apache
github org because we don't want cases where we update an underlying
dependency that is used for one of the connectors, only for that
dependency to create a regression because we couldn't run proper tests
due to secrets not being exposed.
On Thu, Sep 7, 2023 at 9:57 AM Matthew de Detrich <
matthew.dedetrich@aiven.io> wrote:
> > Approval, probably yes, and we can see that as a feature. Secrets
> should not be accessible but that is not a problem as PR validation
> should not need secrets.
>
> With Pekko Connectors this is actually no longer the case, there are tests
> that require secrets to work because they run against actual services (as
> opposed to a local docker).
>
> Currently this is with S3 tests and this was added in because actual
> regressions
> were made in the pekko-connectors S3 client due to the fact that its not
> possible to test all cases with docker services (with S3 specifically this
> is
> the minio docker image).
>
> I also expect that this will increase over time, there are other
> connectors where the equivalent Docker images are only able to test a
> smaller
> scope of features (gcs is another such connector and I am sure there will
> be others).
>
> On Thu, Sep 7, 2023 at 9:23 AM Johannes Rudolph <
> johannes.rudolph@gmail.com> wrote:
>
>> On Wed, Sep 6, 2023 at 11:31 PM PJ Fanning <fa...@gmail.com> wrote:
>> > Scala Steward creates PRs in our repos so the GitHub Actions CI that
>> > we have set up in our repos will run as normal on those PRs. These PR
>> > CI runs will have full access to our repo secrets. It could be that
>> > someone in the Apache GitHub org will need to press a button on the PR
>> > to allow it to run the CI - I've seen this when PRs originate from
>> > users who are not part of the Apache GitHub org.
>>
>> Approval, probably yes, and we can see that as a feature. Secrets
>> should not be accessible but that is not a problem as PR validation
>> should not need secrets.
>>
>> So, I don't see any reason to use our own instance for now.
>>
>> Incidentally, to make the updates less frequent I used to set a
>> schedule to when those Scala steward are proposed, e.g. only once a
>> week on Tuesday mornings, so that it is easier for maintainers to
>> expect those updates and deal with them in a batch.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
>> For additional commands, e-mail: dev-help@pekko.apache.org
>>
>>
>
> --
>
> Matthew de Detrich
>
> *Aiven Deutschland GmbH*
>
> Immanuelkirchstraße 26, 10405 Berlin
>
> Amtsgericht Charlottenburg, HRB 209739 B
>
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
>
> *m:* +491603708037
>
> *w:* aiven.io *e:* matthew.dedetrich@aiven.io
>
--
Matthew de Detrich
*Aiven Deutschland GmbH*
Immanuelkirchstraße 26, 10405 Berlin
Amtsgericht Charlottenburg, HRB 209739 B
Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
*m:* +491603708037
*w:* aiven.io *e:* matthew.dedetrich@aiven.io
Re: [DISCUSS] Dependency updates in Apache Pekko Core + modules
Posted by Matthew de Detrich <ma...@aiven.io.INVALID>.
> Approval, probably yes, and we can see that as a feature. Secrets
should not be accessible but that is not a problem as PR validation
should not need secrets.
With Pekko Connectors this is actually no longer the case, there are tests
that require secrets to work because they run against actual services (as
opposed to a local docker).
Currently this is with S3 tests and this was added in because actual
regressions
were made in the pekko-connectors S3 client due to the fact that its not
possible to test all cases with docker services (with S3 specifically this
is
the minio docker image).
I also expect that this will increase over time, there are other
connectors where the equivalent Docker images are only able to test a
smaller
scope of features (gcs is another such connector and I am sure there will
be others).
On Thu, Sep 7, 2023 at 9:23 AM Johannes Rudolph <jo...@gmail.com>
wrote:
> On Wed, Sep 6, 2023 at 11:31 PM PJ Fanning <fa...@gmail.com> wrote:
> > Scala Steward creates PRs in our repos so the GitHub Actions CI that
> > we have set up in our repos will run as normal on those PRs. These PR
> > CI runs will have full access to our repo secrets. It could be that
> > someone in the Apache GitHub org will need to press a button on the PR
> > to allow it to run the CI - I've seen this when PRs originate from
> > users who are not part of the Apache GitHub org.
>
> Approval, probably yes, and we can see that as a feature. Secrets
> should not be accessible but that is not a problem as PR validation
> should not need secrets.
>
> So, I don't see any reason to use our own instance for now.
>
> Incidentally, to make the updates less frequent I used to set a
> schedule to when those Scala steward are proposed, e.g. only once a
> week on Tuesday mornings, so that it is easier for maintainers to
> expect those updates and deal with them in a batch.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>
--
Matthew de Detrich
*Aiven Deutschland GmbH*
Immanuelkirchstraße 26, 10405 Berlin
Amtsgericht Charlottenburg, HRB 209739 B
Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
*m:* +491603708037
*w:* aiven.io *e:* matthew.dedetrich@aiven.io
Re: [DISCUSS] Dependency updates in Apache Pekko Core + modules
Posted by Johannes Rudolph <jo...@gmail.com>.
On Wed, Sep 6, 2023 at 11:31 PM PJ Fanning <fa...@gmail.com> wrote:
> Scala Steward creates PRs in our repos so the GitHub Actions CI that
> we have set up in our repos will run as normal on those PRs. These PR
> CI runs will have full access to our repo secrets. It could be that
> someone in the Apache GitHub org will need to press a button on the PR
> to allow it to run the CI - I've seen this when PRs originate from
> users who are not part of the Apache GitHub org.
Approval, probably yes, and we can see that as a feature. Secrets
should not be accessible but that is not a problem as PR validation
should not need secrets.
So, I don't see any reason to use our own instance for now.
Incidentally, to make the updates less frequent I used to set a
schedule to when those Scala steward are proposed, e.g. only once a
week on Tuesday mornings, so that it is easier for maintainers to
expect those updates and deal with them in a batch.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: [DISCUSS] Dependency updates in Apache Pekko Core + modules
Posted by PJ Fanning <fa...@gmail.com>.
Reasonable point about starting with just pekko and pekko-http.
Scala Steward creates PRs in our repos so the GitHub Actions CI that
we have set up in our repos will run as normal on those PRs. These PR
CI runs will have full access to our repo secrets. It could be that
someone in the Apache GitHub org will need to press a button on the PR
to allow it to run the CI - I've seen this when PRs originate from
users who are not part of the Apache GitHub org.
On Wed, 6 Sept 2023 at 22:22, Matthew de Detrich
<ma...@aiven.io.invalid> wrote:
>
> Also I forgot to mention that the advantage of having our own runner for
> Scala Steward vs the default public VirtuisLabs one is that a runner in our
> own org has access to all of the github secrets which can be important for
> some integration tests (pekko-connectors has such a test).
>
> It basically allows us to test that dependency upgrades don't break
> something.
>
> On Wed, Sep 6, 2023 at 11:19 PM Matthew de Detrich <
> matthew.dedetrich@aiven.io> wrote:
>
> > > I would like to press on and add entries for our main repos to
> > https://github.com/VirtusLab/scala-steward-repos/blob/main/repos-github.md
> >
> > * pekko
> > * pekko-http
> > * pekko-connectors
> > * possibly more
> >
> > For pekko/pekko-http this can work since the 1.0.x branches have been
> > setup but for other repos we need to create the branches yet since we
> > shouldn't be getting dependency updates for the 1.0.x series unless they
> > contain CVE's/
> >
> > On Wed, Sep 6, 2023 at 7:25 PM PJ Fanning <fa...@apache.org> wrote:
> >
> >> I would like to press on and add entries for our main repos to
> >> https://github.com/VirtusLab/scala-steward-repos/blob/main/repos-github.md
> >>
> >> * pekko
> >> * pekko-http
> >> * pekko-connectors
> >> * possibly more
> >>
> >> There are some Apache repos already managed this way.
> >>
> >> We can set up our own job later but it would be nice to get moving on
> >> this and using the VirtusLab integration is trivial to set up. We can undo
> >> it if we get too much noise in terms of generated PRs.
> >>
> >>
> >>
> >> On 2023/08/14 12:53:06 PJ Fanning wrote:
> >> > We intend to use Scala Steward. There doesn't appear to anything that
> >> matches Scala Steward's feature set for Scala based projects.
> >> >
> >> > The simplest approach is to add entries to this page and there is an
> >> automated job that will raise PRs:
> >> >
> >> https://github.com/VirtusLab/scala-steward-repos/blob/main/repos-github.md
> >> >
> >> > Matthew de Detrich has expressed a preference for us to run our own
> >> Scala Steward job.
> >> >
> >> > With dependencies between Pekko modules, we intend to follow:
> >> >
> >> >
> >> https://pekko.apache.org/docs/pekko/current/project/downstream-upgrade-strategy.html
> >> >
> >> > With 3rd party dependencies, we will be conservative. If there are
> >> security issues, we will almost certainly upgrade to a secure version.
> >> Enabling Scala Steward will raise awareness of 3rd party jar releases but
> >> merging the PRs will not be automatic. They will need careful review.
> >> >
> >> >
> >> >
> >> > On 2023/08/14 10:06:57 Samuele Resca wrote:
> >> > > Hi,
> >> > >
> >> > > I'm opening a discussion regarding dependencies updates in Apache
> >> Pekko
> >> > > Core + modules. I saw that most of the Apache Pekko codebases already
> >> have
> >> > > the .scala-steward.conf file for automatically updating dependencies.
> >> > > Few questions that I have on top of my head:
> >> > > - Do we want to automate the stay current process in Apache Pekko
> >> (core +
> >> > > modules)?
> >> > > - Do we want scala-steward running on Apache Pekko Core + modules? Is
> >> > > there any other alternative system used by ASF projects?
> >> > > - Which subset of dependency do we want to update? (i.e: excluding
> >> > > intra-dependencies between Pekko modules)
> >> > > - Do we have a preference for the schedule (see:
> >> pullRequests.frequency)?
> >> > >
> >> > > Thanks in advance.
> >> > > Samuele
> >> > >
> >> >
> >> > ---------------------------------------------------------------------
> >> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> >> > For additional commands, e-mail: dev-help@pekko.apache.org
> >> >
> >> >
> >>
> >> ---------------------------------------------------------------------
> >> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> >> For additional commands, e-mail: dev-help@pekko.apache.org
> >>
> >>
> >
> > --
> >
> > Matthew de Detrich
> >
> > *Aiven Deutschland GmbH*
> >
> > Immanuelkirchstraße 26, 10405 Berlin
> >
> > Amtsgericht Charlottenburg, HRB 209739 B
> >
> > Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
> >
> > *m:* +491603708037
> >
> > *w:* aiven.io *e:* matthew.dedetrich@aiven.io
> >
>
>
> --
>
> Matthew de Detrich
>
> *Aiven Deutschland GmbH*
>
> Immanuelkirchstraße 26, 10405 Berlin
>
> Amtsgericht Charlottenburg, HRB 209739 B
>
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
>
> *m:* +491603708037
>
> *w:* aiven.io *e:* matthew.dedetrich@aiven.io
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: [DISCUSS] Dependency updates in Apache Pekko Core + modules
Posted by Matthew de Detrich <ma...@aiven.io.INVALID>.
Also I forgot to mention that the advantage of having our own runner for
Scala Steward vs the default public VirtuisLabs one is that a runner in our
own org has access to all of the github secrets which can be important for
some integration tests (pekko-connectors has such a test).
It basically allows us to test that dependency upgrades don't break
something.
On Wed, Sep 6, 2023 at 11:19 PM Matthew de Detrich <
matthew.dedetrich@aiven.io> wrote:
> > I would like to press on and add entries for our main repos to
> https://github.com/VirtusLab/scala-steward-repos/blob/main/repos-github.md
>
> * pekko
> * pekko-http
> * pekko-connectors
> * possibly more
>
> For pekko/pekko-http this can work since the 1.0.x branches have been
> setup but for other repos we need to create the branches yet since we
> shouldn't be getting dependency updates for the 1.0.x series unless they
> contain CVE's/
>
> On Wed, Sep 6, 2023 at 7:25 PM PJ Fanning <fa...@apache.org> wrote:
>
>> I would like to press on and add entries for our main repos to
>> https://github.com/VirtusLab/scala-steward-repos/blob/main/repos-github.md
>>
>> * pekko
>> * pekko-http
>> * pekko-connectors
>> * possibly more
>>
>> There are some Apache repos already managed this way.
>>
>> We can set up our own job later but it would be nice to get moving on
>> this and using the VirtusLab integration is trivial to set up. We can undo
>> it if we get too much noise in terms of generated PRs.
>>
>>
>>
>> On 2023/08/14 12:53:06 PJ Fanning wrote:
>> > We intend to use Scala Steward. There doesn't appear to anything that
>> matches Scala Steward's feature set for Scala based projects.
>> >
>> > The simplest approach is to add entries to this page and there is an
>> automated job that will raise PRs:
>> >
>> https://github.com/VirtusLab/scala-steward-repos/blob/main/repos-github.md
>> >
>> > Matthew de Detrich has expressed a preference for us to run our own
>> Scala Steward job.
>> >
>> > With dependencies between Pekko modules, we intend to follow:
>> >
>> >
>> https://pekko.apache.org/docs/pekko/current/project/downstream-upgrade-strategy.html
>> >
>> > With 3rd party dependencies, we will be conservative. If there are
>> security issues, we will almost certainly upgrade to a secure version.
>> Enabling Scala Steward will raise awareness of 3rd party jar releases but
>> merging the PRs will not be automatic. They will need careful review.
>> >
>> >
>> >
>> > On 2023/08/14 10:06:57 Samuele Resca wrote:
>> > > Hi,
>> > >
>> > > I'm opening a discussion regarding dependencies updates in Apache
>> Pekko
>> > > Core + modules. I saw that most of the Apache Pekko codebases already
>> have
>> > > the .scala-steward.conf file for automatically updating dependencies.
>> > > Few questions that I have on top of my head:
>> > > - Do we want to automate the stay current process in Apache Pekko
>> (core +
>> > > modules)?
>> > > - Do we want scala-steward running on Apache Pekko Core + modules? Is
>> > > there any other alternative system used by ASF projects?
>> > > - Which subset of dependency do we want to update? (i.e: excluding
>> > > intra-dependencies between Pekko modules)
>> > > - Do we have a preference for the schedule (see:
>> pullRequests.frequency)?
>> > >
>> > > Thanks in advance.
>> > > Samuele
>> > >
>> >
>> > ---------------------------------------------------------------------
>> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
>> > For additional commands, e-mail: dev-help@pekko.apache.org
>> >
>> >
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
>> For additional commands, e-mail: dev-help@pekko.apache.org
>>
>>
>
> --
>
> Matthew de Detrich
>
> *Aiven Deutschland GmbH*
>
> Immanuelkirchstraße 26, 10405 Berlin
>
> Amtsgericht Charlottenburg, HRB 209739 B
>
> Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
>
> *m:* +491603708037
>
> *w:* aiven.io *e:* matthew.dedetrich@aiven.io
>
--
Matthew de Detrich
*Aiven Deutschland GmbH*
Immanuelkirchstraße 26, 10405 Berlin
Amtsgericht Charlottenburg, HRB 209739 B
Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
*m:* +491603708037
*w:* aiven.io *e:* matthew.dedetrich@aiven.io
Re: [DISCUSS] Dependency updates in Apache Pekko Core + modules
Posted by Matthew de Detrich <ma...@aiven.io.INVALID>.
> I would like to press on and add entries for our main repos to
https://github.com/VirtusLab/scala-steward-repos/blob/main/repos-github.md
* pekko
* pekko-http
* pekko-connectors
* possibly more
For pekko/pekko-http this can work since the 1.0.x branches have been setup
but for other repos we need to create the branches yet since we shouldn't
be getting dependency updates for the 1.0.x series unless they contain
CVE's/
On Wed, Sep 6, 2023 at 7:25 PM PJ Fanning <fa...@apache.org> wrote:
> I would like to press on and add entries for our main repos to
> https://github.com/VirtusLab/scala-steward-repos/blob/main/repos-github.md
>
> * pekko
> * pekko-http
> * pekko-connectors
> * possibly more
>
> There are some Apache repos already managed this way.
>
> We can set up our own job later but it would be nice to get moving on this
> and using the VirtusLab integration is trivial to set up. We can undo it if
> we get too much noise in terms of generated PRs.
>
>
>
> On 2023/08/14 12:53:06 PJ Fanning wrote:
> > We intend to use Scala Steward. There doesn't appear to anything that
> matches Scala Steward's feature set for Scala based projects.
> >
> > The simplest approach is to add entries to this page and there is an
> automated job that will raise PRs:
> >
> https://github.com/VirtusLab/scala-steward-repos/blob/main/repos-github.md
> >
> > Matthew de Detrich has expressed a preference for us to run our own
> Scala Steward job.
> >
> > With dependencies between Pekko modules, we intend to follow:
> >
> >
> https://pekko.apache.org/docs/pekko/current/project/downstream-upgrade-strategy.html
> >
> > With 3rd party dependencies, we will be conservative. If there are
> security issues, we will almost certainly upgrade to a secure version.
> Enabling Scala Steward will raise awareness of 3rd party jar releases but
> merging the PRs will not be automatic. They will need careful review.
> >
> >
> >
> > On 2023/08/14 10:06:57 Samuele Resca wrote:
> > > Hi,
> > >
> > > I'm opening a discussion regarding dependencies updates in Apache Pekko
> > > Core + modules. I saw that most of the Apache Pekko codebases already
> have
> > > the .scala-steward.conf file for automatically updating dependencies.
> > > Few questions that I have on top of my head:
> > > - Do we want to automate the stay current process in Apache Pekko
> (core +
> > > modules)?
> > > - Do we want scala-steward running on Apache Pekko Core + modules? Is
> > > there any other alternative system used by ASF projects?
> > > - Which subset of dependency do we want to update? (i.e: excluding
> > > intra-dependencies between Pekko modules)
> > > - Do we have a preference for the schedule (see:
> pullRequests.frequency)?
> > >
> > > Thanks in advance.
> > > Samuele
> > >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> > For additional commands, e-mail: dev-help@pekko.apache.org
> >
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>
--
Matthew de Detrich
*Aiven Deutschland GmbH*
Immanuelkirchstraße 26, 10405 Berlin
Amtsgericht Charlottenburg, HRB 209739 B
Geschäftsführer: Oskari Saarenmaa & Hannu Valtonen
*m:* +491603708037
*w:* aiven.io *e:* matthew.dedetrich@aiven.io
Re: [DISCUSS] Dependency updates in Apache Pekko Core + modules
Posted by PJ Fanning <fa...@apache.org>.
I would like to press on and add entries for our main repos to
https://github.com/VirtusLab/scala-steward-repos/blob/main/repos-github.md
* pekko
* pekko-http
* pekko-connectors
* possibly more
There are some Apache repos already managed this way.
We can set up our own job later but it would be nice to get moving on this and using the VirtusLab integration is trivial to set up. We can undo it if we get too much noise in terms of generated PRs.
On 2023/08/14 12:53:06 PJ Fanning wrote:
> We intend to use Scala Steward. There doesn't appear to anything that matches Scala Steward's feature set for Scala based projects.
>
> The simplest approach is to add entries to this page and there is an automated job that will raise PRs:
> https://github.com/VirtusLab/scala-steward-repos/blob/main/repos-github.md
>
> Matthew de Detrich has expressed a preference for us to run our own Scala Steward job.
>
> With dependencies between Pekko modules, we intend to follow:
>
> https://pekko.apache.org/docs/pekko/current/project/downstream-upgrade-strategy.html
>
> With 3rd party dependencies, we will be conservative. If there are security issues, we will almost certainly upgrade to a secure version. Enabling Scala Steward will raise awareness of 3rd party jar releases but merging the PRs will not be automatic. They will need careful review.
>
>
>
> On 2023/08/14 10:06:57 Samuele Resca wrote:
> > Hi,
> >
> > I'm opening a discussion regarding dependencies updates in Apache Pekko
> > Core + modules. I saw that most of the Apache Pekko codebases already have
> > the .scala-steward.conf file for automatically updating dependencies.
> > Few questions that I have on top of my head:
> > - Do we want to automate the stay current process in Apache Pekko (core +
> > modules)?
> > - Do we want scala-steward running on Apache Pekko Core + modules? Is
> > there any other alternative system used by ASF projects?
> > - Which subset of dependency do we want to update? (i.e: excluding
> > intra-dependencies between Pekko modules)
> > - Do we have a preference for the schedule (see: pullRequests.frequency)?
> >
> > Thanks in advance.
> > Samuele
> >
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
> For additional commands, e-mail: dev-help@pekko.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org
Re: [DISCUSS] Dependency updates in Apache Pekko Core + modules
Posted by PJ Fanning <fa...@apache.org>.
We intend to use Scala Steward. There doesn't appear to anything that matches Scala Steward's feature set for Scala based projects.
The simplest approach is to add entries to this page and there is an automated job that will raise PRs:
https://github.com/VirtusLab/scala-steward-repos/blob/main/repos-github.md
Matthew de Detrich has expressed a preference for us to run our own Scala Steward job.
With dependencies between Pekko modules, we intend to follow:
https://pekko.apache.org/docs/pekko/current/project/downstream-upgrade-strategy.html
With 3rd party dependencies, we will be conservative. If there are security issues, we will almost certainly upgrade to a secure version. Enabling Scala Steward will raise awareness of 3rd party jar releases but merging the PRs will not be automatic. They will need careful review.
On 2023/08/14 10:06:57 Samuele Resca wrote:
> Hi,
>
> I'm opening a discussion regarding dependencies updates in Apache Pekko
> Core + modules. I saw that most of the Apache Pekko codebases already have
> the .scala-steward.conf file for automatically updating dependencies.
> Few questions that I have on top of my head:
> - Do we want to automate the stay current process in Apache Pekko (core +
> modules)?
> - Do we want scala-steward running on Apache Pekko Core + modules? Is
> there any other alternative system used by ASF projects?
> - Which subset of dependency do we want to update? (i.e: excluding
> intra-dependencies between Pekko modules)
> - Do we have a preference for the schedule (see: pullRequests.frequency)?
>
> Thanks in advance.
> Samuele
>
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@pekko.apache.org
For additional commands, e-mail: dev-help@pekko.apache.org