Also I noticed that ignite-3 repository has "main" but not "master" branch. Who can shed light on this? Did not find an explanation in this thread.
2020-12-22 13:09 GMT+03:00, Ivan Pavlukhin <vololo...@gmail.com>: > I noticed some free-from commit messages in ignite-3 repository. I > think we should use ticket-based workflow and commit messages as > usual. > > [1] https://github.com/apache/ignite-3/commits/main > > 2020-12-21 10:55 GMT+03:00, Petr Ivanov <mr.wei...@gmail.com>: >> There is no problem to have both in new repository, if skilled enthusiast >> will take over that job. >> >> I guess we will stick to Maven for time being but development of >> Gradle-based building system can be done in parallel. >> I can even add corresponding development build configurations for >> TeamCity, >> or even introduce some kind of switch — so that we can test old and new >> build approaches and provide seamless transition if we agree on that. >> >>> On 19 Dec 2020, at 01:00, Valentin Kulichenko >>> <valentin.kuliche...@gmail.com> wrote: >>> >>> Hi Ivan, >>> >>> There was a very brief discussion around this. Basically, it looks like >>> switching from Maven to something else is not going to bring much value, >>> but at the same time will be quite demanding because the community has >>> much >>> more experience with Maven. However, I would say that it is still >>> debatable at this point -- please feel free to share your thoughts on >>> this. >>> >>> -Val >>> >>> On Thu, Dec 17, 2020 at 10:53 PM Ivan Pavlukhin <vololo...@gmail.com> >>> wrote: >>> >>>> Hi Igniters, >>>> >>>> Forgive me that I am not reading dev list carefully these days. Was it >>>> explicitly decided that Maven should be used as a build system for >>>> Ignite 3? As there is a new repository we possibly can update our >>>> build tools as well. What do you think? >>>> >>>> 2020-12-17 22:45 GMT+03:00, Valentin Kulichenko < >>>> valentin.kuliche...@gmail.com>: >>>>> Hi Dmitriy, >>>>> >>>>> I don't think there is any reason for concern at this point. The >>>> community >>>>> agreed on the scope of the changes for 3.0 - it is described on Wiki. >>>>> The >>>>> scope is quite big, so it is clear that 2.x and 3.x will have to exist >>>>> in >>>>> parallel for a significant amount of time, so we need a place where we >>>> can >>>>> merge the code for 3.x. Thus, I've created this new repo. We already >>>>> have >>>>> multiple IEPs, as well as several contributors who are actively >>>>> involved >>>> in >>>>> development. Some of the first PRs were merged today. >>>>> >>>>> I didn't hear any objections since the repo was created. >>>>> >>>>> -Val >>>>> >>>>> On Wed, Dec 16, 2020 at 7:28 AM Dmitriy Pavlov <dpav...@apache.org> >>>> wrote: >>>>> >>>>>> Folks, I'm a little bit concerned about the simultaneous >>>>>> - existence of the repo https://github.com/apache/ignite-3 and PRs >>>>>> for >>>>>> that >>>>>> repo >>>>>> - and a couple of downvotes from PMC members. >>>>>> >>>>>> Is it all fine here? Was there any vote /discussion where it was >>>>>> discussed >>>>>> and consensus approved? What is the status of the ignite-3 repo? >>>>>> >>>>>> вт, 15 дек. 2020 г. в 17:30, Carbone, Adam >>>>>> <adam.carb...@bottomline.com >>>>> : >>>>>> >>>>>>> I don't believe Java 7 was LTS, and I hope that others will have >>>>>>> upgraded >>>>>>> long before that. If that is the release timeframe for 3.0, then I >>>>>> suppose >>>>>>> that would makes sense, I would still doubt that people would be >>>>>>> going >>>>>>> newer than java 11, just my opinion of what I'm seeing. >>>>>>> >>>>>>> Regards >>>>>>> ~adam >>>>>>> >>>>>>> Adam Carbone | Director of Innovation – Intelligent Platform Team | >>>>>>> Bottomline Technologies >>>>>>> Office: 603-501-6446 | Mobile: 603-570-8418 >>>>>>> www.bottomline.com >>>>>>> >>>>>>> >>>>>>> >>>>>>> On 12/15/20, 4:25 AM, "Ilya Kasnacheev" <ilya.kasnach...@gmail.com> >>>>>>> wrote: >>>>>>> >>>>>>> Hello! >>>>>>> >>>>>>> I guess Ignite 3.0 will be ready for production use somewhere in >>>>>> 2022, >>>>>>> realistically. By that time, Java 8 will be long enough out of >>>>>> support >>>>>>> so >>>>>>> that most companies will actually forbid its use, WRT >>>>>>> vulnerabilities >>>>>>> et >>>>>>> all. >>>>>>> >>>>>>> After all we have managed to upgrade from Java 7 to Java 8 and >>>> only >>>>>>> got a >>>>>>> minor amount of complaints. >>>>>>> >>>>>>> Regards, >>>>>>> -- >>>>>>> Ilya Kasnacheev >>>>>>> >>>>>>> >>>>>>> пн, 14 дек. 2020 г. в 19:06, Carbone, Adam < >>>>>>> adam.carb...@bottomline.com>: >>>>>>> >>>>>>>> So just one bit to consider... Are there features that you need >>>>>>> to >>>>>>> use in >>>>>>>> these newer versions of java? Or are we just updating to stay >>>>>>> current? The >>>>>>>> reason I ask is that there are still lots of people in an >>>>>> enterprise >>>>>>> space >>>>>>>> that are beholden to having to support legacy JAVAEE supported >>>>>>> applications >>>>>>>> on Websphere, Weblogic, Redhat, etc... and the organizations >>>> that >>>>>>> use those >>>>>>>> platforms are slow to move... Most of them are still on Java8 >>>>>>>> >>>>>>>> So as a platform I think a strong consideration needs to be >>>>>>> towards >>>>>>> having >>>>>>>> the broadest possible support profile until it becomes an >>>>>> impediment >>>>>>> to >>>>>>>> doing things that the platform needs. So far I haven't seen huge >>>>>>> things in >>>>>>>> the newer versions of java that are must haves ( a few >>>> exceptions >>>>>> are >>>>>>>> things that would be really nice to take advantage of ). >>>>>>>> >>>>>>>> I think that apache commons has taken the right approach by >>>>>>> staying >>>>>>> on >>>>>>>> java 8 giving the largest possible user base. >>>>>>>> >>>>>>>> Even standardizing on java 11 would have to make us reconsider >>>>>>> Ignite as >>>>>>>> the platform we are using, we are not so invested in it as of >>>>>>> now, >>>>>>> even >>>>>>>> though we have big plans to leverage it. Just because we aren't >>>>>> sure >>>>>>> when >>>>>>>> we are going to be able to upgrade from java8. It has support >>>>>>> through 2022, >>>>>>>> so I imagine that is when we will be discussing that. >>>>>>>> >>>>>>>> Regards >>>>>>>> >>>>>>>> ~Adam >>>>>>>> >>>>>>>> Adam Carbone | Director of Innovation – Intelligent Platform >>>> Team >>>>>>> | >>>>>>>> Bottomline Technologies >>>>>>>> Office: 603-501-6446 | Mobile: 603-570-8418 >>>>>>>> www.bottomline.com >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On 11/24/20, 7:38 AM, "Alexey Zinoviev" <zaleslaw....@gmail.com >>>>> >>>>>>> wrote: >>>>>>>> >>>>>>>> Java 15 is better, VarHandles, ForeignMemory access and so >>>>>>> on. >>>>>>>> >>>>>>>> In both cases, I support the Java version 11 and higher for >>>>>>> the >>>>>>>> development! >>>>>>>> >>>>>>>> вт, 24 нояб. 2020 г. в 15:21, Andrey Mashenkov < >>>>>>>> andrey.mashen...@gmail.com>: >>>>>>>> >>>>>>>>> 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://urldefense.com/v3/__https://issues.apache.org/jira/browse/IGNITE-13751__;!!O3mv9RujDHg!37ujwREhL1l-B3DmRXix6yaN1dE1KgH1Tx_tSl0eLZe4x1y0NnUlF4MzW5FeKAO2Ejs8$ >>>>>>>>> >>>>>>>>> On Tue, Nov 24, 2020 at 5:40 AM Valentin Kulichenko < >>>>>>>>> valentin.kuliche...@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://urldefense.com/v3/__https://github.com/apache/ignite-3__;!!O3mv9RujDHg!37ujwREhL1l-B3DmRXix6yaN1dE1KgH1Tx_tSl0eLZe4x1y0NnUlF4MzW5FeKIq24lxF$ >>>>>>>>>> [2] >>>>>>>> >>>>>>> >>>>>> >>>> https://urldefense.com/v3/__https://ci.ignite.apache.org/project/ignite3__;!!O3mv9RujDHg!37ujwREhL1l-B3DmRXix6yaN1dE1KgH1Tx_tSl0eLZe4x1y0NnUlF4MzW5FeKFGL_oJx$ >>>>>>>>>> [3] >>>>>>>>>> >>>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>> >>>>>> >>>> https://urldefense.com/v3/__https://cwiki.apache.org/confluence/display/IGNITE/Apache*Ignite*3.0*ApacheIgnite3.0-DevelopmentProcess__;Kysj!!O3mv9RujDHg!37ujwREhL1l-B3DmRXix6yaN1dE1KgH1Tx_tSl0eLZe4x1y0NnUlF4MzW5FeKNhWzQ0s$ >>>>>>>>>> >>>>>>>>>> -Val >>>>>>>>>> >>>>>>>>>> On Wed, Nov 18, 2020 at 4:24 PM Valentin Kulichenko < >>>>>>>>>> valentin.kuliche...@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.goncha...@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 >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>> >>>>> >>>> >>>> >>>> -- >>>> >>>> Best regards, >>>> Ivan Pavlukhin >>>> >> >> > > > -- > > Best regards, > Ivan Pavlukhin > -- Best regards, Ivan Pavlukhin
