Hi,
While option #2 looks very appealing it seems not bulletproof
reliable, someone can occasionally miss @Nullable annotation. Option
#3 seems more practical too me, as missed @NotNull annotations cannot
do much harm.
Also I am thinking about using nullable parameters in general. Perhaps
we can
+1
On Fri, Dec 17, 2021 at 6:01 AM Denis Magda wrote:
> +1 (binding)
>
> -
> Denis
>
>
> On Fri, Dec 17, 2021 at 7:20 AM Maxim Muzafarov wrote:
>
> > The release candidate for the 2.11.1 version is ready.
> >
> >
> > I have uploaded a release candidate to:
> >
+1 (binding)
-
Denis
On Fri, Dec 17, 2021 at 7:20 AM Maxim Muzafarov wrote:
> The release candidate for the 2.11.1 version is ready.
>
>
> I have uploaded a release candidate to:
> https://dist.apache.org/repos/dist/dev/ignite/2.11.1-rc1/
>
There was a reason to store VCS settings in ROOT project — minimising git polls
which often caused 'too many connections' error, because each new VCS is
separate instance even if it is the same as in the other project.
Duplicating VCSs will reduce git performance.
Also — if we are going to
Hi,
Thanks for your comment. I rebuilt the documentation and pushed all
changes. Now all should be fine.
On Fri, Dec 17, 2021 at 1:47 PM 18624049226 <18624049...@163.com> wrote:
> Hi,
>
> It seems that all documents are unpublished version 2.12 documents?
>
> For example, the following
Hi Maxim, Ivan,
Thank you for the clarification. So, I have no objections.
+1
Thanks,
S.
пт, 17 дек. 2021 г. в 16:35, Ivan Daschinsky :
> Slava, unfortunately, after some works that improves C++ bulding process,
> now it is impossible to build old releases.
>
> пт, 17 дек. 2021 г. в 16:28,
Petr,
> However, ROOT project will still be not under VCS and some major settings
like VCS roots, Clean-Up rules, custom step runners and so much more will
stay out of Git-based sync.
VCS roots are project-related and should not be stored somewhere outside
the project.
Also, having different
Slava, unfortunately, after some works that improves C++ bulding process,
now it is impossible to build old releases.
пт, 17 дек. 2021 г. в 16:28, Вячеслав Коптилин :
> Hello Maxim,
>
> Honestly, I don't quite understand why ODBC improvement is included in the
> release.
> It seems to me, we
Slava,
The release build scripts have been changed [1]. It's not possible to
build 2.11 from scratch. Since we are going the fastest route (and
safest I suppose) it's better to cherry-pick these changes to the
release rather than changing something on TC.
[1]
Hello Maxim,
Honestly, I don't quite understand why ODBC improvement is included in the
release.
It seems to me, we have an agreement that the scope of the 2.11.1 release
will be limited by log4j issues.
Thanks,
S.
пт, 17 дек. 2021 г. в 15:20, Maxim Muzafarov :
> The release candidate for the
Hi Nikita,
The proposed timeline looks great. Thank you!
Slava.
пт, 17 дек. 2021 г. в 15:32, Nikita Amelchev :
> Hello, Slava.
>
> I am planning the following timeline:
>
> Voting Date: December 20, 2021
> Release Date: December 27, 2021
>
> чт, 16 дек. 2021 г. в 11:52, Вячеслав Коптилин :
> >
Separate JIRA project will ruin the concept of introducing changes for both
code and build settings in single branch of single project.
> On 17 Dec 2021, at 15:14, Anton Vinogradov wrote:
>
> Petr,
>
>> I strongly suggest avoiding a separate repository for project settings.
>> Let's store
Using Kotlin we no longer need templates, as any build configuration (as
object) can be heavily customised, parametrised and reused as many times as you
like.
However, if we are going to separate build settings per project, in me
experience — we may need some kind of lib with common
We CAN store build settings per project — ignite, ignite-3, ignite-extensions
and so on.
However, ROOT project will still be not under VCS and some major settings like
VCS roots, Clean-Up rules, custom step runners and so much more will stay out
of Git-based sync.
And in order to achieve full
>I thought we can store 3.x settings in 3.x repo and so on.
It's not a good idea to use different repositories.
Ignite also has many different modules, but all are situated in the same
project.
If we use different repositories, we can get a situation when a template
from another project will
Hello, Slava.
I am planning the following timeline:
Voting Date: December 20, 2021
Release Date: December 27, 2021
чт, 16 дек. 2021 г. в 11:52, Вячеслав Коптилин :
>
> Hello Nikita,
>
> > I have cherry-picked the issue [1] to the 2.12. It updates the log4j
> version to 2.16.
> Thanks a lot!
>
>
+1
Checked binary packages, .NET examples and NuGets.
On Fri, Dec 17, 2021 at 3:20 PM Maxim Muzafarov wrote:
> The release candidate for the 2.11.1 version is ready.
>
>
> I have uploaded a release candidate to:
> https://dist.apache.org/repos/dist/dev/ignite/2.11.1-rc1/
>
The release candidate for the 2.11.1 version is ready.
I have uploaded a release candidate to:
https://dist.apache.org/repos/dist/dev/ignite/2.11.1-rc1/
https://dist.apache.org/repos/dist/dev/ignite/packages_2.11.1-rc1/
The following staging can be used for testing:
Petr,
> I strongly suggest avoiding a separate repository for project settings.
> Let's store them in https://github.com/apache/ignite
Sounds good, but we must avoid dozens of additional commits in this case.
Each commit should be properly formalized and related to the issue.
We may create a
Maksim, thank you for the suggestion.
I've never used NullAway, but after having a quick look I think it might be
an overkill, since it is a plugin for the ErrorProne, which is a separate
tool. I recall some efforts of introducing ErrorProne to Ignite 3 and they
were not successful. But again, I
Petr,
> why should I edit code in Apache Ignite 2.x repo to introduce new changes
in Apache Ignite 3.x build settings
I thought we can store 3.x settings in 3.x repo and so on.
Looks like it does not work as I hoped it would.
Thanks for your answers.
On Fri, Dec 17, 2021 at 2:35 PM Petr Ivanov
Pavel,
If you are referring to this paragraph
• If you are using TeamCity feature branches, you can define a branch
specification when creating a project from URL (Git only) or in the VCS root
used for versioned settings. TeamCity will run a build in a branch using the
settings from
Thanks for the update!
On Thu, Dec 16, 2021 at 9:07 PM Виталий Осилов
wrote:
> Hi!
> TeamCity server https://ci2.ignite.apache.org/ will be unavailable on
> Friday 17.12 from 22:00 MSK to 00:00 MSK
> Works will be done to synchronize the TeamCity configuration
> https://ci2.ignite.apache.org/
Petr,
> you cannot run new suite added in branch because it just won't be visible
from UI
That's unfortunate.
However, a more important scenario is "make changes to the existing project
in a branch", which is supported, as I understand [1]
[1]
I've dropped GitBox in favour of GitHub — the build [1] has started.
[1]
https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/6329862
> On 17 Dec 2021, at 13:24, Maxim Muzafarov wrote:
>
> Petr,
>
> Thank you.
>
> Yes, I've added changes related to the new
TeamCity DSL just does not work as you wish it should.
Changes from branches are not visible: you cannot run new suite added in branch
because it just won't be visible from UI because project UI is rendered from
default branch only),
and at least snapshot dependencies are taken from default
Witaliy,
> repository is created
> only in the master branch
I strongly suggest avoiding a separate repository for project settings.
Let's store them in https://github.com/apache/ignite
*1. We should be able to test code changes together with CI/CD changes.*
*2. We should be able to have
Petr,
Thank you.
Yes, I've added changes related to the new release build actions
(IGNITE-15678, IGNITE-15677). The ignite-2.12 branch seems to be
working fine, however, at the ignite-2.11.1 the error with "too many
requests" appears from time to time. Here is an example of such a
build [1].
Concerning Too many requests error, I see the following problem:
Your request has been rate limited, as we have detected excessive usage from
your IP or net block:
15.575 SECONDS OF TIME SPENT OVER 120 SECONDS, MAX ALLOWED IS 15.
Rate-limits are automatic and reset every two minutes.
If you
Permissions updated.
> On 17 Dec 2021, at 13:09, Petr Ivanov wrote:
>
> Could you please add links to builds that are malfunctioning?
> As much as I see here [1] and here [2] — the release build changed to comply
> with 2.12 changes that are not merged to 2.11.1
>
>
> [1]
>
+1 for option No. 2.
On Fri, 17 Dec 2021 at 12:10, Maksim Timonin
wrote:
> Hi!
>
> There is a pretty popular project NullAway [1] that checks code of a
> project in compile-time for possible NPE. AFAIK, it works only with the
> "@Nullable" annotation. I think we can try to add this check to
Could you please add links to builds that are malfunctioning?
As much as I see here [1] and here [2] — the release build changed to comply
with 2.12 changes that are not merged to 2.11.1
[1]
https://ci.ignite.apache.org/buildConfiguration/Releases_ApacheIgniteMain_ReleaseBuild/6329822
[2]
Hello Petr,
Can you please assist with configuring the Release Teamcity suite that
has been changed for 2.x a month ago? These changes haven't been
discussed on the dev-list, so I'm not familiar with them.
I've faced several issues:
- the default role for Apache Ignite 2.x (Release) suite is
Hi!
There is a pretty popular project NullAway [1] that checks code of a
project in compile-time for possible NPE. AFAIK, it works only with the
"@Nullable" annotation. I think we can try to add this check to Ignite2 and
3.
But I wonder, whether smbd already tried to introduce this check? If
Dear Ignite Community!
I propose for discussion the conception of using two TeamCity servers with
a roadmap.
https://ci.ignite.apache.org/
https://ci2.ignite.apache.org/
Storing project settings.
Servers synchronize configurations between themselves using the version
control-storing DSL
35 matches
Mail list logo
