Re: [VOTE] Release Superset 0.34.0 based on Superset 0.34.0rc1

2019-08-09 Thread Ville Brofeldt
Hi all,

I believe this is a good point in time to cut the 0.34 release, as there
have been numerous important bugfixes and features introduced since 0.33,
with especially important license housekeeping in the form of removal of
requests (thanks Gianluca!) and FOSSA CI (thanks Max!). So would like to
extend my non-binding +1 to this. Fingers crossed!

Ville

On Fri, Aug 9, 2019 at 9:36 PM Maxime Beauchemin 
wrote:

> Dear all,
>
> The source release 0.34.0 RC1 for Apache Superset is baked and available
> at:
> https://dist.apache.org/repos/dist/dev/incubator/superset/, public
> keys are available
> at https://dist.apache.org/repos/dist/release/incubator/superset/KEYS
>
> We're using the 0.34 branch as the base for this first ASF release as
> opposed to 0.33 in previous attempts. I think all license-related issues
> have been ironed out in our dependency, here's the FOSSA report
> <
> https://app.fossa.com/projects/custom+11342%2f...@github.com:apache%2Fincubator-superset.git/refs/branch/0.34/a04fad858644466219b7ea399aead110cb8ea655
> >
> . *We're still ironing out our release process, so please bear with us and
> help if you can*.
>
> As I went along, I documented the process in [yet-to-be-merged]
> RELEASING/README.md in the repo, latest edits here #
> 8016
> . As part of
> `RELEASING/`, we ship docker files to help test releases in a reproducible
> way.
>
> For context the `0.34` release branch was cut at SHA 9233a63, that was
> merged on master on Aug 8th 2019. From that common ancestor, the following
> list of commit was added as cherry-picks. The SHAs in the list bellow
> reference the cherries on the release branch, PR number are available to
> get more details.
>
> 
>


Re: [Superset] Convenience Releases

2019-08-09 Thread Bolke de Bruin
I don't think there is a problem with that. Please note that as far as Apache 
is concerned any artefact consideres to be "Apache superset" needs to be 
available from it's official release location. So it's fine to "copy" this over 
to pypi/docker but not to have a "different" release at those locations. 

B.

P.S. a docker build would be nice, with proper security settings please ;-)

Sent from my iPhone

> On 9 Aug 2019, at 23:44, Maxime Beauchemin  wrote:
> 
> Hi all,
> 
> How should we go about convenience releases? Currently I'm thinking
> Pypi.org, but we could think about Docker / DockerHub as well.
> 
> First thing to know is that a convenience release for Superset is likely to
> contain minified [aka "compiled"] javascript out of hundreds of libs. In
> theory these libs are scanned and approved by FOSSA license-wise, and
> generating that report will be part of the release process. Is that ok? I
> mean is Apache ok with us distributing that bundle?
> 
> Alternatively, it could *not* contain the minified javascript. We'd have to
> find some solutions to a few challenges. Maybe run a new `superset
> build-js` CLI command that would:
> * bootstrap `npm` locally
> * download JS build deps
> * build locally (minutes)
> * find a place to put these files (can't mutate Python's install dir
> "site-packages")
> * ...
> 
> On the docker side, maybe an official Dockerfile, but no official DockerHub
> entry?
> 
> Max


Re: [Superset] Convenience Releases

2019-08-09 Thread Maxime Beauchemin
Oh no, looks like someone claimed "apache-superset" on pypi.org, probably
by mistake. https://pypi.org/user/cidiomar.dias.restoque/

On Fri, Aug 9, 2019 at 3:24 PM Maxime Beauchemin 
wrote:

