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 <w...@apache.org> wrote: > Shouldn't the community be responsive to this email? > > On 2018/11/14 19:55:53, Alan Gates <alanfga...@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 < > > maximebeauche...@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 <alanfga...@gmail.com> > wrote: > > > > > > > Responses inlined. > > > > > > > > On Fri, Oct 26, 2018 at 8:57 AM Maxime Beauchemin < > > > > maximebeauche...@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
