Aw: Re: Roadmap for 0.8.0

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Aw: Re: Roadmap for 0.8.0

Jan Rasehorn-2
Hi moon,

I think assuming the latest release would be unstable is confusing and not in line with other Apache projects. If you want to have a instable prerelease version, I would suggest to call it a beta version and once the major bugs are removed, a new stable release could be provided.

BR, Jan
--
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.
Am 21.03.17, 16:41, moon soo Lee <[hidden email]> schrieb:
And if i suggest simplest way for us to set quality expectation to user, which will be labeling release in download page.

Currently releases are divided into 2 categories in download page. 'Latest release' and 'Old releases'. I think we can treat 'Latest' as unstable and add one more category 'Stable release'.

For example, once 0.8.0 is released, 

Latest release : 0.8.0
Stable release : 0.7.1
Old release : 0.6.2, 0.6.1 ....

Once we feel confident about the stability of latest release, we can just change label from latest to stable in the download page. (and previous stable goes to old releases)
We can even include formal vote for moving release from 'latest' to 'stable' in our release process, if it is necessary.

Thanks,
moon

On Tue, Mar 21, 2017 at 6:59 AM moon soo Lee <[hidden email]> wrote:
Yes, having longer RC period will help.

But if i recall 0.7.0 release, although 21 people participated verifying through 4 RC for 15days, it wasn't enough to catch all critical problems during the release process. After the release, we've got much more number of bug reports, in next few days.

Basically, verifying RC is limited to people who subscribe mailing list + willing to contribute time to verify RC, which is much smaller number of people who download release from download page. So having longer RC period will definitely help and i think we should do, but I think it's still not enough to make sure the quality, considering past history.

AFAIK, releasing 0.8.0-preview, calling it unstable is up to the project. ASF release process defines how to release source code, but it does not really restrict what kind of 'version' the project should have releases. For example, spark released spark-2.0.0-preview[1] before spark-2.0.0.

Thanks,
moon



On Mon, Mar 20, 2017 at 11:31 PM Jongyoul Lee <[hidden email]> wrote:
I agree that it will help prolong RC period and use it actually. And also we need code freeze for the new features and spend time to stabilize RC.

On Tue, Mar 21, 2017 at 1:25 PM, Felix Cheung <[hidden email]> wrote:
+1 on quality and stabilization.

I'm not sure if releasing as preview or calling it unstable fits with the ASF release process though.

Other projects have code freeze, RC (and longer RC iteration time) etc. - do we think those will help improve quality when the release is finally cut?


_____________________________
From: Jianfeng (Jeff) Zhang <[hidden email]>
Sent: Monday, March 20, 2017 6:13 PM
Subject: Re: Roadmap for 0.8.0
To: <[hidden email]>, dev <[hidden email]>



Strongly +1 for adding system test for different interpreter modes and focus on bug fixing than new features. I do heard from some users complain about the bugs of zeppelin major release. A stabilized release is very necessary for community.




Best Regard,
Jeff Zhang


From: moon soo Lee <[hidden email]<[hidden email]>>
Reply-To: "[hidden email]<[hidden email]>" <[hidden email]<[hidden email]>>
Date: Tuesday, March 21, 2017 at 4:10 AM
To: "[hidden email]<[hidden email]>" <[hidden email]<[hidden email]>>, dev <[hidden email]<[hidden email]>>

Subject: Re: Roadmap for 0.8.0

Great to see discussion for 0.8.0.
List of features for 0.8.0 looks really good.

Interpreter factory refactoring
Interpreter layer supports various behavior depends on combination of PerNote,PerUser / Shared,Scoped,Isolated. We'll need strong test cases for each combination as a first step.
Otherwise, any pullrequest will silently break one of behavior at any time no matter we refactor or not. And fixing and testing this behavior is so hard.
Once we have complete test cases, not only guarantee the behavior but also make refactoring much easier.