> Airflow does it, so yes it's doable. Though we'll have to change the pypi
> package name to `apache-superset`. I think it's fair to push an RC as part
> of the RC release process.
>
> Max
>
> On Fri, Aug 9, 2019 at 2:55 PM Charles Givre  wrote:
>
>> My .02 would be to do all of the above.   Personally, being able to
>> install Superset via pip was really useful in starting the Superset
>> journey... I would also recommend an official Dockerfile.  I'm not sure why
>> you wouldn't want to push it to DockerHub, but if you want to make it easy
>> to adopt I'd push it there as well.  Other than the inconvenience factor,
>> I'm not sure why you'd want to limit the venues where people can access
>> Superset.
>>
>> IMHO, I would say that once versions are approved for release, they
>> should be pushed to Pypi, dockerhub etc.  I've never dealt with python
>> projects via Apache, but is the ASF ok with distributing software via Pypi?
>> Just my .02
>> -- C
>>
>>
>> > On Aug 9, 2019, at 5:44 PM, Maxime Beauchemin <
>> maximebeauche...@gmail.com> wrote:
>> >
>> > Hi all,
>> >
>> > How should we go about convenience releases? Currently I'm thinking
>> > Pypi.org, but we could think about Docker / DockerHub as well.
>> >
>> > First thing to know is that a convenience release for Superset is
>> likely to
>> > contain minified [aka "compiled"] javascript out of hundreds of libs. In
>> > theory these libs are scanned and approved by FOSSA license-wise, and
>> > generating that report will be part of the release process. Is that ok?
>> I
>> > mean is Apache ok with us distributing that bundle?
>> >
>> > Alternatively, it could *not* contain the minified javascript. We'd
>> have to
>> > find some solutions to a few challenges. Maybe run a new `superset
>> > build-js` CLI command that would:
>> > * bootstrap `npm` locally
>> > * download JS build deps
>> > * build locally (minutes)
>> > * find a place to put these files (can't mutate Python's install dir
>> > "site-packages")
>> > * ...
>> >
>> > On the docker side, maybe an official Dockerfile, but no official
>> DockerHub
>> > entry?
>> >
>> > Max
>>
>>


Re: [Superset] Convenience Releases

2019-08-09 Thread Maxime Beauchemin
Airflow does it, so yes it's doable. Though we'll have to change the pypi
package name to `apache-superset`. I think it's fair to push an RC as part
of the RC release process.

Max

On Fri, Aug 9, 2019 at 2:55 PM Charles Givre  wrote:

> My .02 would be to do all of the above.   Personally, being able to
> install Superset via pip was really useful in starting the Superset
> journey... I would also recommend an official Dockerfile.  I'm not sure why
> you wouldn't want to push it to DockerHub, but if you want to make it easy
> to adopt I'd push it there as well.  Other than the inconvenience factor,
> I'm not sure why you'd want to limit the venues where people can access
> Superset.
>
> IMHO, I would say that once versions are approved for release, they should
> be pushed to Pypi, dockerhub etc.  I've never dealt with python projects
> via Apache, but is the ASF ok with distributing software via Pypi?
> Just my .02
> -- C
>
>
> > On Aug 9, 2019, at 5:44 PM, Maxime Beauchemin <
> maximebeauche...@gmail.com> wrote:
> >
> > Hi all,
> >
> > How should we go about convenience releases? Currently I'm thinking
> > Pypi.org, but we could think about Docker / DockerHub as well.
> >
> > First thing to know is that a convenience release for Superset is likely
> to
> > contain minified [aka "compiled"] javascript out of hundreds of libs. In
> > theory these libs are scanned and approved by FOSSA license-wise, and
> > generating that report will be part of the release process. Is that ok? I
> > mean is Apache ok with us distributing that bundle?
> >
> > Alternatively, it could *not* contain the minified javascript. We'd have
> to
> > find some solutions to a few challenges. Maybe run a new `superset
> > build-js` CLI command that would:
> > * bootstrap `npm` locally
> > * download JS build deps
> > * build locally (minutes)
> > * find a place to put these files (can't mutate Python's install dir
> > "site-packages")
> > * ...
> >
> > On the docker side, maybe an official Dockerfile, but no official
> DockerHub
> > entry?
> >
> > Max
>
>


Re: [Superset] Convenience Releases

