Re: Apache Superset Design Sync (vote on next meet up)

[Jolly Paramjit]

Eli,
  Thanks for your reply, I think we should attend the video conference whatever 
odd hours it may be.  We will join the call.
As I want first discussion with full information & some basic demo to showcase.

We will be presenting:
1. Our high level planning for superset overall feature enhancements. (in-case 
everyone is interested)
2. Design system - We are working in Guavus
3. How we are thinking to use same in superset but we need some guidance from 
stake holders.

Looking forward for the upcoming meeting.

-- 
Thanks & Regards
Jolly
Handphone: +91-9971815749
 
[We Learn, Unlearn & Re-learn.]
 

On 08/01/19, 5:17 AM, "Eli Brumbaugh"  wrote:

Hi Jolly, Rasmiranjan (and the community!)

Thank you again for letting the community know about your time zone
difference (13.5 hours ahead of those of us in the Bay Area) and how the
time originally set for the design sync is difficult for you to attend.

*Geographically distributed collaboration proposal:*
Please let us know what you think about this solution.

   - In place of a video conference we collaborate via this email alias,
   shared (publicly accessible docs) and Sketch files.
   - The ASF how-it-works
    suggest the
   following:
  - *"Communication is done via mailing lists. These identify "virtual
  meeting rooms" where conversations happen asynchronously, which is a
  general requirement for groups that are so geographically distributed 
to
  cover all time zones (like it's normally the case for the various 
Apache
  communities).*
   - With our global distribution working asynchronously via the dev@ email
   and google docs seems like the best way to move forward while maximizing
   the transparency of our discussions.

*Sharing your proposal: *
Jolly and Rasmiranjan, would you be willing to share your Superset Design
System and custom UI framework proposal via the dev@ email alias along with
any related publically accessible docs for discussion and if you desire a
vote?

*Upcoming design sync:*

   1. The Thursday, January 31st video chat will still occur for all who
   can attend.
  - *All discussion*, notes, open questions, to do's, etc will be
documented
  in this publicly
  

  accessible google doc.
  - *All decisions* will still be put to a vote in the dev@ email alias.
   2. This doc
   

   will be sent out to the dev@ email alias as a reminder for additional
   comments/discussion.
  - Please be sure to comment and leave feedback!
   3. This doc
   

   will serve as a record of meeting notes that can be accessed easily by 
all.

*If anyone has any thoughts or concerns please let the thread know!*

Best,
Eli



On Fri, Jan 4, 2019 at 11:35 AM Jolly Paramjit 
wrote:

> Hi Eli,
>
> We can use hangouts not an issue, officially we use zoom.
>
> --
> Thanks & Regards
> Jolly
> Handphone: +91-9971815749
>
> [We Learn, Unlearn & Re-learn.]
>
>
> On 05/01/19, 12:34 AM, "Eli Brumbaugh" 
> wrote:
>
> Hi Jolly,
>
> Thank you for letting me know about your location and custom design
> system
> / UI framework. I will work on finding a time that works for everyone.
>
> Quick question: Can you use Google Hangouts?
>
> Best,
> Eli
>
> On Wed, Jan 2, 2019 at 5:15 PM Jolly Paramjit <
> jolly.param...@guavus.com>
> wrote:
>
> > Thanks Eli for setting up this meeting.
> >
> > We are based in india hence plz make sure timings are not very odd.
> > Currently it seems 4 am which is very early.
> > We are ok anytime between 9 am - 11 pm IST. Hopefully you can move
> to any
> > of such time window.
> > Also regarding design system we have explored separately custom
> design
> > system &  trying using in our custom UI framework. Also we wanted
> similar
> > to used by superset if everyone agree to it.
> >
> > Looking forward for this meeting.
> >
> > ~Jolly
> > [Sent from iPhone 7. Pls excuse typos]
> >
> >
> >
> > On 03-Jan-2019, at 1:44 AM, Eli Brumbaugh  > .INVALID> wrote:
> >
> > Hello world,
> >
> > As mentioned several weeks ago in my design operating system

Re: Apache Superset Design Sync (vote on next meet up)

[Eli Brumbaugh]

Hi Jolly, Rasmiranjan (and the community!)

Thank you again for letting the community know about your time zone
difference (13.5 hours ahead of those of us in the Bay Area) and how the
time originally set for the design sync is difficult for you to attend.