0.8.0 release
I'd like to suggest improvements on how we release a new version.

In the past, 0.6.0 and 0.7.0 release with some critical problems. (took 3 months to stabilize 0.6 and we're working on stabilizing 0.7.0 for 2 months)

I think the same thing will happen again with 0.8.0, while we're going to make lots of changes and add many new features.
After we released 0.8.0, while 'Stabilizing' the new release, user who tried the new release may get wrong impression of the quality. Which is very bad and we already repeated the mistake in 0.6.0 and 0.7.0.

So from 0.8.0 release, I'd suggest we improve way we release new version to give user proper expectation. I think there're several ways of doing it.

1. Release 0.8.0-preview officially and then release 0.8.0.
2. Release 0.8.0 with 'beta' or 'unstable' label. And keep 0.7.x as a 'stable' release in the download page. Once 0.8.x release becomes stable enough make 0.8.x release as a 'stable' and move 0.7.x to 'old' releases.


After 0.8.0,
Since Zeppelin projects starts, project went through some major milestone, like

- project gets first users and first contributor
- project went into Apache Incubator
- project became TLP.

And I think it's time to think about hitting another major milestone.

Considering features we already have, features we're planning on 0.8, wide adoption of Zeppelin in the industry, I think it's time to focus on make project more mature and make a 1.0 release. Which i think big milestone for the project.

After 0.8.0 release, I suggest we more focus on bug fixes, stability improvement, optimizing user experience than adding new features. And with subsequent minor release, 0.8.1, 0.8.2 ... moment we feel confident about the quality, release it as a 1.0.0 instead of 0.8.x.

Once we have 1.0.0 released, then I think we can make larger, experimental changes on 2.0.0 branch aggressively, while we keep maintaining 1.0.x branch.


Thanks,
moon

On Mon, Mar 20, 2017 at 8:55 AM Felix Cheung <[hidden email]<[hidden email]>> wrote:
There are several pending visualization improvements/PRs that would be very good to get them in as well.


________________________________
From: Jongyoul Lee <[hidden email]<[hidden email]>>
Sent: Sunday, March 19, 2017 9:03:24 PM
To: dev; [hidden email]<[hidden email]>
Subject: Roadmap for 0.8.0

Hi dev & users,

Recently, community submits very new features for Apache Zeppelin. I think it's very positive signals to improve Apache Zeppelin and its community. But in another aspect, we should focus on what the next release includes. I think we need to summarize and prioritize them. Here is what I know:

* Cluster management
* Admin feature
* Replace some context to separate users
* Helium online

Feel free to talk if you want to add more things. I think we need to choose which features will be included in 0.8.0, too.

Regards,
Jongyoul Lee

--
이종열, Jongyoul Lee, 李宗烈
http://madeng.net





--
이종열, Jongyoul Lee, 李宗烈
Reply | Threaded
Open this post in threaded view
|

Re: Re: Roadmap for 0.8.0

moon
Administrator
Thanks for the opinion. Yes we can think about proper label. These are labels mentioned in this threads so far.

'Unstable', 'Stable', 'Old'
'Latest', 'Stable', 'Old'
'Beta', 'Stable', 'Old'

Intention is not that we want to release 'unstable' version, i think.
The intention is give user proper expectation that latest release may(and may not) include bug which we couldn't discovered in verification process like what happened in our previous release 0.7.0 and 0.6.0.

These are how other apache projects describe their releases.

Kafka - x.x.z is the latest release. current stable version is x.y.z.
Flink - x.y.z is our latest stable release
Cassandra - even-numbered contains new features, odd-numbered contains bug fixes only
Spark - available 2.1.0, 2.0.2, 2.0.1, 2.0.0 .... 1.4.0 as a 'stable' release, others are available as 'archived' releases.
Mesos - most recent stable release: x.y.z
Hadoop - 'x.y.z-alpha' or 'x.y.z' or 'x.y.z (stable)'
Hbase - 1.2.x series is current stable release. (while 1.3.x series does not have a label)

As you can see, it's difficult to find common rule what 'latest' should mean in Apache projects.

Considering the intention that we're not intentionally releasing 'unstable' version, i prefer 'latest / stable' tiny bit more than 'beta / stable'.

I'd like hear more opinions.

Thanks,
moon

On Tue, Mar 21, 2017 at 9:16 AM Jan Rasehorn <[hidden email]> wrote:
Hi moon,

I think assuming the latest release would be unstable is confusing and not in line with other Apache projects. If you want to have a instable prerelease version, I would suggest to call it a beta version and once the major bugs are removed, a new stable release could be provided.

BR, Jan
--
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.
Am 21.03.17, 16:41, moon soo Lee <[hidden email]> schrieb:
And if i suggest simplest way for us to set quality expectation to user, which will be labeling release in download page.

Currently releases are divided into 2 categories in download page. 'Latest release' and 'Old releases'. I think we can treat 'Latest' as unstable and add one more category 'Stable release'.

For example, once 0.8.0 is released, 

Latest release : 0.8.0
Stable release : 0.7.1
Old release : 0.6.2, 0.6.1 ....

Once we feel confident about the stability of latest release, we can just change label from latest to stable in the download page. (and previous stable goes to old releases)
We can even include formal vote for moving release from 'latest' to 'stable' in our release process, if it is necessary.

Thanks,
moon

On Tue, Mar 21, 2017 at 6:59 AM moon soo Lee <[hidden email]> wrote:
Yes, having longer RC period will help.

But if i recall 0.7.0 release, although 21 people participated verifying through 4 RC for 15days, it wasn't enough to catch all critical problems during the release process. After the release, we've got much more number of bug reports, in next few days.

Basically, verifying RC is limited to people who subscribe mailing list + willing to contribute time to verify RC, which is much smaller number of people who download release from download page. So having longer RC period will definitely help and i think we should do, but I think it's still not enough to make sure the quality, considering past history.

AFAIK, releasing 0.8.0-preview, calling it unstable is up to the project. ASF release process defines how to release source code, but it does not really restrict what kind of 'version' the project should have releases. For example, spark released spark-2.0.0-preview[1] before spark-2.0.0.

Thanks,
moon



On Mon, Mar 20, 2017 at 11:31 PM Jongyoul Lee <[hidden email]> wrote:
I agree that it will help prolong RC period and use it actually. And also we need code freeze for the new features and spend time to stabilize RC.

On Tue, Mar 21, 2017 at 1:25 PM, Felix Cheung <[hidden email]> wrote:
+1 on quality and stabilization.

I'm not sure if releasing as preview or calling it unstable fits with the ASF release process though.

Other projects have code freeze, RC (and longer RC iteration time) etc. - do we think those will help improve quality when the release is finally cut?


_____________________________
From: Jianfeng (Jeff) Zhang <[hidden email]>
Sent: Monday, March 20, 2017 6:13 PM
Subject: Re: Roadmap for 0.8.0
To: <[hidden email]>, dev <[hidden email]>



Strongly +1 for adding system test for different interpreter modes and focus on bug fixing than new features. I do heard from some users complain about the bugs of zeppelin major release. A stabilized release is very necessary for community.




Best Regard,
Jeff Zhang


From: moon soo Lee <[hidden email]<[hidden email]>>
Reply-To: "[hidden email]<[hidden email]>" <[hidden email]<[hidden email]>>
Date: Tuesday, March 21, 2017 at 4:10 AM
To: "[hidden email]<[hidden email]>" <[hidden email]<[hidden email]>>, dev <[hidden email]<[hidden email]>>

Subject: Re: Roadmap for 0.8.0

Great to see discussion for 0.8.0.
List of features for 0.8.0 looks really good.

Interpreter factory refactoring
Interpreter layer supports various behavior depends on combination of PerNote,PerUser / Shared,Scoped,Isolated. We'll need strong test cases for each combination as a first step.
Otherwise, any pullrequest will silently break one of behavior at any time no matter we refactor or not. And fixing and testing this behavior is so hard.
Once we have complete test cases, not only guarantee the behavior but also make refactoring much easier.


0.8.0 release
I'd like to suggest improvements on how we release a new version.

In the past, 0.6.0 and 0.7.0 release with some critical problems. (took 3 months to stabilize 0.6 and we're working on stabilizing 0.7.0 for 2 months)

I think the same thing will happen again with 0.8.0, while we're going to make lots of changes and add many new features.
After we released 0.8.0, while 'Stabilizing' the new release, user who tried the new release may get wrong impression of the quality. Which is very bad and we already repeated the mistake in 0.6.0 and 0.7.0.

So from 0.8.0 release, I'd suggest we improve way we release new version to give user proper expectation. I think there're several ways of doing it.

1. Release 0.8.0-preview officially and then release 0.8.0.
2. Release 0.8.0 with 'beta' or 'unstable' label. And keep 0.7.x as a 'stable' release in the download page. Once 0.8.x release becomes stable enough make 0.8.x release as a 'stable' and move 0.7.x to 'old' releases.


After 0.8.0,
Since Zeppelin projects starts, project went through some major milestone, like

- project gets first users and first contributor
- project went into Apache Incubator
- project became TLP.

And I think it's time to think about hitting another major milestone.

Considering features we already have, features we're planning on 0.8, wide adoption of Zeppelin in the industry, I think it's time to focus on make project more mature and make a 1.0 release. Which i think big milestone for the project.

After 0.8.0 release, I suggest we more focus on bug fixes, stability improvement, optimizing user experience than adding new features. And with subsequent minor release, 0.8.1, 0.8.2 ... moment we feel confident about the quality, release it as a 1.0.0 instead of 0.8.x.

Once we have 1.0.0 released, then I think we can make larger, experimental changes on 2.0.0 branch aggressively, while we keep maintaining 1.0.x branch.


Thanks,
moon

On Mon, Mar 20, 2017 at 8:55 AM Felix Cheung <[hidden email]<[hidden email]>> wrote:
There are several pending visualization improvements/PRs that would be very good to get them in as well.


________________________________
From: Jongyoul Lee <[hidden email]<[hidden email]>>
Sent: Sunday, March 19, 2017 9:03:24 PM
To: dev; [hidden email]<[hidden email]>
Subject: Roadmap for 0.8.0

Hi dev & users,

Recently, community submits very new features for Apache Zeppelin. I think it's very positive signals to improve Apache Zeppelin and its community. But in another aspect, we should focus on what the next release includes. I think we need to summarize and prioritize them. Here is what I know:

* Cluster management
* Admin feature
* Replace some context to separate users
* Helium online

Feel free to talk if you want to add more things. I think we need to choose which features will be included in 0.8.0, too.

Regards,
Jongyoul Lee

--
이종열, Jongyoul Lee, 李宗烈
http://madeng.net





--
이종열, Jongyoul Lee, 李宗烈
Reply | Threaded
Open this post in threaded view
|

Re: Re: Roadmap for 0.8.0

Ruslan Dautkhanov
Sorry for bringing up an older topic .. I agree "latest" / "stable" makes a lot of sense.

Also what was *not* discussed in this thread is release cadence target.
IMHO, 2-3 releases a year should give a quicker turnover to release latest fixes and improvements / quicker feedback from the users?

Would be great to see 0.8.0 release soon.. 
I see on github there were a lot of awesome additions/commits since the last release.

Thoughts?



On Tue, Mar 21, 2017 at 10:57 AM, moon soo Lee <[hidden email]> wrote:
Thanks for the opinion. Yes we can think about proper label. These are labels mentioned in this threads so far.

'Unstable', 'Stable', 'Old'
'Latest', 'Stable', 'Old'
'Beta', 'Stable', 'Old'

Intention is not that we want to release 'unstable' version, i think.
The intention is give user proper expectation that latest release may(and may not) include bug which we couldn't discovered in verification process like what happened in our previous release 0.7.0 and 0.6.0.

These are how other apache projects describe their releases.

Kafka - x.x.z is the latest release. current stable version is x.y.z.
Flink - x.y.z is our latest stable release
Cassandra - even-numbered contains new features, odd-numbered contains bug fixes only
Spark - available 2.1.0, 2.0.2, 2.0.1, 2.0.0 .... 1.4.0 as a 'stable' release, others are available as 'archived' releases.
Mesos - most recent stable release: x.y.z
Hadoop - 'x.y.z-alpha' or 'x.y.z' or 'x.y.z (stable)'
Hbase - 1.2.x series is current stable release. (while 1.3.x series does not have a label)

As you can see, it's difficult to find common rule what 'latest' should mean in Apache projects.

Considering the intention that we're not intentionally releasing 'unstable' version, i prefer 'latest / stable' tiny bit more than 'beta / stable'.

I'd like hear more opinions.

Thanks,
moon

On Tue, Mar 21, 2017 at 9:16 AM Jan Rasehorn <[hidden email]> wrote:
Hi moon,

I think assuming the latest release would be unstable is confusing and not in line with other Apache projects. If you want to have a instable prerelease version, I would suggest to call it a beta version and once the major bugs are removed, a new stable release could be provided.

BR, Jan
--
Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet.
Am 21.03.17, 16:41, moon soo Lee <[hidden email]> schrieb:
And if i suggest simplest way for us to set quality expectation to user, which will be labeling release in download page.

Currently releases are divided into 2 categories in download page. 'Latest release' and 'Old releases'. I think we can treat 'Latest' as unstable and add one more category 'Stable release'.

For example, once 0.8.0 is released, 

Latest release : 0.8.0
Stable release : 0.7.1
Old release : 0.6.2, 0.6.1 ....

Once we feel confident about the stability of latest release, we can just change label from latest to stable in the download page. (and previous stable goes to old releases)
We can even include formal vote for moving release from 'latest' to 'stable' in our release process, if it is necessary.

Thanks,
moon

On Tue, Mar 21, 2017 at 6:59 AM moon soo Lee <[hidden email]> wrote:
Yes, having longer RC period will help.

But if i recall 0.7.0 release, although 21 people participated verifying through 4 RC for 15days, it wasn't enough to catch all critical problems during the release process. After the release, we've got much more number of bug reports, in next few days.

Basically, verifying RC is limited to people who subscribe mailing list + willing to contribute time to verify RC, which is much smaller number of people who download release from download page. So having longer RC period will definitely help and i think we should do, but I think it's still not enough to make sure the quality, considering past history.

AFAIK, releasing 0.8.0-preview, calling it unstable is up to the project. ASF release process defines how to release source code, but it does not really restrict what kind of 'version' the project should have releases. For example, spark released spark-2.0.0-preview[1] before spark-2.0.0.

Thanks,
moon



On Mon, Mar 20, 2017 at 11:31 PM Jongyoul Lee <[hidden email]> wrote:
I agree that it will help prolong RC period and use it actually. And also we need code freeze for the new features and spend time to stabilize RC.

On Tue, Mar 21, 2017 at 1:25 PM, Felix Cheung <[hidden email]> wrote:
+1 on quality and stabilization.

I'm not sure if releasing as preview or calling it unstable fits with the ASF release process though.

Other projects have code freeze, RC (and longer RC iteration time) etc. - do we think those will help improve quality when the release is finally cut?


_____________________________
From: Jianfeng (Jeff) Zhang <[hidden email]>
Sent: Monday, March 20, 2017 6:13 PM
Subject: Re: Roadmap for 0.8.0
To: <[hidden email]>, dev <[hidden email]>



Strongly +1 for adding system test for different interpreter modes and focus on bug fixing than new features. I do heard from some users complain about the bugs of zeppelin major release. A stabilized release is very necessary for community.




Best Regard,
Jeff Zhang


From: moon soo Lee <[hidden email]<[hidden email]>>
Reply-To: "[hidden email]<[hidden email]>" <[hidden email]<[hidden email]>>
Date: Tuesday, March 21, 2017 at 4:10 AM
To: "[hidden email]<[hidden email]>" <[hidden email]<[hidden email]>>, dev <[hidden email]<[hidden email]>>

Subject: Re: Roadmap for 0.8.0

Great to see discussion for 0.8.0.
List of features for 0.8.0 looks really good.

Interpreter factory refactoring
Interpreter layer supports various behavior depends on combination of PerNote,PerUser / Shared,Scoped,Isolated. We'll need strong test cases for each combination as a first step.
Otherwise, any pullrequest will silently break one of behavior at any time no matter we refactor or not. And fixing and testing this behavior is so hard.
Once we have complete test cases, not only guarantee the behavior but also make refactoring much easier.


0.8.0 release
I'd like to suggest improvements on how we release a new version.

In the past, 0.6.0 and 0.7.0 release with some critical problems. (took 3 months to stabilize 0.6 and we're working on stabilizing 0.7.0 for 2 months)

I think the same thing will happen again with 0.8.0, while we're going to make lots of changes and add many new features.
After we released 0.8.0, while 'Stabilizing' the new release, user who tried the new release may get wrong impression of the quality. Which is very bad and we already repeated the mistake in 0.6.0 and 0.7.0.

So from 0.8.0 release, I'd suggest we improve way we release new version to give user proper expectation. I think there're several ways of doing it.

1. Release 0.8.0-preview officially and then release 0.8.0.
2. Release 0.8.0 with 'beta' or 'unstable' label. And keep 0.7.x as a 'stable' release in the download page. Once 0.8.x release becomes stable enough make 0.8.x release as a 'stable' and move 0.7.x to 'old' releases.


After 0.8.0,
Since Zeppelin projects starts, project went through some major milestone, like

- project gets first users and first contributor
- project went into Apache Incubator
- project became TLP.

And I think it's time to think about hitting another major milestone.

Considering features we already have, features we're planning on 0.8, wide adoption of Zeppelin in the industry, I think it's time to focus on make project more mature and make a 1.0 release. Which i think big milestone for the project.

After 0.8.0 release, I suggest we more focus on bug fixes, stability improvement, optimizing user experience than adding new features. And with subsequent minor release, 0.8.1, 0.8.2 ... moment we feel confident about the quality, release it as a 1.0.0 instead of 0.8.x.

Once we have 1.0.0 released, then I think we can make larger, experimental changes on 2.0.0 branch aggressively, while we keep maintaining 1.0.x branch.


Thanks,
moon

On Mon, Mar 20, 2017 at 8:55 AM Felix Cheung <[hidden email]<[hidden email]>> wrote:
There are several pending visualization improvements/PRs that would be very good to get them in as well.


________________________________
From: Jongyoul Lee <[hidden email]<[hidden email]>>
Sent: Sunday, March 19, 2017 9:03:24 PM
To: dev; [hidden email]<[hidden email]>
Subject: Roadmap for 0.8.0

Hi dev & users,

Recently, community submits very new features for Apache Zeppelin. I think it's very positive signals to improve Apache Zeppelin and its community. But in another aspect, we should focus on what the next release includes. I think we need to summarize and prioritize them. Here is what I know:

* Cluster management
* Admin feature
* Replace some context to separate users
* Helium online

Feel free to talk if you want to add more things. I think we need to choose which features will be included in 0.8.0, too.

Regards,
Jongyoul Lee

--
이종열, Jongyoul Lee, 李宗烈
http://madeng.net





--
이종열, Jongyoul Lee, 李宗烈