You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@superset.apache.org by Alan Gates <al...@gmail.com> on 2018/10/25 21:40:15 UTC
Helping Superset grow into an Apache community
All, there are concerns in the Incubator that Superset is not learning the
Apache Way as it should.
It is still doing non-Apache releases. Some have pointed out evidence that
decisions may be being taken off list and corporate allegiance may be
determining peoples choices. If Superset is going to move through the
Incubator and eventually graduate it needs to begin addressing these issues
immediately, as the Incubator PMC is loosing patience. Alternatively,
maybe Apache isn't the best home for Superset, and if so, that's ok.
The purpose of this email is to start a discussion around what the
community needs to do to address these issues.
Alan.
Re: Helping Superset grow into an Apache community
Posted by Justin Mclean <jm...@apache.org>.
Hi,
I notice you are consider using a tool (not rat) to bulk add the headers. Take care that 3rd party headers are not removed and ASF headers are only added to files that require it.
Thanks,
Justin
Re: Helping Superset grow into an Apache community
Posted by Krist Wongsuphasawat <kr...@gmail.com>.
I created issues based on advice from Alan and put them in a project board
for tracking.
https://github.com/apache/incubator-superset/projects/6
On Sun, Dec 2, 2018 at 10:40 PM Dave Fisher <wa...@apache.org> wrote:
> Shouldn't the community be responsive to this email?
>
> On 2018/11/14 19:55:53, Alan Gates <al...@gmail.com> wrote:
> > Picking this thread back up.
> >
> > On the code in the vendors folder, do we know where that came from? If
> it
> > was not contributed to Superset we need to 1) check that it's ok to have
> it
> > at all (ie, we have the author's blessing); 2) figure out what license
> the
> > author released it under; 3) put the license and copyright information in
> > the LICENSE and NOTICE files.
> >
> > Same questions apply for code in the visualizations folder. With just a
> > quick look through there I didn't see any licenses, notices, copyright
> > statements, etc.
> >
> > A few other things I noticed:
> >
> > You need a NOTICE file at the top of the source directory, see
> > https://incubator.apache.org/guides/releasemanagement.html and
> > http://www.apache.org/legal/release-policy.html
> >
> > You need a DISCLAIMER file, see
> > https://incubator.apache.org/guides/branding.html
> >
> > None of the source files appear to have Apache headers on them. I didn't
> > find a header in any of the css, html, py, js, sh, or yaml files. I'm
> not
> > saying these are the only file types that should have them, they're just
> > the ones I checked. Any non-binary file that can take comments should
> have
> > the header. (By header I mean the "Licensed to the Apache Software
> > Foundation..." bit, which you can find in any Apache project's code.
> >
> > Other than the image files, I didn't see any binary or executable files,
> > which is good.
> >
> > There might be other issues, but this will be a good start.
> >
> > Alan.
> >
> > On Fri, Oct 26, 2018 at 12:49 PM Maxime Beauchemin <
> > maximebeauchemin@gmail.com> wrote:
> >
> > > Super. This clarifies things for me. If it's a source only release,
> then we
> > > have MUCH LESS concerns. Some things to check are:
> > > * This vendors folder
> > > <
> > >
> https://github.com/apache/incubator-superset/tree/master/superset/assets/vendor
> > > >,
> > > files in here are copied & modified
> > > * parallel-coordinates:
> > >
> https://github.com/syntagmatic/parallel-coordinates/blob/master/LICENSE
> > > (what license is this?)
> > > * cal-heatmap:
> > > https://github.com/wa0x6e/cal-heatmap/blob/master/LICENCE-MIT (MIT)
> > > * pygment.css:
> https://github.com/nex3/pygments/blob/master/LICENSE
> > > (BSD2 <https://github.com/nex3/pygments/blob/master/LICENSE(BSD2>)
> > > * the visualization folder
> > > <
> > >
> https://github.com/apache/incubator-superset/tree/master/superset/assets/src/visualizations
> > > >
> > > has some copied/modified code as well, mostly coming from bl.ocks.org
> . I
> > > believe there should be headers in all cases as to where it came from.
> We
> > > probably need to dig in here. Good news is that there's ongoing work to
> > > ship all visualizations as plugins, so that we can keep this out of the
> > > source releases.
> > >
> > > Max
> > >
> > > On Fri, Oct 26, 2018 at 11:22 AM Alan Gates <al...@gmail.com>
> wrote:
> > >
> > > > Responses inlined.
> > > >
> > > > On Fri, Oct 26, 2018 at 8:57 AM Maxime Beauchemin <
> > > > maximebeauchemin@gmail.com> wrote:
> > > >
> > > > > One of the main challenge/blocker to date has been around crafting
> our
> > > > > LICENSE.txt file, and keeping it up to date as our JS dependency
> tree
> > > is
> > > > > massive, deep and very dynamic. It seemed like we have to do this
> > > > > programmatically. I started writing a script to do so a little
> while
> > > back
> > > > > and was looking for more mentor guidance as to how to handle the
> > > special
> > > > > cases. There are many libs under "MIT*" or "BSD*" where the "*"
> needs
> > > to
> > > > be
> > > > > investigated and personally I'm not qualified to know whether "MIT
> with
> > > > > LLVM clause" is ok or not... So while I can commit time to this, I
> can
> > > > only
> > > > > raise questions in the process. Also there have been questions
> around
> > > > > convenience releases and whether it's ok to have grey-zone license
> if
> > > > > they're fetched at build time. We need mentor and legal guidance
> here.
> > > > > https://github.com/apache/incubator-superset/pull/5801
> > > >
> > > >
> > > > Sorry if this is repetitive as I'm new here, but step 1 should be
> doing a
> > > > source release. Apache doesn't do binary releases, it does
> convenience
> > > > binaries. If the convenience binary isn't 100% Apache approved yet,
> > > we'll
> > > > solve that in a step 2.
> > > >
> > > > For the source release I'm guessing that all the JS stuff doesn't get
> > > > pulled in, is that right? If so, then we can proceed to the first
> phase
> > > > and get an Apache release out. And we can post those convenience
> > > binaries
> > > > in their current messy state. Then we'll start working on getting
> the
> > > > licensing and packaging right for those.
> > > >
> > > >
> > > > >
> > > > > I also have filled in the "The Apache Project Maturity Checklist"
> last
> > > > > month in the GH issue bellow, and it seems like we're doing fairly
> > > well:
> > > > > https://github.com/apache/incubator-superset/issues/5951
> > > > >
> > > > > I believe that the issues around having discussions off-lists can
> be
> > > > > addressed easily, but we need to clarify what's acceptable or not.
> Is
> > > > Slack
> > > > > ok? Are in-person operational community meetings ok if everyone is
> > > > welcomed
> > > > > to attend, minutes are posted and no important decisions are taken?
> > > > >
> > > >
> > > > The key in Apache is "if it didn't happen on the lists, it didn't
> > > happen".
> > > > Anything that copies to the lists (JIRA, GitHub, etc.) counts.
> Obviously
> > > > people are going to have f2f, slack, etc. discussions. The key is to
> > > > always report the content of those discussions and allow those on the
> > > list
> > > > to be part of the discussion and decision making process. The issue
> with
> > > > any realtime tool like slack is that no matter what time of day you
> pick,
> > > > it's 3am somewhere, which makes it hard to build a geographically
> > > > distributed community.
> > > >
> > > > Let me give an example of how we handle this in the Hive community.
> > > Since
> > > > many Hive developers work for either Cloudera or Hortonworks,
> obviously a
> > > > lot off list discussion happens. But _no_ changes are made without a
> > > > JIRA. And a JIRA patch must be up for 24 hours before anyone can
> commit
> > > > it. This way everyone has a chance to take a look at it before it's
> > > > committed, even if the initial idea for the change is based on some
> > > hallway
> > > > conversation somewhere. Superset will probably prefer git to JIRA,
> but
> > > the
> > > > same principles apply if you let any PR stay open for 24 hours before
> > > > merging it.
> > > >
> > > >
> > > > >
> > > > > Personally I'm committed to align with "the Apache Way" and do a
> > > > > significant portion of the work that we have to do in order to
> > > graduate,
> > > > > but I would love support and help from committers and mentors to
> make
> > > it
> > > > > happen.
> > > > >
> > > >
> > > > Glad to hear you're committed. We mentors are here to help. If we
> have
> > > a
> > > > first pass of what a source release looks like I can take a look and
> give
> > > > some feedback.
> > > >
> > > > Alan.
> > > >
> > >
> >
>
--
*Krist Wongsuphasawat, PhD*
http://kristw.yellowpigz.com
Re: Helping Superset grow into an Apache community
Posted by Dave Fisher <wa...@apache.org>.
Shouldn't the community be responsive to this email?
On 2018/11/14 19:55:53, Alan Gates <al...@gmail.com> wrote:
> Picking this thread back up.
>
> On the code in the vendors folder, do we know where that came from? If it
> was not contributed to Superset we need to 1) check that it's ok to have it
> at all (ie, we have the author's blessing); 2) figure out what license the
> author released it under; 3) put the license and copyright information in
> the LICENSE and NOTICE files.
>
> Same questions apply for code in the visualizations folder. With just a
> quick look through there I didn't see any licenses, notices, copyright
> statements, etc.
>
> A few other things I noticed:
>
> You need a NOTICE file at the top of the source directory, see
> https://incubator.apache.org/guides/releasemanagement.html and
> http://www.apache.org/legal/release-policy.html
>
> You need a DISCLAIMER file, see
> https://incubator.apache.org/guides/branding.html
>
> None of the source files appear to have Apache headers on them. I didn't
> find a header in any of the css, html, py, js, sh, or yaml files. I'm not
> saying these are the only file types that should have them, they're just
> the ones I checked. Any non-binary file that can take comments should have
> the header. (By header I mean the "Licensed to the Apache Software
> Foundation..." bit, which you can find in any Apache project's code.
>
> Other than the image files, I didn't see any binary or executable files,
> which is good.
>
> There might be other issues, but this will be a good start.
>
> Alan.
>
> On Fri, Oct 26, 2018 at 12:49 PM Maxime Beauchemin <
> maximebeauchemin@gmail.com> wrote:
>
> > Super. This clarifies things for me. If it's a source only release, then we
> > have MUCH LESS concerns. Some things to check are:
> > * This vendors folder
> > <
> > https://github.com/apache/incubator-superset/tree/master/superset/assets/vendor
> > >,
> > files in here are copied & modified
> > * parallel-coordinates:
> > https://github.com/syntagmatic/parallel-coordinates/blob/master/LICENSE
> > (what license is this?)
> > * cal-heatmap:
> > https://github.com/wa0x6e/cal-heatmap/blob/master/LICENCE-MIT (MIT)
> > * pygment.css: https://github.com/nex3/pygments/blob/master/LICENSE
> > (BSD2 <https://github.com/nex3/pygments/blob/master/LICENSE(BSD2>)
> > * the visualization folder
> > <
> > https://github.com/apache/incubator-superset/tree/master/superset/assets/src/visualizations
> > >
> > has some copied/modified code as well, mostly coming from bl.ocks.org . I
> > believe there should be headers in all cases as to where it came from. We
> > probably need to dig in here. Good news is that there's ongoing work to
> > ship all visualizations as plugins, so that we can keep this out of the
> > source releases.
> >
> > Max
> >
> > On Fri, Oct 26, 2018 at 11:22 AM Alan Gates <al...@gmail.com> wrote:
> >
> > > Responses inlined.
> > >
> > > On Fri, Oct 26, 2018 at 8:57 AM Maxime Beauchemin <
> > > maximebeauchemin@gmail.com> wrote:
> > >
> > > > One of the main challenge/blocker to date has been around crafting our
> > > > LICENSE.txt file, and keeping it up to date as our JS dependency tree
> > is
> > > > massive, deep and very dynamic. It seemed like we have to do this
> > > > programmatically. I started writing a script to do so a little while
> > back
> > > > and was looking for more mentor guidance as to how to handle the
> > special
> > > > cases. There are many libs under "MIT*" or "BSD*" where the "*" needs
> > to
> > > be
> > > > investigated and personally I'm not qualified to know whether "MIT with
> > > > LLVM clause" is ok or not... So while I can commit time to this, I can
> > > only
> > > > raise questions in the process. Also there have been questions around
> > > > convenience releases and whether it's ok to have grey-zone license if
> > > > they're fetched at build time. We need mentor and legal guidance here.
> > > > https://github.com/apache/incubator-superset/pull/5801
> > >
> > >
> > > Sorry if this is repetitive as I'm new here, but step 1 should be doing a
> > > source release. Apache doesn't do binary releases, it does convenience
> > > binaries. If the convenience binary isn't 100% Apache approved yet,
> > we'll
> > > solve that in a step 2.
> > >
> > > For the source release I'm guessing that all the JS stuff doesn't get
> > > pulled in, is that right? If so, then we can proceed to the first phase
> > > and get an Apache release out. And we can post those convenience
> > binaries
> > > in their current messy state. Then we'll start working on getting the
> > > licensing and packaging right for those.
> > >
> > >
> > > >
> > > > I also have filled in the "The Apache Project Maturity Checklist" last
> > > > month in the GH issue bellow, and it seems like we're doing fairly
> > well:
> > > > https://github.com/apache/incubator-superset/issues/5951
> > > >
> > > > I believe that the issues around having discussions off-lists can be
> > > > addressed easily, but we need to clarify what's acceptable or not. Is
> > > Slack
> > > > ok? Are in-person operational community meetings ok if everyone is
> > > welcomed
> > > > to attend, minutes are posted and no important decisions are taken?
> > > >
> > >
> > > The key in Apache is "if it didn't happen on the lists, it didn't
> > happen".
> > > Anything that copies to the lists (JIRA, GitHub, etc.) counts. Obviously
> > > people are going to have f2f, slack, etc. discussions. The key is to
> > > always report the content of those discussions and allow those on the
> > list
> > > to be part of the discussion and decision making process. The issue with
> > > any realtime tool like slack is that no matter what time of day you pick,
> > > it's 3am somewhere, which makes it hard to build a geographically
> > > distributed community.
> > >
> > > Let me give an example of how we handle this in the Hive community.
> > Since
> > > many Hive developers work for either Cloudera or Hortonworks, obviously a
> > > lot off list discussion happens. But _no_ changes are made without a
> > > JIRA. And a JIRA patch must be up for 24 hours before anyone can commit
> > > it. This way everyone has a chance to take a look at it before it's
> > > committed, even if the initial idea for the change is based on some
> > hallway
> > > conversation somewhere. Superset will probably prefer git to JIRA, but
> > the
> > > same principles apply if you let any PR stay open for 24 hours before
> > > merging it.
> > >
> > >
> > > >
> > > > Personally I'm committed to align with "the Apache Way" and do a
> > > > significant portion of the work that we have to do in order to
> > graduate,
> > > > but I would love support and help from committers and mentors to make
> > it
> > > > happen.
> > > >
> > >
> > > Glad to hear you're committed. We mentors are here to help. If we have
> > a
> > > first pass of what a source release looks like I can take a look and give
> > > some feedback.
> > >
> > > Alan.
> > >
> >
>
Re: Helping Superset grow into an Apache community
Posted by Alan Gates <al...@gmail.com>.
Picking this thread back up.
On the code in the vendors folder, do we know where that came from? If it
was not contributed to Superset we need to 1) check that it's ok to have it
at all (ie, we have the author's blessing); 2) figure out what license the
author released it under; 3) put the license and copyright information in
the LICENSE and NOTICE files.
Same questions apply for code in the visualizations folder. With just a
quick look through there I didn't see any licenses, notices, copyright
statements, etc.
A few other things I noticed:
You need a NOTICE file at the top of the source directory, see
https://incubator.apache.org/guides/releasemanagement.html and
http://www.apache.org/legal/release-policy.html
You need a DISCLAIMER file, see
https://incubator.apache.org/guides/branding.html
None of the source files appear to have Apache headers on them. I didn't
find a header in any of the css, html, py, js, sh, or yaml files. I'm not
saying these are the only file types that should have them, they're just
the ones I checked. Any non-binary file that can take comments should have
the header. (By header I mean the "Licensed to the Apache Software
Foundation..." bit, which you can find in any Apache project's code.
Other than the image files, I didn't see any binary or executable files,
which is good.
There might be other issues, but this will be a good start.
Alan.
On Fri, Oct 26, 2018 at 12:49 PM Maxime Beauchemin <
maximebeauchemin@gmail.com> wrote:
> Super. This clarifies things for me. If it's a source only release, then we
> have MUCH LESS concerns. Some things to check are:
> * This vendors folder
> <
> https://github.com/apache/incubator-superset/tree/master/superset/assets/vendor
> >,
> files in here are copied & modified
> * parallel-coordinates:
> https://github.com/syntagmatic/parallel-coordinates/blob/master/LICENSE
> (what license is this?)
> * cal-heatmap:
> https://github.com/wa0x6e/cal-heatmap/blob/master/LICENCE-MIT (MIT)
> * pygment.css: https://github.com/nex3/pygments/blob/master/LICENSE
> (BSD2 <https://github.com/nex3/pygments/blob/master/LICENSE(BSD2>)
> * the visualization folder
> <
> https://github.com/apache/incubator-superset/tree/master/superset/assets/src/visualizations
> >
> has some copied/modified code as well, mostly coming from bl.ocks.org . I
> believe there should be headers in all cases as to where it came from. We
> probably need to dig in here. Good news is that there's ongoing work to
> ship all visualizations as plugins, so that we can keep this out of the
> source releases.
>
> Max
>
> On Fri, Oct 26, 2018 at 11:22 AM Alan Gates <al...@gmail.com> wrote:
>
> > Responses inlined.
> >
> > On Fri, Oct 26, 2018 at 8:57 AM Maxime Beauchemin <
> > maximebeauchemin@gmail.com> wrote:
> >
> > > One of the main challenge/blocker to date has been around crafting our
> > > LICENSE.txt file, and keeping it up to date as our JS dependency tree
> is
> > > massive, deep and very dynamic. It seemed like we have to do this
> > > programmatically. I started writing a script to do so a little while
> back
> > > and was looking for more mentor guidance as to how to handle the
> special
> > > cases. There are many libs under "MIT*" or "BSD*" where the "*" needs
> to
> > be
> > > investigated and personally I'm not qualified to know whether "MIT with
> > > LLVM clause" is ok or not... So while I can commit time to this, I can
> > only
> > > raise questions in the process. Also there have been questions around
> > > convenience releases and whether it's ok to have grey-zone license if
> > > they're fetched at build time. We need mentor and legal guidance here.
> > > https://github.com/apache/incubator-superset/pull/5801
> >
> >
> > Sorry if this is repetitive as I'm new here, but step 1 should be doing a
> > source release. Apache doesn't do binary releases, it does convenience
> > binaries. If the convenience binary isn't 100% Apache approved yet,
> we'll
> > solve that in a step 2.
> >
> > For the source release I'm guessing that all the JS stuff doesn't get
> > pulled in, is that right? If so, then we can proceed to the first phase
> > and get an Apache release out. And we can post those convenience
> binaries
> > in their current messy state. Then we'll start working on getting the
> > licensing and packaging right for those.
> >
> >
> > >
> > > I also have filled in the "The Apache Project Maturity Checklist" last
> > > month in the GH issue bellow, and it seems like we're doing fairly
> well:
> > > https://github.com/apache/incubator-superset/issues/5951
> > >
> > > I believe that the issues around having discussions off-lists can be
> > > addressed easily, but we need to clarify what's acceptable or not. Is
> > Slack
> > > ok? Are in-person operational community meetings ok if everyone is
> > welcomed
> > > to attend, minutes are posted and no important decisions are taken?
> > >
> >
> > The key in Apache is "if it didn't happen on the lists, it didn't
> happen".
> > Anything that copies to the lists (JIRA, GitHub, etc.) counts. Obviously
> > people are going to have f2f, slack, etc. discussions. The key is to
> > always report the content of those discussions and allow those on the
> list
> > to be part of the discussion and decision making process. The issue with
> > any realtime tool like slack is that no matter what time of day you pick,
> > it's 3am somewhere, which makes it hard to build a geographically
> > distributed community.
> >
> > Let me give an example of how we handle this in the Hive community.
> Since
> > many Hive developers work for either Cloudera or Hortonworks, obviously a
> > lot off list discussion happens. But _no_ changes are made without a
> > JIRA. And a JIRA patch must be up for 24 hours before anyone can commit
> > it. This way everyone has a chance to take a look at it before it's
> > committed, even if the initial idea for the change is based on some
> hallway
> > conversation somewhere. Superset will probably prefer git to JIRA, but
> the
> > same principles apply if you let any PR stay open for 24 hours before
> > merging it.
> >
> >
> > >
> > > Personally I'm committed to align with "the Apache Way" and do a
> > > significant portion of the work that we have to do in order to
> graduate,
> > > but I would love support and help from committers and mentors to make
> it
> > > happen.
> > >
> >
> > Glad to hear you're committed. We mentors are here to help. If we have
> a
> > first pass of what a source release looks like I can take a look and give
> > some feedback.
> >
> > Alan.
> >
>
Re: Helping Superset grow into an Apache community
Posted by Maxime Beauchemin <ma...@gmail.com>.
Super. This clarifies things for me. If it's a source only release, then we
have MUCH LESS concerns. Some things to check are:
* This vendors folder
<https://github.com/apache/incubator-superset/tree/master/superset/assets/vendor>,
files in here are copied & modified
* parallel-coordinates:
https://github.com/syntagmatic/parallel-coordinates/blob/master/LICENSE
(what license is this?)
* cal-heatmap:
https://github.com/wa0x6e/cal-heatmap/blob/master/LICENCE-MIT (MIT)
* pygment.css: https://github.com/nex3/pygments/blob/master/LICENSE
(BSD2)
* the visualization folder
<https://github.com/apache/incubator-superset/tree/master/superset/assets/src/visualizations>
has some copied/modified code as well, mostly coming from bl.ocks.org . I
believe there should be headers in all cases as to where it came from. We
probably need to dig in here. Good news is that there's ongoing work to
ship all visualizations as plugins, so that we can keep this out of the
source releases.
Max
On Fri, Oct 26, 2018 at 11:22 AM Alan Gates <al...@gmail.com> wrote:
> Responses inlined.
>
> On Fri, Oct 26, 2018 at 8:57 AM Maxime Beauchemin <
> maximebeauchemin@gmail.com> wrote:
>
> > One of the main challenge/blocker to date has been around crafting our
> > LICENSE.txt file, and keeping it up to date as our JS dependency tree is
> > massive, deep and very dynamic. It seemed like we have to do this
> > programmatically. I started writing a script to do so a little while back
> > and was looking for more mentor guidance as to how to handle the special
> > cases. There are many libs under "MIT*" or "BSD*" where the "*" needs to
> be
> > investigated and personally I'm not qualified to know whether "MIT with
> > LLVM clause" is ok or not... So while I can commit time to this, I can
> only
> > raise questions in the process. Also there have been questions around
> > convenience releases and whether it's ok to have grey-zone license if
> > they're fetched at build time. We need mentor and legal guidance here.
> > https://github.com/apache/incubator-superset/pull/5801
>
>
> Sorry if this is repetitive as I'm new here, but step 1 should be doing a
> source release. Apache doesn't do binary releases, it does convenience
> binaries. If the convenience binary isn't 100% Apache approved yet, we'll
> solve that in a step 2.
>
> For the source release I'm guessing that all the JS stuff doesn't get
> pulled in, is that right? If so, then we can proceed to the first phase
> and get an Apache release out. And we can post those convenience binaries
> in their current messy state. Then we'll start working on getting the
> licensing and packaging right for those.
>
>
> >
> > I also have filled in the "The Apache Project Maturity Checklist" last
> > month in the GH issue bellow, and it seems like we're doing fairly well:
> > https://github.com/apache/incubator-superset/issues/5951
> >
> > I believe that the issues around having discussions off-lists can be
> > addressed easily, but we need to clarify what's acceptable or not. Is
> Slack
> > ok? Are in-person operational community meetings ok if everyone is
> welcomed
> > to attend, minutes are posted and no important decisions are taken?
> >
>
> The key in Apache is "if it didn't happen on the lists, it didn't happen".
> Anything that copies to the lists (JIRA, GitHub, etc.) counts. Obviously
> people are going to have f2f, slack, etc. discussions. The key is to
> always report the content of those discussions and allow those on the list
> to be part of the discussion and decision making process. The issue with
> any realtime tool like slack is that no matter what time of day you pick,
> it's 3am somewhere, which makes it hard to build a geographically
> distributed community.
>
> Let me give an example of how we handle this in the Hive community. Since
> many Hive developers work for either Cloudera or Hortonworks, obviously a
> lot off list discussion happens. But _no_ changes are made without a
> JIRA. And a JIRA patch must be up for 24 hours before anyone can commit
> it. This way everyone has a chance to take a look at it before it's
> committed, even if the initial idea for the change is based on some hallway
> conversation somewhere. Superset will probably prefer git to JIRA, but the
> same principles apply if you let any PR stay open for 24 hours before
> merging it.
>
>
> >
> > Personally I'm committed to align with "the Apache Way" and do a
> > significant portion of the work that we have to do in order to graduate,
> > but I would love support and help from committers and mentors to make it
> > happen.
> >
>
> Glad to hear you're committed. We mentors are here to help. If we have a
> first pass of what a source release looks like I can take a look and give
> some feedback.
>
> Alan.
>
Re: Helping Superset grow into an Apache community
Posted by Alan Gates <al...@gmail.com>.
Responses inlined.
On Fri, Oct 26, 2018 at 8:57 AM Maxime Beauchemin <
maximebeauchemin@gmail.com> wrote:
> One of the main challenge/blocker to date has been around crafting our
> LICENSE.txt file, and keeping it up to date as our JS dependency tree is
> massive, deep and very dynamic. It seemed like we have to do this
> programmatically. I started writing a script to do so a little while back
> and was looking for more mentor guidance as to how to handle the special
> cases. There are many libs under "MIT*" or "BSD*" where the "*" needs to be
> investigated and personally I'm not qualified to know whether "MIT with
> LLVM clause" is ok or not... So while I can commit time to this, I can only
> raise questions in the process. Also there have been questions around
> convenience releases and whether it's ok to have grey-zone license if
> they're fetched at build time. We need mentor and legal guidance here.
> https://github.com/apache/incubator-superset/pull/5801
Sorry if this is repetitive as I'm new here, but step 1 should be doing a
source release. Apache doesn't do binary releases, it does convenience
binaries. If the convenience binary isn't 100% Apache approved yet, we'll
solve that in a step 2.
For the source release I'm guessing that all the JS stuff doesn't get
pulled in, is that right? If so, then we can proceed to the first phase
and get an Apache release out. And we can post those convenience binaries
in their current messy state. Then we'll start working on getting the
licensing and packaging right for those.
>
> I also have filled in the "The Apache Project Maturity Checklist" last
> month in the GH issue bellow, and it seems like we're doing fairly well:
> https://github.com/apache/incubator-superset/issues/5951
>
> I believe that the issues around having discussions off-lists can be
> addressed easily, but we need to clarify what's acceptable or not. Is Slack
> ok? Are in-person operational community meetings ok if everyone is welcomed
> to attend, minutes are posted and no important decisions are taken?
>
The key in Apache is "if it didn't happen on the lists, it didn't happen".
Anything that copies to the lists (JIRA, GitHub, etc.) counts. Obviously
people are going to have f2f, slack, etc. discussions. The key is to
always report the content of those discussions and allow those on the list
to be part of the discussion and decision making process. The issue with
any realtime tool like slack is that no matter what time of day you pick,
it's 3am somewhere, which makes it hard to build a geographically
distributed community.
Let me give an example of how we handle this in the Hive community. Since
many Hive developers work for either Cloudera or Hortonworks, obviously a
lot off list discussion happens. But _no_ changes are made without a
JIRA. And a JIRA patch must be up for 24 hours before anyone can commit
it. This way everyone has a chance to take a look at it before it's
committed, even if the initial idea for the change is based on some hallway
conversation somewhere. Superset will probably prefer git to JIRA, but the
same principles apply if you let any PR stay open for 24 hours before
merging it.
>
> Personally I'm committed to align with "the Apache Way" and do a
> significant portion of the work that we have to do in order to graduate,
> but I would love support and help from committers and mentors to make it
> happen.
>
Glad to hear you're committed. We mentors are here to help. If we have a
first pass of what a source release looks like I can take a look and give
some feedback.
Alan.
Re: Helping Superset grow into an Apache community
Posted by Maxime Beauchemin <ma...@gmail.com>.
One of the main challenge/blocker to date has been around crafting our
LICENSE.txt file, and keeping it up to date as our JS dependency tree is
massive, deep and very dynamic. It seemed like we have to do this
programmatically. I started writing a script to do so a little while back
and was looking for more mentor guidance as to how to handle the special
cases. There are many libs under "MIT*" or "BSD*" where the "*" needs to be
investigated and personally I'm not qualified to know whether "MIT with
LLVM clause" is ok or not... So while I can commit time to this, I can only
raise questions in the process. Also there have been questions around
convenience releases and whether it's ok to have grey-zone license if
they're fetched at build time. We need mentor and legal guidance here.
https://github.com/apache/incubator-superset/pull/5801
I also have filled in the "The Apache Project Maturity Checklist" last
month in the GH issue bellow, and it seems like we're doing fairly well:
https://github.com/apache/incubator-superset/issues/5951
I believe that the issues around having discussions off-lists can be
addressed easily, but we need to clarify what's acceptable or not. Is Slack
ok? Are in-person operational community meetings ok if everyone is welcomed
to attend, minutes are posted and no important decisions are taken?
Personally I'm committed to align with "the Apache Way" and do a
significant portion of the work that we have to do in order to graduate,
but I would love support and help from committers and mentors to make it
happen.
Max
On Thu, Oct 25, 2018 at 3:43 PM Jason Smith <Ja...@mckinsey.com>
wrote:
> I worked on releasing Apache CouchDB a few years back.
>
>
> I would like to get involved in making a Superset release. I think
> Superset is similar to CouchDB in that it only works correctly when
> bundling large subcomponents, such as the JavaScript runtime and lots of
> JavaScript code.
>
> ________________________________
> From: Alan Gates <al...@gmail.com>
> Sent: Thursday, October 25, 2018 5:40:15 PM
> To: dev@superset.apache.org
> Subject: [EXT]Helping Superset grow into an Apache community
>
> All, there are concerns in the Incubator that Superset is not learning the
> Apache Way as it should.
> It is still doing non-Apache releases. Some have pointed out evidence that
> decisions may be being taken off list and corporate allegiance may be
> determining peoples choices. If Superset is going to move through the
> Incubator and eventually graduate it needs to begin addressing these issues
> immediately, as the Incubator PMC is loosing patience. Alternatively,
> maybe Apache isn't the best home for Superset, and if so, that's ok.
>
> The purpose of this email is to start a discussion around what the
> community needs to do to address these issues.
>
> Alan.
>
> +========================================================================+
> This email is confidential and may be privileged. If you have received it
> in error, please notify us immediately and then delete it. Please do not
> copy it, disclose its contents or use it for any purpose.
> +========================================================================+
>
Re: Helping Superset grow into an Apache community
Posted by Jason Smith <Ja...@mckinsey.com>.
I worked on releasing Apache CouchDB a few years back.
I would like to get involved in making a Superset release. I think Superset is similar to CouchDB in that it only works correctly when bundling large subcomponents, such as the JavaScript runtime and lots of JavaScript code.
________________________________
From: Alan Gates <al...@gmail.com>
Sent: Thursday, October 25, 2018 5:40:15 PM
To: dev@superset.apache.org
Subject: [EXT]Helping Superset grow into an Apache community
All, there are concerns in the Incubator that Superset is not learning the
Apache Way as it should.
It is still doing non-Apache releases. Some have pointed out evidence that
decisions may be being taken off list and corporate allegiance may be
determining peoples choices. If Superset is going to move through the
Incubator and eventually graduate it needs to begin addressing these issues
immediately, as the Incubator PMC is loosing patience. Alternatively,
maybe Apache isn't the best home for Superset, and if so, that's ok.
The purpose of this email is to start a discussion around what the
community needs to do to address these issues.
Alan.
+========================================================================+
This email is confidential and may be privileged. If you have received it
in error, please notify us immediately and then delete it. Please do not
copy it, disclose its contents or use it for any purpose.
+========================================================================+
Re: Helping Superset grow into an Apache community
Posted by Jeff Feng <je...@airbnb.com.INVALID>.
Thanks Sylvia!
Also, here is the video if anyone would like to view it:
https://drive.google.com/file/d/1V1i_fpzo8ZhvEZYR-tbdarUsYK357xSR/view?usp=sharing
On Fri, Dec 14, 2018 at 9:03 AM Sylvia Tomiyama
<sy...@airbnb.com.invalid> wrote:
> Here are the notes
> <
> https://docs.google.com/document/d/1xRLqmUn-G7WiPe8qZnfuvbrYHZ1jmk9aSv9Bhjis2tg/edit#heading=h.98sb4lvagu9j
> >
> from the meeting. Link is available to everyone, but also pasted here for
> convenience:
> 2018-12-13 Apache Superset Agenda & Meeting Notes
>
> Attendees: Jeff Feng, Conglei Shi, Krist W., Vyl C., Timi F., Grace Guo,
> Alan Gates, Chris Council, Sylvia T., Max B., Chris W., John B., Justin M.,
> Beto, Christine Chambers, Junda Yang
>
> Agenda:
>
> -
>
> History of the Superset Project
> -
>
> How does the mechanics of Apache work
> -
>
> Hortonworks Engineering Apache Training
> -
>
> Coaching on how to do things the Apache Way
> -
>
> Options if not Apache
>
>
> Meeting Notes:
>
> -
>
> History of Superset
> -
>
> Max: People at Hortonworks approached Max/Superset to join the Apache
> software foundation and support with the mechanics of joining
> (mentorship,
> committers). This is exciting -- Jeff and a few others at Airbnb had
> been
> working on Superset. Max had done this with Airflow before. These
> people
> didn’t actually come through -- a few people had made some commits,
> and
> some mentorship early on, but fizzled out. I didn’t personally show
> leadership in getting people fired up about getting this graduated
> from
> incubation
> -
>
> How does Apache work / Apache Way (Alan)
> -
>
> No corporate affiliations: Corporations don’t have a standing/voice
> as such in Apache. Each person participates as their own
> -
>
> Companies can’t dictate how to act/vote. (they can, of course, decide
> what they pay for).
> -
>
> Releases are determined by the community, not by companies
> -
>
> You can try to get a release if your company needs it, but need
> community buy-in
> -
>
> Can’t make promises about a release on X date, because this is
> driven by the community
> -
>
> Meritocracy -- people are recognized for “just doing it”
> -
>
> Contributions come from more than just code: e.g. release plans,
> proposals for features, figuring out use cases, qa, answering
> questions, etc
> -
>
> Contributors that show they can help guide the project you can
> vote them to be PMC. In incubation, it’s PPMC - podling. PMC
> has to approve
> them and PPMC votes aren’t binding but it’s like practice
> -
>
> Jeff: what is necessary for being voted into PPMC?
> -
>
> Alan: depends on the PMC, but for me what I look for: they have
> been a committer for a while. Know how to work well with
> others. Can help
> guide/lead others -- shoulder the burden of driving the
> project forward.
> Helping new people, coming up with ideas where we should go
> -
>
> Committers and PMC members who contribute across projects can be
> voted in as Apache members
> -
>
> Collaboration
> -
>
> Mailing lists are the official record -- if it didn’t happen on
> the lists, it didn’t happen.
> -
>
> Enable people around the world -- be inclusive. The way Apache
> deals with this is ensuring everything is on teh mailing list
> -
>
> Jira (and github) if it copies to mailing list as a record, it
> counts. The point is that there is a record, and that I can
> look into it
> from somewhere else and see what happened. Archive
> -
>
> Voting: typically do 72 hours so that there’s enough time/day
> -
>
> Types:
> -
>
> Dev - ideally put everything into here.
> -
>
> Private - ONLY stuff that can’t be public; e.g. security,
> legal, people.
> -
>
> User - for users of a project
> -
>
> Others -- commits, issues, security lists
> -
>
> Decisions are reached by consensus, not by force
> -
>
> E.g. releases and adding new committers or PMC members are
> voted on
> -
>
> Votes are asked for only after consensus is reached
> -
>
> Max: Votes and meritocracy seem in conflict.
> -
>
> Only PMC counts for personnel
> -
>
> For code, committers
> -
>
> PMC is for releases -- because this is a legal thing. But,
> still do this in public
> -
>
> Merit never expires (but people should use this
> -
>
> How to get a sense of consensus before voting?
> -
>
> Do a prevote: e.g. “DISCUSS” and get inputs; Then start an
> official vote
> -
>
> Need to create a space where people can comfortably stand up
> -
>
> Can you vote on a release cycle and then get it approved
> -
>
> Each release has to be approved
> -
>
> But it’s fine to agree on trying to do a release cycle
> -
>
> Note from Justin: Not everyone is paid to work at Apache -- there
> are people who are doing this as a volunteer
> -
>
> Justin: Also committer bar should be clearly documented
> -
>
> May need to reduce the bar for this
> -
>
> What’s the value of Apache?
> -
>
> Known and respected brand in teh open source world
> -
>
> Developing open source software owned by a 3rd party really helps
> build collaboration. It’s very different if a company owns it.
> -
>
> If users are coming to contribute, it’s important that it’s owned
> by a third party
> -
>
> Your users can become your partners and code contributors. It’s
> the only time where I have a customer report a bug and fix it.
> -
>
> Ability to collaborate in the open in a safe “switzerland” space,
> with a friendly license for businesses.
> -
>
> Which hat are you wearing -- for the people who are paid to work on
> it
> -
>
> Are you a committer? PMC member? You have responsibilities to
> Apache.
> -
>
> Just because the company pays you, it doesn’t mean you’re not
> bound by your Apache responsibilities
> -
>
> Justin: Incubator Wiki- Default Project Guidelines:
> https://wiki.apache.org/incubator/DefaultProjectGuidelines
> -
>
> Best Practices
> -
>
> Make sure all off-list discussions are posted to the list, so that
> people can be part of the discussions
> -
>
> Discuss changes fully in PR
> -
>
> Avoid: PR with minimal description, post a patch, and resolve
> within 5 min. Because someone reading it can’t understand it.
> -
>
> Ideally wait at least 24 hours before it can be committed
> unless it’s some really serious issue.
> -
>
> Participate in mailing list in constructive ways
> -
>
> Be professional in your interactions at Apache. Also remember
> that sometimes people end up being rude unintentionally
> -
>
> Make sure all roles are represented in Apache
> -
>
> Make sure to respond to feedback outside of the core community
> -
>
> Vyl: Is Slack or other channels for communication OK?
> -
>
> Alan: My perspective -- email is a specific way of implementing the
> spirit of the law
> -
>
> For slack specifically, I’m worried about the durability of the
> content
> -
>
> If you can download and archive it, that would work.
> -
>
> Justin: there was a way to do it before
> -
>
> Justin: Most/all release conversation should go into the mailing list
> -
>
> Max: but what about real details like which cherries etc
> -
>
> Alan: Some projects have release manager who is centralized
> -
>
> Justin: Most projects I see, they discuss what features to include in
> the mailing list
> -
>
> You can do what you want as long as it follows the guidelines.
> -
>
> Max: Not having support for images is really challenging esp with
> data visualizations.
> -
>
> Github is fine: Open and archived/durable over time
> -
>
> Core tenets: Open and archived/durable over time
> -
>
> Michelle: We use SIP for major changes. If we’re divvying up work,
> then should that be archived?
> -
>
> Alan: The easy way to think about this is, can someone who is not
> physically located with you jump in? Can someone else join?
> -
>
> John: For the SIPs -- we usually have some discussion somewhere that
> the idea comes from, before the SIP, is that OK? Does that
> somehow need to
> be documented?
> -
>
> Alan: If you design something top to bottom and have 10 pages of
> documentation, then it’s really hard for someone to jump in
> -
>
> Need to be not too far so that if feedback comes in, you’re not
> willing to make any changes
> -
>
> I think it’s fine if you have some discussions and put it into the
> SIP
> -
>
> Michelle: If we can’t find a way to archive slack. People go to slack
> to get help from each other -- does that need to be archived?
> -
>
> Justin: users asking questions on slack are fine, esp if it’s
> quick and easy to answer. The downslide is that it’s not
> discoverable so
> it’s repetitive. So usually it’s worth it just to send it to
> the mailing
> list.
> -
>
> Jeff: what about stack overflow?
> -
>
> Justin: yes, that’s fine. It definitely attracts more people and
> creates a bigger community.
> -
>
> Max: Google docs is also a good forum -- is it OK?
> -
>
> Justin: these are all fine, but you are having conversations that
> people can’t join. This is why we don’t want to require
> synchronous/realtime conversations
> -
>
> Max: We need to ask Apache Infra for every piece of infra to add and
> gets denied
> -
>
> Justin: Autoclose issues. This is discussed in a lot of detail on the
> mailing lists and the consensus is that it’s problematic
> -
>
> CI tools are OK
> -
>
> Not being admin on their own gitbox is challenging
> -
>
> Alan: This is a common complaint from many other projects
> -
>
> People who are not committers cannot manage/label issues on github
> that are not their own issue.
> -
>
> Justin: I think it might be an issue with setup. If they are a
> committer they should be able to
> -
>
> Vyl: I have submitted all my paperwork but I still haven’t gotten a
> response over several months.
> -
>
> Justin: PPMC not keeping roster up to date
> -
>
> Alan: This is probably because the mentors aren’t active.
> -
>
> Max: can we have a UI to do this?
> -
>
> Justin: whimsy
> -
>
> Max: Not sure who is on the mailing list
> -
>
> Alan: some of it is the mentors, for sure. Also Apache is slow in
> updating tools, which is why it’s
> -
>
> Alan: please be honest. If Apache isn’t the way, then don’t hide
> meetings.
> -
>
> Justin: the problem is that having the meetings makes it hard for people
> to join
> -
>
> Meetings can’t be the driving force
> -
>
> What would be a good process if we want to have some in-person
> discussions?
> -
>
> Justin: Sending an agenda out and letting people add stuff, and bring
> it back to the mailing list works. Copy and pasting meeting
> notes into the
> mailing list is fine
> -
>
> Release Process
> -
>
> Max: There are hundreds of dependencies in the javascript tree that
> changes all the time
> -
>
> Justin: Why are you so worried about the dependencies?
> -
>
> Max: I’m worried about managing the license file.
> -
>
> Justin: It is only the bundle
> -
>
> Max: Convenience releases. Do we need to build tools
> -
>
> Alan: Are you worried that there is stuff in the convenience releases
> that is not in compliance with Apache
> -
>
> Justin: bsd with advertising clause is one of the few that matter. If
> you want to be Apache software, it must be compatible with the Apache
> software
> -
>
> There are mutated versions of a known license, and I’m not sure how
> to make the call on them.
> -
>
> You can ask on legal-discuss. There are past questions there that
> covers most of the cases.
> -
>
> As long as the clause doesn’t add more restrictions, it’s generally
> permissible
> -
>
> There are 800 javascript libraries -- a micropackage world.
> -
>
> Other projects have had similar challenges, e.g. maven. Maven has
> some pretty good tools to pull in the licenses quickly and will tell
> you.
> -
>
> Justin suggests running fossilogy. It will also help with doing
> deltas between releases.
> -
>
> Github 5801 is where I put this in. I’m worried about having 20
> different conversations about this, especially since this evolves
> -
>
> Alan: I know this is a painpoint. I spent an entire plane ride from
> Toronto. You will get better at it over time. No matter where you
> ship
> this, it’s stuff you have to get right, since you’re liable if
> you screw it
> up. Someone has to bite the bullet. It can be more than just Max.
> -
>
> Someone can own your software if you screw it up and you could get
> sued.
> -
>
> The nice thing about Apache is that people know for sure that it’s
> safe to use.
> -
>
> Justin: Also Apache protects all PMC members legally -- so even if
> you screw it up, unlikely you personally would be sued. Of
> course, this is
> all under the assumption that you’re following the release policy.
> -
>
> Alan: Apache legal resolved will show you what’s been approved or
> not. This will answer 90% of questions. You can use discuss for
> the
> alternative/
> -
>
> You can also ask the owner if you can use it under Apache and
> usually they say yes, or they can change it for other people.
> -
>
> Justin will also share other tools and talks about how to do
> releases. I’ve reviewed 4-500 releases.
> -
>
> Justin: There are projects with more licenses, so it’s definitely
> feasible.
> -
>
> Michelle: Could we get it reviewed so we don’t screw it up
> -
>
> Yes, that’s the point of us (Alan/Justin).
>
> Steps for a release
>
> -
>
> Releases are code only. No binaries
> -
>
> A: I would start with the code release, then do the binaries later since
> the code release is easier and very educational. Then non-conforming
> licenses are out of the picture.
> -
>
> Someone says on the list, I propose to do a release, and let’s use this
> label or cut at Friday
> -
>
> People discuss and come to a conclusion on where to cut the release
> -
>
> Projects do their releases in their own way
> -
>
> Release Guidelines:
> https://incubator.apache.org/guides/releasemanagement.html
> -
>
> Have disclaimers, notice -- there’s documentation
> -
>
> Build release package of source code (not compiled , no outside
> packages)
> -
>
> Sign that with your PGP key and sha512
> -
>
> Put this up on a page and tell people, here it is, go vote on it
> -
>
> Tarball, gzip package
> -
>
> Signature
> -
>
> Sha hash on the package -- to check you build it and it’s what
> you say it is.
> -
>
> Ideally we would have people test it at out this point
> -
>
> Since incubating, need our community to vote on it.
> -
>
> Then send email to incubator pmc to get votes on it, then done
> -
>
> Can ping gates@ for links for what to go in the notice file.
> Alan/Justin: notice should be simple for your case.
> -
>
> Copyrights that have been relocated from source file
> -
>
> Any required third party notices that aren’t already mentioned in the
> license file
> -
>
> If there’s
> -
>
> Date is 2018
> -
>
> Justin also sent links for all this
> -
>
> There is also another repository where we store javascript plugins.
> Should we regard this as an external dependency?
> -
>
> Alan: Who owns that code? It’s up to them where they want to put it
> -
>
> Justin: It might be owned by the company who paid them to do it
> -
>
> Max: we refactored some sections and took them out to enable
> embeddable charts. Some of it is a copy and some of it is
> refactored copy.
> -
>
> Do we call it Superset plugin
> -
>
> There’s no requirement that Superset is one thing only. You don;t
> even need to release them together. Being pluggable.
> -
>
> Justin: It’s not something you need to figure out for your first
> release. But what matters is if it’s an optional? If it’s not
> optional,
> then is it still under Apache? Then it’s not a problem.
> -
>
> The license and notice should cover everything that is in the release
> -
>
> Moving it out is concerning if you’re using it in private
> -
>
> Justin & Alan: This is a place to learn. It’s better to do the first
> release, even if all yoru ducks aren’t in a row, and learn from it.
> That’s
> the point of the incubator. If it’s really out of bounds
> -
>
> Release what you can today and
> -
>
> I don’t think we should move forward in this frankenstein mode.
> -
>
> Max: if we commit, we should fully commit
>
>
> Other options
>
> -
>
> Alan: Other projects have certainly left Apache and gone their separate
> ways. There are other software foundations or you can go it on your own.
> -
>
> Speaking as a person who has been doing this for a while, I think
> being part of something is definitely needed, because otherwise
> you’re
> reinventing the wheel
> -
>
> Max: how do we decide this?
> -
>
> Alan: Whether we shut down is the PMC.
> -
>
> If half want to stay and half want to leave, we probably wouldn’t
> kick out
> -
>
> Jeff: Who is the community here
> -
>
> Alan: Binding votes are PPMC, but I really hope that community can
> come to a consensus we can
> -
>
> Previously retired podlings: There are some that left. Not clear if
> Apache would care about the name since it hasn’t been released. I
> don’t
> think Apache would make it painful
> -
>
> Justin: I don’t think name would be an issue because it hasn’t
> been released and hasn’t been trademarked.
> -
>
> Trademark is only done manually after release with a specific
> request. Organizations can pay for it adn donate it to Apache
> -
>
> Max: If people want to stay in Apache, I want to make sure that more
> people are helping with it.
> -
>
> Jeff: how much work is it?
> -
>
> Alan: the first one is different from all the other ones. I would
> assume it’s a solid week of work. After that, it’s one day.
> -
>
> First time I did a pig release, the
> -
>
> Jeff: it seems like release process would be equal amount of effort re.
> Releases.
> -
>
> Alan: Some things are more lightweight, other things are more
> intense. E.g. blackduck that looks for copyright violations. You
> can bring
> your own governance model.
> -
>
> It’s definitely different. There’s a lot more of you define your own
> process vs.
> -
>
> Jeff: If there’s a will to move forward, can we stay?
> -
>
> Justin & Alan: Yes
> -
>
> Max: But, we need to commit or get out.
> -
>
> Justin: how any of the PMC are on the incubator list?
> -
>
> Do you read the board report -- reading this would help with
> clarifying the ultimatum
> -
>
> Alan: this doesn’t show up in the emails. Everyone has access. It’s
> published on the website. Or stored in SVN
> -
>
> Jeff: I’ve been creating these reports but it’s been going to a black
> hole.
> -
>
> Alan: OK, we need to close the loop on this
> -
>
> Justin: I recommend adding more people to the PMC if you are stretched
> thin.
> -
>
> Apache Incubator Board Minutes:
> https://whimsy.apache.org/board/minutes/
> -
>
> Alan: A +1 means both that you’re behind it and willing to support it.
> -
>
> Jeff: i don’t think it’s from a lack of commitment or lack of
> willingness to play by the rules, but more lack of mentorship.
> -
>
> Max: I felt like this face to face meeting really helped, in a way that
> was hard on mailing list
> -
>
> Alan: I encourage people to go to Apache con -- it helps with this sort
> of thing
> -
>
> Alan/Max: We should discuss this decision on the mailing list
>
> Action Items:
>
> -
>
> Alan to send a release checklist to us
>
>
> On Mon, Dec 10, 2018 at 9:54 PM Jeff Feng <je...@airbnb.com.invalid>
> wrote:
>
> > Hi All,
> >
> > The PPMC and Committers <https://whimsy.apache.org/roster/ppmc/superset>
> > on
> > the Superset project are going to be meeting with one of our mentors
> (Alan
> > Gates) to receive coaching on learning the Apache Way as well as aligning
> > on a set of next steps forward.
> >
> > All are welcome to join and participate in the meeting. It will be on
> > Thursday 12/13 from 2-4 pm PDT. I have included the WebEx information
> > below. We will share a summary of the meeting with Alan following the
> > meeting back to this thread.
> >
> > Best,
> > Jeff
> >
> >
> > JOIN WEBEX MEETING
> >
> >
> https://airbnb.webex.com/airbnb/j.php?MTID=ma4a1fd711d92662580330f1c44859977
> > <
> >
> https://www.google.com/url?q=https%3A%2F%2Fairbnb.webex.com%2Fairbnb%2Fj.php%3FMTID%3Dma4a1fd711d92662580330f1c44859977&sa=D&ust=1544909323375000&usg=AFQjCNGaBqzmCnnq81Pz8XYy1ROSTxow9g
> > >
> > Meeting number: 626 615 201 JOIN FROM A VIDEO SYSTEM OR APPLICATION Dial
> > sip:626615201@airbnb.webex.com You can also dial 173.243.2.68 and enter
> > your meeting number. JOIN BY PHONE 1-650-479-3208 Call-in toll number
> > (US/Canada) Tap here to call (mobile phones only, hosts not supported):
> > tel:%2B1-650-479-3208,,*01*626615201%23%23*01* Global call-in numbers:
> >
> >
> https://airbnb.webex.com/airbnb/globalcallin.php?serviceType=MC&ED=745271162&tollFree=0
> > <
> >
> https://www.google.com/url?q=https%3A%2F%2Fairbnb.webex.com%2Fairbnb%2Fglobalcallin.php%3FserviceType%3DMC%26ED%3D745271162%26tollFree%3D0&sa=D&ust=1544909323375000&usg=AFQjCNFnSd37so63klXA4nIC742NUhKwEg
> > >
> > Can't join the meeting? https://help.webex.com/docs/DOC-5412
> > <
> >
> https://www.google.com/url?q=https%3A%2F%2Fhelp.webex.com%2Fdocs%2FDOC-5412&sa=D&ust=1544909323375000&usg=AFQjCNFkGvqMS8Pu5vSMnaOEDO65yGppAA
> > >
> >
> >
> >
> >
> >
> > On Thu, Oct 25, 2018 at 2:40 PM Alan Gates <al...@gmail.com> wrote:
> >
> > > All, there are concerns in the Incubator that Superset is not learning
> > the
> > > Apache Way as it should.
> > > It is still doing non-Apache releases. Some have pointed out evidence
> > that
> > > decisions may be being taken off list and corporate allegiance may be
> > > determining peoples choices. If Superset is going to move through the
> > > Incubator and eventually graduate it needs to begin addressing these
> > issues
> > > immediately, as the Incubator PMC is loosing patience. Alternatively,
> > > maybe Apache isn't the best home for Superset, and if so, that's ok.
> > >
> > > The purpose of this email is to start a discussion around what the
> > > community needs to do to address these issues.
> > >
> > > Alan.
> > >
> >
>
--
*Jeff Feng*
Product Lead
m: (949)-610-5108
twitter: @jtfeng
Re: Helping Superset grow into an Apache community
Posted by Sylvia Tomiyama <sy...@airbnb.com.INVALID>.
Here are the notes
<https://docs.google.com/document/d/1xRLqmUn-G7WiPe8qZnfuvbrYHZ1jmk9aSv9Bhjis2tg/edit#heading=h.98sb4lvagu9j>
from the meeting. Link is available to everyone, but also pasted here for
convenience:
2018-12-13 Apache Superset Agenda & Meeting Notes
Attendees: Jeff Feng, Conglei Shi, Krist W., Vyl C., Timi F., Grace Guo,
Alan Gates, Chris Council, Sylvia T., Max B., Chris W., John B., Justin M.,
Beto, Christine Chambers, Junda Yang
Agenda:
-
History of the Superset Project
-
How does the mechanics of Apache work
-
Hortonworks Engineering Apache Training
-
Coaching on how to do things the Apache Way
-
Options if not Apache
Meeting Notes:
-
History of Superset
-
Max: People at Hortonworks approached Max/Superset to join the Apache
software foundation and support with the mechanics of joining
(mentorship,
committers). This is exciting -- Jeff and a few others at Airbnb had been
working on Superset. Max had done this with Airflow before. These people
didn’t actually come through -- a few people had made some commits, and
some mentorship early on, but fizzled out. I didn’t personally show
leadership in getting people fired up about getting this graduated from
incubation
-
How does Apache work / Apache Way (Alan)
-
No corporate affiliations: Corporations don’t have a standing/voice
as such in Apache. Each person participates as their own
-
Companies can’t dictate how to act/vote. (they can, of course, decide
what they pay for).
-
Releases are determined by the community, not by companies
-
You can try to get a release if your company needs it, but need
community buy-in
-
Can’t make promises about a release on X date, because this is
driven by the community
-
Meritocracy -- people are recognized for “just doing it”
-
Contributions come from more than just code: e.g. release plans,
proposals for features, figuring out use cases, qa, answering
questions, etc
-
Contributors that show they can help guide the project you can
vote them to be PMC. In incubation, it’s PPMC - podling. PMC
has to approve
them and PPMC votes aren’t binding but it’s like practice
-
Jeff: what is necessary for being voted into PPMC?
-
Alan: depends on the PMC, but for me what I look for: they have
been a committer for a while. Know how to work well with
others. Can help
guide/lead others -- shoulder the burden of driving the
project forward.
Helping new people, coming up with ideas where we should go
-
Committers and PMC members who contribute across projects can be
voted in as Apache members
-
Collaboration
-
Mailing lists are the official record -- if it didn’t happen on
the lists, it didn’t happen.
-
Enable people around the world -- be inclusive. The way Apache
deals with this is ensuring everything is on teh mailing list
-
Jira (and github) if it copies to mailing list as a record, it
counts. The point is that there is a record, and that I can
look into it
from somewhere else and see what happened. Archive
-
Voting: typically do 72 hours so that there’s enough time/day
-
Types:
-
Dev - ideally put everything into here.
-
Private - ONLY stuff that can’t be public; e.g. security,
legal, people.
-
User - for users of a project
-
Others -- commits, issues, security lists
-
Decisions are reached by consensus, not by force
-
E.g. releases and adding new committers or PMC members are
voted on
-
Votes are asked for only after consensus is reached
-
Max: Votes and meritocracy seem in conflict.
-
Only PMC counts for personnel
-
For code, committers
-
PMC is for releases -- because this is a legal thing. But,
still do this in public
-
Merit never expires (but people should use this
-
How to get a sense of consensus before voting?
-
Do a prevote: e.g. “DISCUSS” and get inputs; Then start an
official vote
-
Need to create a space where people can comfortably stand up
-
Can you vote on a release cycle and then get it approved
-
Each release has to be approved
-
But it’s fine to agree on trying to do a release cycle
-
Note from Justin: Not everyone is paid to work at Apache -- there
are people who are doing this as a volunteer
-
Justin: Also committer bar should be clearly documented
-
May need to reduce the bar for this
-
What’s the value of Apache?
-
Known and respected brand in teh open source world
-
Developing open source software owned by a 3rd party really helps
build collaboration. It’s very different if a company owns it.
-
If users are coming to contribute, it’s important that it’s owned
by a third party
-
Your users can become your partners and code contributors. It’s
the only time where I have a customer report a bug and fix it.
-
Ability to collaborate in the open in a safe “switzerland” space,
with a friendly license for businesses.
-
Which hat are you wearing -- for the people who are paid to work on it
-
Are you a committer? PMC member? You have responsibilities to
Apache.
-
Just because the company pays you, it doesn’t mean you’re not
bound by your Apache responsibilities
-
Justin: Incubator Wiki- Default Project Guidelines:
https://wiki.apache.org/incubator/DefaultProjectGuidelines
-
Best Practices
-
Make sure all off-list discussions are posted to the list, so that
people can be part of the discussions
-
Discuss changes fully in PR
-
Avoid: PR with minimal description, post a patch, and resolve
within 5 min. Because someone reading it can’t understand it.
-
Ideally wait at least 24 hours before it can be committed
unless it’s some really serious issue.
-
Participate in mailing list in constructive ways
-
Be professional in your interactions at Apache. Also remember
that sometimes people end up being rude unintentionally
-
Make sure all roles are represented in Apache
-
Make sure to respond to feedback outside of the core community
-
Vyl: Is Slack or other channels for communication OK?
-
Alan: My perspective -- email is a specific way of implementing the
spirit of the law
-
For slack specifically, I’m worried about the durability of the
content
-
If you can download and archive it, that would work.
-
Justin: there was a way to do it before
-
Justin: Most/all release conversation should go into the mailing list
-
Max: but what about real details like which cherries etc
-
Alan: Some projects have release manager who is centralized
-
Justin: Most projects I see, they discuss what features to include in
the mailing list
-
You can do what you want as long as it follows the guidelines.
-
Max: Not having support for images is really challenging esp with
data visualizations.
-
Github is fine: Open and archived/durable over time
-
Core tenets: Open and archived/durable over time
-
Michelle: We use SIP for major changes. If we’re divvying up work,
then should that be archived?
-
Alan: The easy way to think about this is, can someone who is not
physically located with you jump in? Can someone else join?
-
John: For the SIPs -- we usually have some discussion somewhere that
the idea comes from, before the SIP, is that OK? Does that
somehow need to
be documented?
-
Alan: If you design something top to bottom and have 10 pages of
documentation, then it’s really hard for someone to jump in
-
Need to be not too far so that if feedback comes in, you’re not
willing to make any changes
-
I think it’s fine if you have some discussions and put it into the
SIP
-
Michelle: If we can’t find a way to archive slack. People go to slack
to get help from each other -- does that need to be archived?
-
Justin: users asking questions on slack are fine, esp if it’s
quick and easy to answer. The downslide is that it’s not
discoverable so
it’s repetitive. So usually it’s worth it just to send it to
the mailing
list.
-
Jeff: what about stack overflow?
-
Justin: yes, that’s fine. It definitely attracts more people and
creates a bigger community.
-
Max: Google docs is also a good forum -- is it OK?
-
Justin: these are all fine, but you are having conversations that
people can’t join. This is why we don’t want to require
synchronous/realtime conversations
-
Max: We need to ask Apache Infra for every piece of infra to add and
gets denied
-
Justin: Autoclose issues. This is discussed in a lot of detail on the
mailing lists and the consensus is that it’s problematic
-
CI tools are OK
-
Not being admin on their own gitbox is challenging
-
Alan: This is a common complaint from many other projects
-
People who are not committers cannot manage/label issues on github
that are not their own issue.
-
Justin: I think it might be an issue with setup. If they are a
committer they should be able to
-
Vyl: I have submitted all my paperwork but I still haven’t gotten a
response over several months.
-
Justin: PPMC not keeping roster up to date
-
Alan: This is probably because the mentors aren’t active.
-
Max: can we have a UI to do this?
-
Justin: whimsy
-
Max: Not sure who is on the mailing list
-
Alan: some of it is the mentors, for sure. Also Apache is slow in
updating tools, which is why it’s
-
Alan: please be honest. If Apache isn’t the way, then don’t hide
meetings.
-
Justin: the problem is that having the meetings makes it hard for people
to join
-
Meetings can’t be the driving force
-
What would be a good process if we want to have some in-person
discussions?
-
Justin: Sending an agenda out and letting people add stuff, and bring
it back to the mailing list works. Copy and pasting meeting
notes into the
mailing list is fine
-
Release Process
-
Max: There are hundreds of dependencies in the javascript tree that
changes all the time
-
Justin: Why are you so worried about the dependencies?
-
Max: I’m worried about managing the license file.
-
Justin: It is only the bundle
-
Max: Convenience releases. Do we need to build tools
-
Alan: Are you worried that there is stuff in the convenience releases
that is not in compliance with Apache
-
Justin: bsd with advertising clause is one of the few that matter. If
you want to be Apache software, it must be compatible with the Apache
software
-
There are mutated versions of a known license, and I’m not sure how
to make the call on them.
-
You can ask on legal-discuss. There are past questions there that
covers most of the cases.
-
As long as the clause doesn’t add more restrictions, it’s generally
permissible
-
There are 800 javascript libraries -- a micropackage world.
-
Other projects have had similar challenges, e.g. maven. Maven has
some pretty good tools to pull in the licenses quickly and will tell you.
-
Justin suggests running fossilogy. It will also help with doing
deltas between releases.
-
Github 5801 is where I put this in. I’m worried about having 20
different conversations about this, especially since this evolves
-
Alan: I know this is a painpoint. I spent an entire plane ride from
Toronto. You will get better at it over time. No matter where you ship
this, it’s stuff you have to get right, since you’re liable if
you screw it
up. Someone has to bite the bullet. It can be more than just Max.
-
Someone can own your software if you screw it up and you could get
sued.
-
The nice thing about Apache is that people know for sure that it’s
safe to use.
-
Justin: Also Apache protects all PMC members legally -- so even if
you screw it up, unlikely you personally would be sued. Of
course, this is
all under the assumption that you’re following the release policy.
-
Alan: Apache legal resolved will show you what’s been approved or
not. This will answer 90% of questions. You can use discuss for the
alternative/
-
You can also ask the owner if you can use it under Apache and
usually they say yes, or they can change it for other people.
-
Justin will also share other tools and talks about how to do
releases. I’ve reviewed 4-500 releases.
-
Justin: There are projects with more licenses, so it’s definitely
feasible.
-
Michelle: Could we get it reviewed so we don’t screw it up
-
Yes, that’s the point of us (Alan/Justin).
Steps for a release
-
Releases are code only. No binaries
-
A: I would start with the code release, then do the binaries later since
the code release is easier and very educational. Then non-conforming
licenses are out of the picture.
-
Someone says on the list, I propose to do a release, and let’s use this
label or cut at Friday
-
People discuss and come to a conclusion on where to cut the release
-
Projects do their releases in their own way
-
Release Guidelines:
https://incubator.apache.org/guides/releasemanagement.html
-
Have disclaimers, notice -- there’s documentation
-
Build release package of source code (not compiled , no outside
packages)
-
Sign that with your PGP key and sha512
-
Put this up on a page and tell people, here it is, go vote on it
-
Tarball, gzip package
-
Signature
-
Sha hash on the package -- to check you build it and it’s what
you say it is.
-
Ideally we would have people test it at out this point
-
Since incubating, need our community to vote on it.
-
Then send email to incubator pmc to get votes on it, then done
-
Can ping gates@ for links for what to go in the notice file.
Alan/Justin: notice should be simple for your case.
-
Copyrights that have been relocated from source file
-
Any required third party notices that aren’t already mentioned in the
license file
-
If there’s
-
Date is 2018
-
Justin also sent links for all this
-
There is also another repository where we store javascript plugins.
Should we regard this as an external dependency?
-
Alan: Who owns that code? It’s up to them where they want to put it
-
Justin: It might be owned by the company who paid them to do it
-
Max: we refactored some sections and took them out to enable
embeddable charts. Some of it is a copy and some of it is
refactored copy.
-
Do we call it Superset plugin
-
There’s no requirement that Superset is one thing only. You don;t
even need to release them together. Being pluggable.
-
Justin: It’s not something you need to figure out for your first
release. But what matters is if it’s an optional? If it’s not optional,
then is it still under Apache? Then it’s not a problem.
-
The license and notice should cover everything that is in the release
-
Moving it out is concerning if you’re using it in private
-
Justin & Alan: This is a place to learn. It’s better to do the first
release, even if all yoru ducks aren’t in a row, and learn from it. That’s
the point of the incubator. If it’s really out of bounds
-
Release what you can today and
-
I don’t think we should move forward in this frankenstein mode.
-
Max: if we commit, we should fully commit
Other options
-
Alan: Other projects have certainly left Apache and gone their separate
ways. There are other software foundations or you can go it on your own.
-
Speaking as a person who has been doing this for a while, I think
being part of something is definitely needed, because otherwise you’re
reinventing the wheel
-
Max: how do we decide this?
-
Alan: Whether we shut down is the PMC.
-
If half want to stay and half want to leave, we probably wouldn’t
kick out
-
Jeff: Who is the community here
-
Alan: Binding votes are PPMC, but I really hope that community can
come to a consensus we can
-
Previously retired podlings: There are some that left. Not clear if
Apache would care about the name since it hasn’t been released. I don’t
think Apache would make it painful
-
Justin: I don’t think name would be an issue because it hasn’t
been released and hasn’t been trademarked.
-
Trademark is only done manually after release with a specific
request. Organizations can pay for it adn donate it to Apache
-
Max: If people want to stay in Apache, I want to make sure that more
people are helping with it.
-
Jeff: how much work is it?
-
Alan: the first one is different from all the other ones. I would
assume it’s a solid week of work. After that, it’s one day.
-
First time I did a pig release, the
-
Jeff: it seems like release process would be equal amount of effort re.
Releases.
-
Alan: Some things are more lightweight, other things are more
intense. E.g. blackduck that looks for copyright violations. You
can bring
your own governance model.
-
It’s definitely different. There’s a lot more of you define your own
process vs.
-
Jeff: If there’s a will to move forward, can we stay?
-
Justin & Alan: Yes
-
Max: But, we need to commit or get out.
-
Justin: how any of the PMC are on the incubator list?
-
Do you read the board report -- reading this would help with
clarifying the ultimatum
-
Alan: this doesn’t show up in the emails. Everyone has access. It’s
published on the website. Or stored in SVN
-
Jeff: I’ve been creating these reports but it’s been going to a black
hole.
-
Alan: OK, we need to close the loop on this
-
Justin: I recommend adding more people to the PMC if you are stretched
thin.
-
Apache Incubator Board Minutes: https://whimsy.apache.org/board/minutes/
-
Alan: A +1 means both that you’re behind it and willing to support it.
-
Jeff: i don’t think it’s from a lack of commitment or lack of
willingness to play by the rules, but more lack of mentorship.
-
Max: I felt like this face to face meeting really helped, in a way that
was hard on mailing list
-
Alan: I encourage people to go to Apache con -- it helps with this sort
of thing
-
Alan/Max: We should discuss this decision on the mailing list
Action Items:
-
Alan to send a release checklist to us
On Mon, Dec 10, 2018 at 9:54 PM Jeff Feng <je...@airbnb.com.invalid>
wrote:
> Hi All,
>
> The PPMC and Committers <https://whimsy.apache.org/roster/ppmc/superset>
> on
> the Superset project are going to be meeting with one of our mentors (Alan
> Gates) to receive coaching on learning the Apache Way as well as aligning
> on a set of next steps forward.
>
> All are welcome to join and participate in the meeting. It will be on
> Thursday 12/13 from 2-4 pm PDT. I have included the WebEx information
> below. We will share a summary of the meeting with Alan following the
> meeting back to this thread.
>
> Best,
> Jeff
>
>
> JOIN WEBEX MEETING
>
> https://airbnb.webex.com/airbnb/j.php?MTID=ma4a1fd711d92662580330f1c44859977
> <
> https://www.google.com/url?q=https%3A%2F%2Fairbnb.webex.com%2Fairbnb%2Fj.php%3FMTID%3Dma4a1fd711d92662580330f1c44859977&sa=D&ust=1544909323375000&usg=AFQjCNGaBqzmCnnq81Pz8XYy1ROSTxow9g
> >
> Meeting number: 626 615 201 JOIN FROM A VIDEO SYSTEM OR APPLICATION Dial
> sip:626615201@airbnb.webex.com You can also dial 173.243.2.68 and enter
> your meeting number. JOIN BY PHONE 1-650-479-3208 Call-in toll number
> (US/Canada) Tap here to call (mobile phones only, hosts not supported):
> tel:%2B1-650-479-3208,,*01*626615201%23%23*01* Global call-in numbers:
>
> https://airbnb.webex.com/airbnb/globalcallin.php?serviceType=MC&ED=745271162&tollFree=0
> <
> https://www.google.com/url?q=https%3A%2F%2Fairbnb.webex.com%2Fairbnb%2Fglobalcallin.php%3FserviceType%3DMC%26ED%3D745271162%26tollFree%3D0&sa=D&ust=1544909323375000&usg=AFQjCNFnSd37so63klXA4nIC742NUhKwEg
> >
> Can't join the meeting? https://help.webex.com/docs/DOC-5412
> <
> https://www.google.com/url?q=https%3A%2F%2Fhelp.webex.com%2Fdocs%2FDOC-5412&sa=D&ust=1544909323375000&usg=AFQjCNFkGvqMS8Pu5vSMnaOEDO65yGppAA
> >
>
>
>
>
>
> On Thu, Oct 25, 2018 at 2:40 PM Alan Gates <al...@gmail.com> wrote:
>
> > All, there are concerns in the Incubator that Superset is not learning
> the
> > Apache Way as it should.
> > It is still doing non-Apache releases. Some have pointed out evidence
> that
> > decisions may be being taken off list and corporate allegiance may be
> > determining peoples choices. If Superset is going to move through the
> > Incubator and eventually graduate it needs to begin addressing these
> issues
> > immediately, as the Incubator PMC is loosing patience. Alternatively,
> > maybe Apache isn't the best home for Superset, and if so, that's ok.
> >
> > The purpose of this email is to start a discussion around what the
> > community needs to do to address these issues.
> >
> > Alan.
> >
>
Re: Helping Superset grow into an Apache community
Posted by Jeff Feng <je...@airbnb.com.INVALID>.
Hi All,
The PPMC and Committers <https://whimsy.apache.org/roster/ppmc/superset> on
the Superset project are going to be meeting with one of our mentors (Alan
Gates) to receive coaching on learning the Apache Way as well as aligning
on a set of next steps forward.
All are welcome to join and participate in the meeting. It will be on
Thursday 12/13 from 2-4 pm PDT. I have included the WebEx information
below. We will share a summary of the meeting with Alan following the
meeting back to this thread.
Best,
Jeff
JOIN WEBEX MEETING
https://airbnb.webex.com/airbnb/j.php?MTID=ma4a1fd711d92662580330f1c44859977
<https://www.google.com/url?q=https%3A%2F%2Fairbnb.webex.com%2Fairbnb%2Fj.php%3FMTID%3Dma4a1fd711d92662580330f1c44859977&sa=D&ust=1544909323375000&usg=AFQjCNGaBqzmCnnq81Pz8XYy1ROSTxow9g>
Meeting number: 626 615 201 JOIN FROM A VIDEO SYSTEM OR APPLICATION Dial
sip:626615201@airbnb.webex.com You can also dial 173.243.2.68 and enter
your meeting number. JOIN BY PHONE 1-650-479-3208 Call-in toll number
(US/Canada) Tap here to call (mobile phones only, hosts not supported):
tel:%2B1-650-479-3208,,*01*626615201%23%23*01* Global call-in numbers:
https://airbnb.webex.com/airbnb/globalcallin.php?serviceType=MC&ED=745271162&tollFree=0
<https://www.google.com/url?q=https%3A%2F%2Fairbnb.webex.com%2Fairbnb%2Fglobalcallin.php%3FserviceType%3DMC%26ED%3D745271162%26tollFree%3D0&sa=D&ust=1544909323375000&usg=AFQjCNFnSd37so63klXA4nIC742NUhKwEg>
Can't join the meeting? https://help.webex.com/docs/DOC-5412
<https://www.google.com/url?q=https%3A%2F%2Fhelp.webex.com%2Fdocs%2FDOC-5412&sa=D&ust=1544909323375000&usg=AFQjCNFkGvqMS8Pu5vSMnaOEDO65yGppAA>
On Thu, Oct 25, 2018 at 2:40 PM Alan Gates <al...@gmail.com> wrote:
> All, there are concerns in the Incubator that Superset is not learning the
> Apache Way as it should.
> It is still doing non-Apache releases. Some have pointed out evidence that
> decisions may be being taken off list and corporate allegiance may be
> determining peoples choices. If Superset is going to move through the
> Incubator and eventually graduate it needs to begin addressing these issues
> immediately, as the Incubator PMC is loosing patience. Alternatively,
> maybe Apache isn't the best home for Superset, and if so, that's ok.
>
> The purpose of this email is to start a discussion around what the
> community needs to do to address these issues.
>
> Alan.
>