Started a [VOTE] thread!
On Thu, Apr 11, 2019 at 12:20 PM Bolke de Bruin wrote:
> Im eager to vote ;-)
>
> Verstuurd vanaf mijn iPad
>
> > Op 9 apr. 2019 om 20:28 heeft Maxime Beauchemin <
> maximebeauche...@gmail.com> het volgende geschreven:
> >
> > Agreed, let me start a vote on the release I
Im eager to vote ;-)
Verstuurd vanaf mijn iPad
> Op 9 apr. 2019 om 20:28 heeft Maxime Beauchemin
> het volgende geschreven:
>
> Agreed, let me start a vote on the release I had put together.
>
>> On Tue, Apr 9, 2019 at 11:20 AM Bolke de Bruin wrote:
>>
>> Hi Max et al.,
>>
>> Finally it is
Agreed, let me start a vote on the release I had put together.
On Tue, Apr 9, 2019 at 11:20 AM Bolke de Bruin wrote:
> Hi Max et al.,
>
> Finally it is happening! Awesome! Let me know if I can help in anyway.
>
> I think it is fine push the tag to github if you haven’t done so yet. That
> has ne
Hi Max et al.,
Finally it is happening! Awesome! Let me know if I can help in anyway.
I think it is fine push the tag to github if you haven’t done so yet. That has
never been the issue. I also think your suggestion of doing a ‘Superset
compile’ will work. In the end it is always about the art
About licenses for this source release, we have to look and make sure the
copy/pasted code [if any] is gathered in LICENSE.txt I believe. Now that
we've move superset-ui out, that leaves very little behind in terms of
copied code. `superset-ui` has things copied from `blocks.org` . Maybe the
one fi
Has anyone done a first pass on the licenses, checking to see if there are
any obvious problems before going to lawyers with edge cases? If not, I can
have a look at that.
Dave
On Tue, Mar 26, 2019 at 11:08 PM Ville Brofeldt
wrote:
> If it helps I can walk through the the releasing steps and gi
If it helps I can walk through the the releasing steps and give feedback
(PR?), although I assume the critical steps require committer credentials
and have to be left out during a dry run.
Ville
‐‐‐ Original Message ‐‐‐
On Wednesday, 27 March 2019 07:22, Maxime Beauchemin <
maximebeauche.
I'm still wondering what to do with my Apache release attempt, we're now a
few RCs behind as `0.31.0.rc20` is on top of branch `release--0.31`
I'd love if someone can follow the steps I described in
https://github.com/apache/incubator-superset/blob/master/RELEASING.md (I
need a volunteer please!)
Thanks for the context, ya'll. Since SIP-12 had not been voted on for
adoption I was hoping to chime in before there was a lot of "sunk cost" and
before it was locked. Your background was helpful, thanks.
I do want to note that the motivation for my comments was not to make
running git commands an
Hi Dave,
We appreciate your comments on the release process and are glad to have
someone with experience about this topic on board. Before going deep into
the discussion about gitflow, we would like to clarify our stance on the
topic.
First of all, git workflow and cherry-pick are not the pain
Thanks, Michelle. The reliance on cherry-picking as part of a work flow can
definitely bring the process into conflict with other tools and processes
in the git ecosystem. I've left a fairly lengthy comment on SIP-12
proposing that the mechanics be handled using gitflow, which does not use
cherry-p
To answer the question about using a workflow for managing
releases/branches/tags, I previously evaluated using conventional commits:
https://www.conventionalcommits.org/en/v1.0.0-beta.3/, which is a system
for tagging commits to generate the changelog. At the time it seemed like
it may have issues
Fair, and you are correct, pypi explicitly forbids that representation, but I
think there are separable concerns here:
1) what is the Superset version?
2) how is that version represented in published artifacts across
potentially multiple consuming tech stacks?
I realize opinions may vary, but for
On Wed, 20 Mar 2019 at 13:40, Maxime Beauchemin
wrote:
> Python's PEP-440 says otherwise:
> https://www.python.org/dev/peps/pep-0440/#pre-releases
>
> I'm not 100% on this but if I remember correctly Pypi will reject that
> specific flavor of semver-compliant string. (ie: 0.32.0-rc1)
>
>
>
This i
Python's PEP-440 says otherwise:
https://www.python.org/dev/peps/pep-0440/#pre-releases
I'm not 100% on this but if I remember correctly Pypi will reject that
specific flavor of semver-compliant string. (ie: 0.32.0-rc1)
On Tue, Mar 19, 2019 at 9:37 PM David Smith wrote:
> One more note: to be s
One more note: to be semver compliant, the version string "0.32.0rc1"
should be changed to "0.32.0-rc1" (see rule #9 at https://semver.org)
On Tue, Mar 19, 2019 at 9:26 PM David Smith wrote:
> I'm new to this project, so I apologize if this has been discussed
> previously, but... Have we conside
I'm new to this project, so I apologize if this has been discussed
previously, but... Have we considered using a widely adopted workflow for
managing releases/branches/tags, and using tools that the community has
already built for them? For example Git Flow or some variant thereof? For
anyone who
Wondering what to do next, Justin, is it ok for me to push the related tag
to Github?
Should I trigger a [VOTE] thread?
Max
On Tue, Mar 19, 2019 at 12:04 AM Maxime Beauchemin <
maximebeauche...@gmail.com> wrote:
> My svn is a bit rusty but I made some progress tonight:
> https://github.com/apac
My svn is a bit rusty but I made some progress tonight:
https://github.com/apache/incubator-superset/pull/7054
Pushed some files to SVN
https://dist.apache.org/repos/dist/dev/incubator/superset/0.31.0rc18/
It's not intended to be an actual real RC, but it's a start.
An early question is around R
Not officially approved yet, I think we should start a [DISCUSS] thread and
eventually [VOTE]
On Mon, Mar 18, 2019 at 10:13 PM David Smith wrote:
> Thanks Max! Out of curiosity, has that release SIP-12 been approved yet? I
> have some thoughts but if it is already a done deal I'll wait until ano
Thanks Max! Out of curiosity, has that release SIP-12 been approved yet? I
have some thoughts but if it is already a done deal I'll wait until another
time. :-)
On Mon, Mar 18, 2019 at 9:53 PM Maxime Beauchemin <
maximebeauche...@gmail.com> wrote:
> Hi all,
>
> I wanted to send an email explainin
Hi all,
I wanted to send an email explaining the current state of releases and
start a thread about what's ahead.
Early on in the project lifecycle, I used to package releases and push to
Pypi without much process. I'd package internal releases internally for
Airbnb. We'd roll out to staging, sta
22 matches
Mail list logo