*Geographically distributed collaboration proposal:*
Please let us know what you think about this solution.

   - In place of a video conference we collaborate via this email alias,
   shared (publicly accessible docs) and Sketch files.
   - The ASF how-it-works
    suggest the
   following:
  - *"Communication is done via mailing lists. These identify "virtual
  meeting rooms" where conversations happen asynchronously, which is a
  general requirement for groups that are so geographically distributed to
  cover all time zones (like it's normally the case for the various Apache
  communities).*
   - With our global distribution working asynchronously via the dev@ email
   and google docs seems like the best way to move forward while maximizing
   the transparency of our discussions.

*Sharing your proposal: *
Jolly and Rasmiranjan, would you be willing to share your Superset Design
System and custom UI framework proposal via the dev@ email alias along with
any related publically accessible docs for discussion and if you desire a
vote?

*Upcoming design sync:*

   1. The Thursday, January 31st video chat will still occur for all who
   can attend.
  - *All discussion*, notes, open questions, to do's, etc will be
documented
  in this publicly
  

  accessible google doc.
  - *All decisions* will still be put to a vote in the dev@ email alias.
   2. This doc
   

   will be sent out to the dev@ email alias as a reminder for additional
   comments/discussion.
  - Please be sure to comment and leave feedback!
   3. This doc
   

   will serve as a record of meeting notes that can be accessed easily by all.

*If anyone has any thoughts or concerns please let the thread know!*

Best,
Eli



On Fri, Jan 4, 2019 at 11:35 AM Jolly Paramjit 
wrote:

> Hi Eli,
>
> We can use hangouts not an issue, officially we use zoom.
>
> --
> Thanks & Regards
> Jolly
> Handphone: +91-9971815749
>
> [We Learn, Unlearn & Re-learn.]
>
>
> On 05/01/19, 12:34 AM, "Eli Brumbaugh" 
> wrote:
>
> Hi Jolly,
>
> Thank you for letting me know about your location and custom design
> system
> / UI framework. I will work on finding a time that works for everyone.
>
> Quick question: Can you use Google Hangouts?
>
> Best,
> Eli
>
> On Wed, Jan 2, 2019 at 5:15 PM Jolly Paramjit <
> jolly.param...@guavus.com>
> wrote:
>
> > Thanks Eli for setting up this meeting.
> >
> > We are based in india hence plz make sure timings are not very odd.
> > Currently it seems 4 am which is very early.
> > We are ok anytime between 9 am - 11 pm IST. Hopefully you can move
> to any
> > of such time window.
> > Also regarding design system we have explored separately custom
> design
> > system &  trying using in our custom UI framework. Also we wanted
> similar
> > to used by superset if everyone agree to it.
> >
> > Looking forward for this meeting.
> >
> > ~Jolly
> > [Sent from iPhone 7. Pls excuse typos]
> >
> >
> >
> > On 03-Jan-2019, at 1:44 AM, Eli Brumbaugh  > .INVALID> wrote:
> >
> > Hello world,
> >
> > As mentioned several weeks ago in my design operating system
> proposal I
> > would like to propose a meeting date for the next Apache Superset
> design
> > sync.
> >
> > After some lightweight discussion
> > <
> https://apache-superset.slack.com/archives/CCKHMGRRB/p1545423476013000>
> > in
> > the (publically accessible) Apache Superset Slack #design channel
> this is
> > what we would like to purpose:
> >
> > *Date*: Thursday, January 31st
> > *Time*: 3 PM - 4 PM (PST)
> > *How*: Google Hangouts (publically accessible/free conference
> software)
> >
> > Potential itinerary:
> >
> >   - Introductions.
> >   - Review each individual's design related efforts/plans (avoid
> >   overlap/ensure review).
> >   - *Matt* and *Anita* - Update on the status of the publically
> accessible
> >   Superset UI Sketch file. (Confirmed) They are kindly doing the
> legwork to
> >   rebuild what's in code.
> >   - *Rasmiranjan* and *Jolly* - Sharing their work on a Superset
> Design
> >   System. I've asked them to present this effort to the group. (TBD)
> >   - Review operating 

Re: [VOTE] release Superset 0.29.0rc7 as 0.29.0 to Pypi

[Maxime Beauchemin]

Hi Bolke,

