You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@superset.apache.org by Dave Fisher <wa...@apache.org> on 2018/12/03 06:40:53 UTC
Re: Helping Superset grow into an Apache community
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 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