2019-08-09 Thread Charles Givre
My .02 would be to do all of the above.   Personally, being able to install 
Superset via pip was really useful in starting the Superset journey... I would 
also recommend an official Dockerfile.  I'm not sure why you wouldn't want to 
push it to DockerHub, but if you want to make it easy to adopt I'd push it 
there as well.  Other than the inconvenience factor, I'm not sure why you'd 
want to limit the venues where people can access Superset.

IMHO, I would say that once versions are approved for release, they should be 
pushed to Pypi, dockerhub etc.  I've never dealt with python projects via 
Apache, but is the ASF ok with distributing software via Pypi?
Just my .02
-- C


> On Aug 9, 2019, at 5:44 PM, Maxime Beauchemin  
> wrote:
> 
> Hi all,
> 
> How should we go about convenience releases? Currently I'm thinking
> Pypi.org, but we could think about Docker / DockerHub as well.
> 
> First thing to know is that a convenience release for Superset is likely to
> contain minified [aka "compiled"] javascript out of hundreds of libs. In
> theory these libs are scanned and approved by FOSSA license-wise, and
> generating that report will be part of the release process. Is that ok? I
> mean is Apache ok with us distributing that bundle?
> 
> Alternatively, it could *not* contain the minified javascript. We'd have to
> find some solutions to a few challenges. Maybe run a new `superset
> build-js` CLI command that would:
> * bootstrap `npm` locally
> * download JS build deps
> * build locally (minutes)
> * find a place to put these files (can't mutate Python's install dir
> "site-packages")
> * ...
> 
> On the docker side, maybe an official Dockerfile, but no official DockerHub
> entry?
> 
> Max



[Superset] Convenience Releases

2019-08-09 Thread Maxime Beauchemin
Hi all,

How should we go about convenience releases? Currently I'm thinking
Pypi.org, but we could think about Docker / DockerHub as well.

First thing to know is that a convenience release for Superset is likely to
contain minified [aka "compiled"] javascript out of hundreds of libs. In
theory these libs are scanned and approved by FOSSA license-wise, and
generating that report will be part of the release process. Is that ok? I
mean is Apache ok with us distributing that bundle?

Alternatively, it could *not* contain the minified javascript. We'd have to
find some solutions to a few challenges. Maybe run a new `superset
build-js` CLI command that would:
* bootstrap `npm` locally
* download JS build deps
* build locally (minutes)
* find a place to put these files (can't mutate Python's install dir
"site-packages")
* ...

On the docker side, maybe an official Dockerfile, but no official DockerHub
entry?

Max


Re: [VOTE] Release Superset 0.34.0 based on Superset 0.34.0rc1

2019-08-09 Thread Maxime Beauchemin
We can start another thread to talk about "Convenience Releases"
(pypi/docker).

On Fri, Aug 9, 2019 at 2:05 PM Charles Givre  wrote:

> QQ:  At some point, can we update the version on Pypi?  It is
> significantly out of date, and would be nice if we could have a more up to
> date version there.
> Thanks,
> -- C
>
>
> > On Aug 9, 2019, at 2:36 PM, Maxime Beauchemin <
> maximebeauche...@gmail.com> wrote:
> >
> > Dear all,
> >
> > The source release 0.34.0 RC1 for Apache Superset is baked and available
> at:
> > https://dist.apache.org/repos/dist/dev/incubator/superset/, public
> > keys are available
> > at https://dist.apache.org/repos/dist/release/incubator/superset/KEYS
> >
> > We're using the 0.34 branch as the base for this first ASF release as
> > opposed to 0.33 in previous attempts. I think all license-related issues
> > have been ironed out in our dependency, here's the FOSSA report
> > <
> https://app.fossa.com/projects/custom+11342%2f...@github.com:apache%2Fincubator-superset.git/refs/branch/0.34/a04fad858644466219b7ea399aead110cb8ea655
> >
> > . *We're still ironing out our release process, so please bear with us
> and
> > help if you can*.
> >
> > As I went along, I documented the process in [yet-to-be-merged]
> > RELEASING/README.md in the repo, latest edits here #
> > 8016
> > . As part of
> > `RELEASING/`, we ship docker files to help test releases in a
> reproducible
> > way.
> >
> > For context the `0.34` release branch was cut at SHA 9233a63, that was
> > merged on master on Aug 8th 2019. From that common ancestor, the
> following
> > list of commit was added as cherry-picks. The SHAs in the list bellow
> > reference the cherries on the release branch, PR number are available to
> > get more details.
> >
> > 
>
>