Thanks for the thoughtful notes here. I like the idea of sticking to
release candidate or "devN" packages on pypi for this, personally I think
that's acceptable.

About headers, I have a PR out here
https://github.com/apache/incubator-superset/pull/5800. I ended up writing
a small utility that does kind of what RAT does (called "rodent" :) as I
couldn't get RAT to work properly

About LICENSE.txt, and legal/licenses aspects, we're super committed to
doing it, we just haven't come up with a solid plan + timeline yet. I think
realistically it can be done this quarter. I did some work here
https://github.com/apache/incubator-superset/pull/5801. From my
understanding some of the concerns I'm trying to address in this PR are not
a real concern for a source release where the user would fetch and build
the JS out of NPM. I'm not sure whether they are a concern for a
convenience release but I think they are, unless we find a way to *not*
bundle the JS "binaries" in the convenience release. The idea I had was to
commit a whitelist of packages that have non-standard license on NPM
(things like "apache2*" or "MIT*", or "MIT with LLVN clause") in the repo
and to have some automated checks to raise issues when new, non-whitelisted
libs with non-standard licenses would show up on the dependency tree.

Max

On Mon, Jan 7, 2019 at 12:07 AM Bolke de Bruin  wrote:

> Hi All,
>
> (Part of the thread seems missing, but I assume everyone has the same
> history).
>
> Just hopping over from Apache Airflow. We have been going through the same
> process and some of you even have been involved :-). We have also struggled
> along the way, but we found our path and have just graduated from the
> incubator last month. We are also a Python based project.
>
> I personally reach out as I made the company I work for dependent on
> Superset, but we cannot continue to use it if it doesn’t eventually does a
> legal compliant release. During incubation the ASF puts you through the
> mill in order to get to such a release, but others like CNCF will require
> the same.
>
> So here to share some experiences, some suggestions, and offer some help.
>
> On the ‘VOTE’
>
> Releases in Apache’s world are a very loaded concept. It is not so much
> about bug fixes and new features, but much more if those new features and
> bug fixes fit in the legal framework. Primarily are copyrights correct and
> licenses compliant? During voting it is assumed the the PMC takes a serious
> look at this. To help, during incubation, the IPMC will also take a serious
> look at this. Hence the double voting.
>
> If you come from outside the incubator (as Superset did and also Airflow
> did) then this process feels slow and bureaucratic. You releases when you
> wanted and no autonomy is taken away. You want to cater to your users and
> fix bugs quickly. Going back and forth to the IPMC  is a burden. To keep
> the momentum while (72h + 72h) * X times voting is tough. Particularly, if
> you are doing this on a voluntary basis.
>
> Now your users, that have grown beyond before you joined the incubator,
> trust the Apache brand and all that comes with it. Actually, because of the
> Apache brand some corporates (like mine) can now (finally) use Superset as
> we trust the process Apache puts in place.
>
> This vote doesn’t do that and you are not doing your users a favor with
> it. Moreover, you put them at risk of becoming legally liable. You can
> argue that having rc7 on PyPi for developer convenience is fine. ‘Pip’ does
> not install rc’s (or betas etc) without asking it to do so explicitly. It
> kind of works as Maven snapshots in the java world. So installation only
> happens when you know what you are doing and thus understand the extra risk
> that you are taking with installing it (functionally and legally). Justin
> might not entirely agree however ;-).
>
> So it is fine to point *developers* to a place where they can pick up what
> they need to further develop Superset. If that involves company wide
> testing so be it. It is assumed they know what they are doing. However, you
> cannot point you users to it. They have different expectations.
>
> Suggestion:
>
> 1) do not rename, everyone who needs development features and bug fixes
> can install the development version so they can use that for testing.
> 2) do not misuse “release”
>
> LICENSES
>
> I noticed that a lot of the files do not have ASF headers. I’m also pretty
> sure that Superset has quite a lot third party dependencies that come with
> their own licenses[1]. There is nothing in LICENSE.txt that points to those.
>
> Yes, it is not fun to track down all those licenses (and versions).
> However, it is mostly a one-off job. It only requires updating when you
> change or update the dependency. To a certain extend it can be automated
> even!
>
> Apache has some software that helps with license compliancy. Apache RAT
> works well and in Airflow we created a script that does this as part of our
> CI[1]. 

