ignite-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrey Mashenkov <andrey.mashen...@gmail.com>
Subject Re: [DISCUSS] Ignite 3.0 development approach
Date Tue, 24 Nov 2020 12:21:01 GMT
Let's add maven plugins  for sanity checks at the early stage.
I've created a ticket for this [1].

Also, I've found initial pom.xml has a target version Java 8.
Do we intend to move to Java 11 (or may be next LTS) and drop Java 8 in
Ignite 3.0?

[1] https://issues.apache.org/jira/browse/IGNITE-13751

On Tue, Nov 24, 2020 at 5:40 AM Valentin Kulichenko <
valentin.kulichenko@gmail.com> wrote:

> Folks,
>
> I went ahead and created the repository [1]. I also configured a TeamCity
> project [2] that runs all available JUnit tests on every PR creation or
> update. It also sends the status update to GitHub so that it's reflected in
> the PR itself so that we can do merges directly from GitHub. Basic steps to
> make a change are described on the Wiki page [3].
>
> Let me know if you have any questions.
>
> [1] https://github.com/apache/ignite-3
> [2] https://ci.ignite.apache.org/project/ignite3
> [3]
>
> https://cwiki.apache.org/confluence/display/IGNITE/Apache+Ignite+3.0#ApacheIgnite3.0-DevelopmentProcess
>
> -Val
>
> On Wed, Nov 18, 2020 at 4:24 PM Valentin Kulichenko <
> valentin.kulichenko@gmail.com> wrote:
>
> > Thanks, guys. It looks like we are much closer to the consensus now. I
> > totally on board with the plan, but I would also like to address the
> > short-term needs. As I've already mentioned earlier, there are several
> > active IEPs, but we still don't have even a preliminary technical process
> > for working on these IEPs. I believe this might be frustrating for the
> > folks who would like to commit code.
> >
> > The scope we agreed on is quite big, and it will surely take significant
> > time to implement all the changes and stabilize them. Therefore, it's
> clear
> > to me that we will have to maintain 2.x and 3.x in parallel for quite
> some
> > time - this needs to be addressed somehow. I'm convinced that having a
> > separate repo is the ONLY way to do that, and so far, I haven't heard any
> > clear alternatives or reasons why we shouldn't do this.
> >
> > That said, I'm inclined to proceed with this in the next few days - I
> will
> > create a repo and describe the process (which we, of course, can discuss
> > and modify going forward). Let's, at the very least, try and see where it
> > leads us.
> >
> > If someone has any concrete alternative options on how to we can maintain
> > two major versions in parallel, let's have another voice discussion this
> > Friday. If we do the meeting, we should set it up with a clear goal to
> make
> > a decision. Please let me know if there is interest in this.
> >
> > -Val
> >
> > On Mon, Nov 16, 2020 at 6:31 AM Alexey Goncharuk <
> > alexey.goncharuk@gmail.com> wrote:
> >
> >> Good,
> >>
> >> I think we have an intermediate agreement on the scope and significance
> of
> >> the changes we want to make. I suggest creating separate discussion
> >> streams
> >> and calls for each of the suggested topics so that:
> >>
> >>    - It is clear for the community what is the motivation of the stream
> >>    (this includes both functional targets and technical debt issues
> >> pointed
> >>    out by Sergey)
> >>    - Who is planning to take an active part in each of the streams (i.e.
> >>    the 'design committee', as Sergey suggested)
> >>    - What are the intermediate and final goals for each of the streams
> >>    - What are the cross-stream interactions and how we integrate them
> >>    - How each of the streams will be integrated with the current
> codebase
> >>    based on the above (here is where we will see whether drop-in or
> >>    incremental approaches make more sense)
> >>
> >
>


-- 
Best regards,
Andrey V. Mashenkov

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message