Re: [VOTE] Release Superset 0.34.0 based on Superset 0.34.0rc1

2019-08-09 Thread Charles Givre
QQ:  At some point, can we update the version on Pypi?  It is significantly out 
of date, and would be nice if we could have a more up to date version there.
Thanks,
-- C


> On Aug 9, 2019, at 2:36 PM, Maxime Beauchemin  
> wrote:
> 
> Dear all,
> 
> The source release 0.34.0 RC1 for Apache Superset is baked and available at:
> https://dist.apache.org/repos/dist/dev/incubator/superset/, public
> keys are available
> at https://dist.apache.org/repos/dist/release/incubator/superset/KEYS
> 
> We're using the 0.34 branch as the base for this first ASF release as
> opposed to 0.33 in previous attempts. I think all license-related issues
> have been ironed out in our dependency, here's the FOSSA report
> 
> . *We're still ironing out our release process, so please bear with us and
> help if you can*.
> 
> As I went along, I documented the process in [yet-to-be-merged]
> RELEASING/README.md in the repo, latest edits here #
> 8016
> . As part of
> `RELEASING/`, we ship docker files to help test releases in a reproducible
> way.
> 
> For context the `0.34` release branch was cut at SHA 9233a63, that was
> merged on master on Aug 8th 2019. From that common ancestor, the following
> list of commit was added as cherry-picks. The SHAs in the list bellow
> reference the cherries on the release branch, PR number are available to
> get more details.
> 
> 



[VOTE] Release Superset 0.34.0 based on Superset 0.34.0rc1

2019-08-09 Thread Maxime Beauchemin
Dear all,

The source release 0.34.0 RC1 for Apache Superset is baked and available at:
https://dist.apache.org/repos/dist/dev/incubator/superset/, public
keys are available
at https://dist.apache.org/repos/dist/release/incubator/superset/KEYS

We're using the 0.34 branch as the base for this first ASF release as
opposed to 0.33 in previous attempts. I think all license-related issues
have been ironed out in our dependency, here's the FOSSA report

. *We're still ironing out our release process, so please bear with us and
help if you can*.

As I went along, I documented the process in [yet-to-be-merged]
RELEASING/README.md in the repo, latest edits here #
8016
. As part of
`RELEASING/`, we ship docker files to help test releases in a reproducible
way.

For context the `0.34` release branch was cut at SHA 9233a63, that was
merged on master on Aug 8th 2019. From that common ancestor, the following
list of commit was added as cherry-picks. The SHAs in the list bellow
reference the cherries on the release branch, PR number are available to
get more details.




Re: [Superset] Design interest group

2019-08-09 Thread Rasmiranjan Nayak
Hi Max,

Great initiative. I would like to participate and contribute as a ui/ux 
developer.  At Guavus we try to solve complex use cases using superset and our 
experience in design system will help shaping up superset.

Warm Regards,
Rasmiranjan Nayak