Re: [VOTE] release Superset 0.29.0rc7 as 0.29.0 to Pypi

[Bolke de Bruin]

Hi All,

(Part of the thread seems missing, but I assume everyone has the same history).

Just hopping over from Apache Airflow. We have been going through the same 
process and some of you even have been involved :-). We have also struggled 
along the way, but we found our path and have just graduated from the incubator 
last month. We are also a Python based project.

I personally reach out as I made the company I work for dependent on Superset, 
but we cannot continue to use it if it doesn’t eventually does a legal 
compliant release. During incubation the ASF puts you through the mill in order 
to get to such a release, but others like CNCF will require the same. 

So here to share some experiences, some suggestions, and offer some help.

On the ‘VOTE’

Releases in Apache’s world are a very loaded concept. It is not so much about 
bug fixes and new features, but much more if those new features and bug fixes 
fit in the legal framework. Primarily are copyrights correct and licenses 
compliant? During voting it is assumed the the PMC takes a serious look at 
this. To help, during incubation, the IPMC will also take a serious look at 
this. Hence the double voting.

If you come from outside the incubator (as Superset did and also Airflow did) 
then this process feels slow and bureaucratic. You releases when you wanted and 
no autonomy is taken away. You want to cater to your users and fix bugs 
quickly. Going back and forth to the IPMC  is a burden. To keep the momentum 
while (72h + 72h) * X times voting is tough. Particularly, if you are doing 
this on a voluntary basis.

Now your users, that have grown beyond before you joined the incubator, trust 
the Apache brand and all that comes with it. Actually, because of the Apache 
brand some corporates (like mine) can now (finally) use Superset as we trust 
the process Apache puts in place. 

This vote doesn’t do that and you are not doing your users a favor with it. 
Moreover, you put them at risk of becoming legally liable. You can argue that 
having rc7 on PyPi for developer convenience is fine. ‘Pip’ does not install 
rc’s (or betas etc) without asking it to do so explicitly. It kind of works as 
Maven snapshots in the java world. So installation only happens when you know 
what you are doing and thus understand the extra risk that you are taking with 
installing it (functionally and legally). Justin might not entirely agree 
however ;-).

So it is fine to point *developers* to a place where they can pick up what they 
need to further develop Superset. If that involves company wide testing so be 
it. It is assumed they know what they are doing. However, you cannot point you 
users to it. They have different expectations.

Suggestion: 

1) do not rename, everyone who needs development features and bug fixes can 
install the development version so they can use that for testing.
2) do not misuse “release”

LICENSES

I noticed that a lot of the files do not have ASF headers. I’m also pretty sure 
that Superset has quite a lot third party dependencies that come with their own 
licenses[1]. There is nothing in LICENSE.txt that points to those.

Yes, it is not fun to track down all those licenses (and versions). However, it 
is mostly a one-off job. It only requires updating when you change or update 
the dependency. To a certain extend it can be automated even!

Apache has some software that helps with license compliancy. Apache RAT works 
well and in Airflow we created a script that does this as part of our CI[1]. 
What we did (see git history) is to keep a count of the amount of “unknown” 
licenses and that count was not allowed to go up. I think we even did a force 
of -1 at some point to require PRs to add license headers so we didnt have to 
face that burden entirely on our own. How’s that for crowd sourcing :-).

Suggestion:

1) Add ASF headers to all files that should have it. Do this as a one-off 
semi-automation
2) Add Apache RAT as part of your build process and fail PRs if they don’t pass.


MY HELP:

Let me see if I can add Apache Rat.


Hope this helps!

Bolke


[1] https://github.com/syntagmatic/parallel-coordinates 

[2] https://github.com/apache/airflow/blob/master/scripts/ci/6-check-license.sh 



> Op 6 jan. 2019, om 22:02 heeft Justin Mclean  het 
> volgende geschreven:
> 
> Hi,
> 
> Release policy [1] states:
> "Projects MUST direct outsiders towards official releases rather than raw 
> source repositories, nightly builds, snapshots, release candidates, or any 
> other similar packages."
> 
> In this context an official release is an ASF source release vetted (usually 
> by voting) by the PPMC.
> 
> See also (for instance) [2] - "It is appropriate to distribute official 
> releases through downstream channels, but inappropriate to distribute 
> unreleased materials through them."
> 
> IMO you would need