> merge to master only fully finished features It's already true for Ignite master branch.
В Вт, 24/09/2019 в 09:03 +0300, Alexey Zinoviev пишет: > The planned before 2_3 months release dates are good defender from > partially merged features, In my opinion > > Or we should have Master and dev branch separetely, and merge to master > only fully finished features > > пн, 23 сент. 2019 г., 20:27 Maxim Muzafarov <mmu...@apache.org>: > > > Andrey, > > > > Agree with you. It can affect the user impression. > > > > Can you advise, how can we guarantee in our case when we complete with > > current partially merged features that someone will not partially > > merge the new one? Should we monitor the master branch commits for > > such purpose? > > > > On Mon, 23 Sep 2019 at 20:18, Andrey Gura <ag...@apache.org> wrote: > > > > > > Maxim, > > > > > > > > From my point, if some components will not be ready by > > > > > previously discussed `scope freeze` date it is absolutely OK to > > > > > perform the next (e.g. 2.8.1, 2.8.2) releases. > > > > > > It is good approach if partial implemented features aren't merged to > > > master branch. Unfortunately this is not our case. > > > > > > I don't see any reasons to force new Apache Ignite release. Time is > > > not driver for release. If we want release Ignite periodically we must > > > significantly review the process. And most valuable change in this > > > process is feature branches that will not block new release by design. > > > > > > On Mon, Sep 23, 2019 at 8:12 PM Andrey Gura <ag...@apache.org> wrote: > > > > > > > > > > From my point of view monitoring isn't ready for release. > > > > > Can you clarify, what exactly is not ready? > > > > > Can we track planned changes somehow? > > > > > > > > We have too many not resolved tickets under IEP-35 label [1]. Also it > > > > makes sense to do some usability testing: JMX beans interfaces, system > > > > views, etc. > > > > > > > > > > > > [1] https://issues.apache.org/jira/issues/?jql=labels%20%3D%20IEP-35 > > > > > > > > On Mon, Sep 23, 2019 at 6:04 PM Nikolay Izhikov <nizhi...@apache.org> > > > > wrote: > > > > > > > > > > Hello, Andrey. > > > > > > > > > > > From my point of view monitoring isn't ready for release. > > > > > > > > > > Can you clarify, what exactly is not ready? > > > > > Can we track planned changes somehow? > > > > > > > > > > > > > > > В Пн, 23/09/2019 в 17:59 +0300, Andrey Gura пишет: > > > > > > Igniters, > > > > > > > > > > > > From my point of view monitoring isn't ready for release. So it > > > > would > > > > > > be great to return to this discussion later. It seems that > > > > beginning > > > > > > of November is good time for it. > > > > > > > > > > > > On Mon, Sep 23, 2019 at 5:37 PM Alexey Zinoviev < > > > > zaleslaw....@gmail.com> wrote: > > > > > > > > > > > > > > Nikolay Izhikov, ok, let's arrange the talk in ASF slack between > > > > 16 and 19 > > > > > > > MSK, is it possible? > > > > > > > > > > > > > > пн, 23 сент. 2019 г. в 17:35, Alexey Zinoviev < > > > > zaleslaw....@gmail.com>: > > > > > > > > > > > > > > > Ok, I'll clarify the situation > > > > > > > > > > > > > > > > 1. Currently, the ML module is like a black box for me. What > > > > exactly > > > > > > > > we are expected to get by the code freeze date? Do we have > > > > tickets we > > > > > > > > should address to? > > > > > > > > > > > > > > > > - Yes, we have a few epics that are not finished yet, due to > > > > limited free > > > > > > > > time the planned dates were written earlier > > > > > > > > > > > > > > > > 2. I think we can move code freeze date to December 11-th but, > > > > from > > > > > > > > your side, do you think that 2-weeks of stabilization and > > > > regression > > > > > > > > will be enough for the master branch living without release > > > > for a > > > > > > > > year? > > > > > > > > > > > > > > > > Ok, I've ready to move code freeze to your dates but not to 1 > > > > November, it > > > > > > > > sounds weird (why we should go so fast if haven't released > > > > during the year) > > > > > > > > I'm against fast releasing without planned dates. > > > > > > > > > > > > > > > > 3. What do you think about that we will make the huge 2.8 > > > > release in > > > > > > > > November with long period of branch stabilization and an > > > > additional > > > > > > > > 2.8.1 release with ML component in January? Such an approach > > > > have some > > > > > > > > advantages like we will not rush the development of ML > > > > components. > > > > > > > > > > > > > > > > The best idea here is ability to merge the last ML changes > > > > during > > > > > > > > stabilization period (bug fixing, tests and so on), is it ok > > > > for you? > > > > > > > > > > > > > > > > 2.8.1 could be a good point, but remind you guys, the normal > > > > practice to > > > > > > > > plan release for 2 months and ask another maintainers about > > > > another modules > > > > > > > > maybe the need additional clarification from another > > > > committers. > > > > > > > > > > > > > > > > пн, 23 сент. 2019 г. в 13:35, Nikolay Izhikov < > > > > nizhi...@apache.org>: > > > > > > > > > > > > > > > > > +1 to start releasing 2.8 in November or even in the end of > > > > October. > > > > > > > > > > > > > > > > > > Alex, can we schedule some quick meetings in the new Ignite > > > > Slack chat > > > > > > > > > and discuss all release date details? > > > > > > > > > Wendseday, 25 September is good for you? > > > > > > > > > > > > > > > > > > > > > > > > > > > В Пн, 23/09/2019 в 13:31 +0300, Maxim Muzafarov пишет: > > > > > > > > > > Alexey, > > > > > > > > > > > > > > > > > > > > Can you, please, clarify some questions. > > > > > > > > > > > > > > > > > > > > 1. Currently, the ML module is like a black box for me. > > > > What exactly > > > > > > > > > > we are expected to get by the code freeze date? Do we have > > > > tickets we > > > > > > > > > > should address to? > > > > > > > > > > > > > > > > > > > > 2. I think we can move code freeze date to December 11-th > > > > but, from > > > > > > > > > > your side, do you think that 2-weeks of stabilization and > > > > regression > > > > > > > > > > will be enough for the master branch living without > > > > release for a > > > > > > > > > > year? > > > > > > > > > > > > > > > > > > > > 3. What do you think about that we will make the huge 2.8 > > > > release in > > > > > > > > > > November with long period of branch stabilization and an > > > > additional > > > > > > > > > > 2.8.1 release with ML component in January? Such an > > > > approach have some > > > > > > > > > > advantages like we will not rush the development of ML > > > > components. > > > > > > > > > > > > > > > > > > > > On Fri, 20 Sep 2019 at 17:24, Alexey Zinoviev < > > > > zaleslaw....@gmail.com> > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > I wrote about code freeze at December 18, 2019, ok, we > > > > can move one > > > > > > > > > > > > > > > > > > week > > > > > > > > > > > earlier to 11 December > > > > > > > > > > > Voting + Release could be after 10th January. > > > > > > > > > > > > > > > > > > > > > > пт, 20 сент. 2019 г. в 15:43, Maxim Muzafarov < > > > > mmu...@apache.org>: > > > > > > > > > > > > > > > > > > > > > > > Alexey, > > > > > > > > > > > > > > > > > > > > > > > > It is not a problem to shift release a bit later or > > > > earlier, but I'm > > > > > > > > > > > > strictly against having `code freeze` stage on > > > > holidays (the > > > > > > > > > > > > > > > > > > Christmas > > > > > > > > > > > > holidays at the end of December and New Year holidays > > > > at the > > > > > > > > > > > > > > > > > > beginning > > > > > > > > > > > > of January). From my point, it's better to have it > > > > completed `code > > > > > > > > > > > > freeze` stage before December 23th or started after > > > > 10th January. > > > > > > > > > > > > > > > > > > > > > > > > Thoughts? > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > On Fri, 20 Sep 2019 at 15:09, Dmitriy Pavlov < > > > > dpav...@apache.org> > > > > > > > > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > > > > +1 For Maxim as release manager. > > > > > > > > > > > > > > > > > > > > > > > > > > Maxim, > > > > > > > > > > > > > > > > > > > > > > > > > > It is a good thing that you have committer rights, > > > > and most of > > > > > > > > > > > > > > > > > > the steps > > > > > > > > > > > > > you will be able to complete yourself. > > > > > > > > > > > > > > > > > > > > > > > > > > But please engage one from PMC member to complete > > > > steps from the > > > > > > > > > > > > > > > > > > release > > > > > > > > > > > > > process where PMC rights are required > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > https://cwiki.apache.org/confluence/display/IGNITE/Release+Process At > > > > > > > > > > > > > least, access to docker and nuget creds requires PMC > > > > membership. > > > > > > > > > > > > > > > > > > > > > > > > > > Feel free to ping me, I will assist, as well. > > > > > > > > > > > > > > > > > > > > > > > > > > Sincerely, > > > > > > > > > > > > > Dmitriy Pavlov > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > пт, 20 сент. 2019 г. в 14:59, Alexey Zinoviev < > > > > > > > > > > > > > > > > > > zaleslaw....@gmail.com>: > > > > > > > > > > > > > > > > > > > > > > > > > > > For Spark and ML components the best dates should > > > > be moved to > > > > > > > > > > > > > > > > > > one month > > > > > > > > > > > > > > later, what's about? > > > > > > > > > > > > > > There are a lot of features there, but a lot of > > > > bugs and minor > > > > > > > > > > > > > > improvements in JIRA too > > > > > > > > > > > > > > > > > > > > > > > > > > > > Also I support you as a release manager > > > > > > > > > > > > > > > > > > > > > > > > > > > > Scope Freeze: December 4, 2019 > > > > > > > > > > > > > > Code Freeze: December 18, 2019 > > > > > > > > > > > > > > Voting Date: January 10, 2019 > > > > > > > > > > > > > > Release Date: January 17, 2019 > > > > > > > > > > > > > > > > > > > > > > > > > > > > пт, 20 сент. 2019 г. в 14:44, Maxim Muzafarov < > > > > > > > > > > > > > > > > > > mmu...@apache.org>: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Igniters, > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > It's almost a year has passed since the last > > > > major Apache > > > > > > > > > > > > > > > > > > Ignite 2.7 > > > > > > > > > > > > > > > has been released. We've accumulated a lot of > > > > performance > > > > > > > > > > > > > > > > > > > > > > > > improvements > > > > > > > > > > > > > > > and a lot of new features which are waiting for > > > > their release > > > > > > > > > > > > > > > > > > date. > > > > > > > > > > > > > > > Here is my list of the most interesting things > > > > from my point > > > > > > > > > > > > > > > > > > since > > > > > > > > > > > > > > > > > > > > > > > > the > > > > > > > > > > > > > > > last major release: > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Service Grid, > > > > > > > > > > > > > > > Monitoring, > > > > > > > > > > > > > > > Recovery Read > > > > > > > > > > > > > > > BLT auto-adjust, > > > > > > > > > > > > > > > PDS compression, > > > > > > > > > > > > > > > WAL page compression, > > > > > > > > > > > > > > > Thin client: best effort affinity, > > > > > > > > > > > > > > > Thin client: transactions support (not yet) > > > > > > > > > > > > > > > SQL query history > > > > > > > > > > > > > > > SQL statistics > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I think we should no longer wait and freeze the > > > > master branch > > > > > > > > > > > > > > > > > > anymore > > > > > > > > > > > > > > > and prepare the next major release by the end of > > > > the year. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > I propose to discuss Time, Scope of Apache > > > > Ignite 2.8 release > > > > > > > > > > > > > > > > > > and > > > > > > > > > > > > > > > > > > > > > > > > also > > > > > > > > > > > > > > > I want to propose myself to be the release > > > > manager of the > > > > > > > > > > > > > > > > > > planning > > > > > > > > > > > > > > > release. > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Scope Freeze: November 4, 2019 > > > > > > > > > > > > > > > Code Freeze: November 18, 2019 > > > > > > > > > > > > > > > Voting Date: December 10, 2019 > > > > > > > > > > > > > > > Release Date: December 17, 2019 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > WDYT? > > > > > > > > > > > > > > >
signature.asc
Description: This is a digitally signed message part