On 2019/08/08 18:30:21, Maxime Beauchemin  wrote: 
> Thanks everyone, we're looking to do a 4 hours kick off meeting coming back> 
> from labor day weekend, most likely on the 4th of September (not set in> 
> stone yet). From that point on, we should expect punctual interactions and> 
> weekly 2h long meetings.> 
> 
> I will start a separate thread with the interested folks to coordinate.> 
> 
> We'll keep the community posted as we move forward.> 
> 
> Max> 
> 
> On Thu, Aug 8, 2019 at 9:01 AM Ville Brofeldt > 
> wrote:> 
> 
> > Great initiative Max!> 
> >> 
> > I would be happy to participate in this effort if I can be of assistance.> 
> >> 
> > Ville> 
> >> 
> > On Tue, Aug 6, 2019 at 2:54 AM Maxime Beauchemin <> 
> > maximebeauche...@gmail.com>> 
> > wrote:> 
> >> 
> > > Hi all,> 
> > >> 
> > > As mentioned at the bi-weekly community meeting, the team at Preset is> 
> > > planning to sponsor an engagement with design agency Cartel> 
> > >  to assist the community in defining what the> 
> > > future of Superset may evolve looking like. The folks at Cartel (cced)> 
> > are> 
> > > specialized in designing data-heavy, highly-interactive applications 
> > > like> 
> > > Superset.> 
> > >> 
> > > The effort will take place over September - October - November, and for> 
> > > that engagement we'd like to assemble a small interest group (6-8 
> > > people)> 
> > > that can help shape the direction of this effort, from across the> 
> > > community. We'd like for the major contributors to be represented, and> 
> > for> 
> > > representation to be roughly be based on merit accumulated so far. The> 
> > > folks at Cartel told us they've had much better success working with> 
> > > smaller group so we're trying to respect that.> 
> > >> 
> > > People who want to get involved should:> 
> > > * be able to commit 2H+ a week over those 3 months> 
> > > * have a history of involvement in the project, merit and/or merit> 
> > > representation> 
> > > * a deep understanding of the product> 
> > > * design sense + good UI / UX intuition> 
> > > * understanding Superset use cases and users> 
> > >> 
> > > We'd also like to be able to communicate progress throughout the process> 
> > > and offer a way for the people from the wider community to provide> 
> > > feedback. One or two people in the interest group will be in charge of> 
> > > communicating in and out as we move forward.> 
> > >> 
> > > The interest group will define what areas to focus on and the> 
> > deliverables> 
> > > as we engage with the agency. My personal intuition going into this is> 
> > that> 
> > > we'll prefer to go wide and shallow as opposed to dig super deep into a> 
> > > small set of specific area. Though we'll likely focus on core-ux> 
> > workflows> 
> > > like content creation, and tying up the different pieces of Superset> 
> > > together. We may explore new areas like spreasheet-type interactions,> 
> > > notebooky-type interfaces and things of that nature as well. In any 
> > > case,> 
> > > expect to see lots of wireframes!> 
> > >> 
> > > We do not intend for the designs produced during this engagement to be 
> > > an> 
> > > absolute for the future of Superset, but instead as an inspiration and> 
> > > guiding material to build upon as we work on individual PRs.> 
> > >> 
> > > Anyhow! Please reach out if you're interested or have feedback on the> 
> > > process. We're intending to report progress on the mailing list as we 
> > > go.> 
> > >> 
> > > Thanks,> 
> > >> 
> > > Max> 
> > >> 
> >> 
> 

Problem with flask-jwt-extended

2019-08-09 Thread Brian Newman (C4ML)
We have encountered an issue that started with the updating of the
flask-jwt-extended package to 3.21.0 on August 5th.  This required Flask
>=1.0.0 and superset 0.28.1 requires <=0.12.3. gunicorn requires the
flask-jwt-extended package.

We have tried 2 things that end in the same result.  The /health reports
OK, but the login page is not found, and if I try a dashboard directly I
get Internal Server Error.

The 2 things I have tried are;
Forcing Flask to 0.12.3 and flask-jwt-extended to 3.20.0.
Using the 0.28 requirements.txt from github

Any help is greatly appreciated.


The information contained in this e-mail is confidential and/or proprietary to 
Capital One and/or its affiliates and may only be used solely in performance of 
work or services for Capital One. The information transmitted herewith is 
intended only for use by the individual or entity to which it is addressed. If 
the reader of this message is not the intended recipient, you are hereby 
notified that any review, retransmission, dissemination, distribution, copying 
or other use of, or taking of any action in reliance upon this information is 
strictly prohibited. If you have received this communication in error, please 
contact the sender and delete the material from your computer.