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 <jeff.f...@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:626615...@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 <alanfga...@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.
> >
>
