Great, thanks Dave
On Sun, Sep 6, 2020, 00:17 Dave Fisher wrote:
> Every release must be made in SVN on dist.apache.org. All other channels
> are optional and may or may not have Infra support.
>
> I view this as a request to have ComDev or Infra manage a Gitbox/Github
> repository where any PMC
Every release must be made in SVN on dist.apache.org. All other channels are
optional and may or may not have Infra support.
I view this as a request to have ComDev or Infra manage a Gitbox/Github
repository where any PMC can publish a PMC approved Helm Chart release from
their project.
How to
>The point is that we MUST give the users possibility to (re)build those
images on their own if they want.
>From http://www.apache.org/legal/release-policy.html#source-packages, it
does not say it has to be on PyPI. I will reiterate what I said in the
Github issue, having a binary on PyPI is no g
@Matt Sicker -> agree on both, central chart repo, and
per-project sources for charts. Though packaging is a bit different than
Docker though. The packages contain tar.gz sources of the chart (which
usually includes quite complex go templating logic, not just simple yaml
files) and those template
Does voting needs to happen for "releasing" the Helm chart ? Do we any
guidelines from the ASF around releasing Helm Chart & Dockerfile?
On Sat, Sep 5, 2020, 17:36 Matt Sicker wrote:
> If packaging is similar to Docker, then our Helm charts will still
> need some third party base images and such
[
https://issues.apache.org/jira/browse/COMDEV-269?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shi Jinghai closed COMDEV-269.
--
Resolution: Invalid
Close now.
> GSOC 2018 OFBiz Extend AR/AP to support China accounting regulations
[
https://issues.apache.org/jira/browse/COMDEV-270?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shi Jinghai closed COMDEV-270.
--
Resolution: Invalid
I agree with Jacques. This issue is no longer valid as it's for gsoc 2018.
Close n
If packaging is similar to Docker, then our Helm charts will still
need some third party base images and such for GPL licensed system
dependencies (besides the kernel itself, there's OpenJDK which is
definitely used in plenty of projects here). The bits we build on top
of external components become
While I understand the necessity for users to have access to all source code,
I'm a bit concerned about the complexity this places on the open-source
project. Let's take Airflow as an example. If we want to use pgbouncer in our
home chart are we expected to be able to build this external project
[
https://issues.apache.org/jira/browse/COMDEV-270?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17191050#comment-17191050
]
Jacques Le Roux commented on COMDEV-270:
I see no reasons to not close this issue
10 matches
Mail list logo
