Re: [VOTE] Podling web sites: make (incubator.) optional in podling urls

[Daniel Gruno]

+1, binding.

On 3/12/24 19:36, Craig Russell wrote:

After this discussion
https://lists.apache.org/thread/frwsy1g1pkx3ppbvzt538xxh9qo9y319
I'd like to propose that we make the incubator. part of the URL optional for 
podlings.

This is a way to minimize the work needed to graduate. No redirect or 
reimplementation of the web site is required.

https://incubator.apache.org/guides/branding.html will need to change only the 
URL requirement. Other branding requirements are still applicable.

While most podlings do have incubator. in their URL, several do not and it is a 
flag for the web site checker.

+1 make incubator. optional in URL
+0 do not care strongly
-1 keep the requirement for incubator. in URL

Please vote with your ASF id followed by (binding) if you are a member of the 
Incubator PMC or (not binding) if not.

Vote will be open for at least 72 hours.

Here is my +1

Craig L Russell
c...@apache.org


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [QUESTION] Reproducible build for container images

[Daniel Gruno]

On 1/23/24 15:49, PJ Fanning wrote:

Hi Alex,

While reproducible builds are a great idea, the Incubator PMC does not
require them. Plugging away at improving things so that reproducible
builds can be produced in future is a useful thing to do.


This may be related to https://issues.apache.org/jira/browse/INFRA-25140 
which *does* require reproducible builds for KIE.




Regards,
PJ

On Tue, 23 Jan 2024 at 14:58, Alex Porcelli  wrote:


In the KIE podling, we regularly publish container images as part of
our releases. We've achieved semantically identical images, verified
using the 'diffoci' tool. However, due to current Docker/OCI engine
limitations, we can't eliminate variations in file metadata caused by
automatically appended timestamps.

The latest version of Buildkit offers a solution but still needs to be
integrated into the build engines. I want to ask the Incubator PMC: Is
achieving semantically verifiable images sufficient for now, as we
await the integration of Buildkit changes into Docker/OCI build
engines?

Regards,
-
Alex
Apache KIE PPMC

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [RESULT][VOTE] Release Apache Wayang (Incubating) v0.7.1 RC3

[Daniel Gruno]

On 2023-09-18 15:20, Gláucia Esppenchutz wrote:

Hello everyone,

I am pleased to announce that the vote for Apache Wayang(Incubating)
v0.7.1 RC3 has now concluded. Thank you all for your review and
participation in the voting process.

I am happy to inform you that the release voting has passed with 3 binding
votes and there were no +0 or -1 votes.

The individuals who provided binding votes are:

- Alexander Alten-Loren
- Jean-Baptiste Onofré
- Christofer Dutz
- Zoi Kaoudi
- Paul King


Alexander Alten-Loren and Zoi Kaoudi are not IPMC members, so their 
votes are non-binding in this instance. The remaining three people are 
IPMC members, so you do have the three +1s you need.




You can find the voting thread at the following link:
https://lists.apache.org/thread/xpnknwqqcngvhfgmny9ks3bqnpjqkd7w

I want to express my gratitude to everyone who has offered us help, advice,
and guidance throughout this process.

Thank you all!

Regards,
Glaucia Esppenchutz




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Looking for a Champion / Mentors for ResilientDB Blockchain Platform

[Daniel Gruno]

On 2023-08-18 09:54, Calvin Kirs wrote:

Hi Mohammad,

We usually just need one champion, I see David expressing interest and
I think he is a good champion.


David would not be admissible as a champion, as that requires a person 
to be either a foundation member or officer. See 
https://incubator.apache.org/guides/roles_and_responsibilities.html#Champion 
for details.





On Fri, Aug 18, 2023 at 12:15 PM Mo Sadoghi  wrote:


Dear Calvin,

Thank you so much for your kind support.

It would be great to have you as a mentor. Would you be open to serving as 
Champion, too, given your extensive experience?

Greatly appreciated.

---
Best Regards,
Mohammad Sadoghi, PhD
Associate Professor
Exploratory Systems Lab (ExpoLab)
Department of Computer Science
University of California, Davis

ExpoLab: https://expolab.org/
ResilientDB: https://resilientdb.com/
Phone: 914-319-7937


Statements by UC Davis: Chancellor Gary S. May, Dean Corsi (College of 
Engineering), Middle East/South Asia Studies

Personal Statement: We stand in solidarity with the brave and determined 
Iranian women and Iranian people. We are committed to upholding fundamental 
human rights, maintaining equity and justice, and standing against the use of 
violence, repression, and discrimination. We condemn the barbaric acts and 
brutal killings in Iranian streets, of innocent people in Ukraine, and 
everywhere globally.


On Thu, Aug 17, 2023 at 7:15 PM Calvin Kirs  wrote:


Hi,

Please count me in, I'm interested in this project and I am happy
to help as a mentor.

I have been involved in the incubation process of several projects and
have experience with this.

On Fri, Aug 18, 2023 at 9:40 AM 俊平堵  wrote:


Hi,
 The project looks interesting to me and I am happy to help as mentor.
  BTW, I am PMC of hadoop, Ozone, and mentor Yunikorn, Evenmesh, Linkis,
etc. towards Apache TLP.

Thanks,

JP

Mo Sadoghi  于2023年8月18日周五 05:55写道：


Dear Apache Members,

Hope you are safe and well.

Over the past 6 years, we have been developing a distributed blockchain
framework, called ResilientDB , which has been
open-sourced  since 2019.
ResilientDB is a lightweight and highly performant framework (written in
C++) that has been extensively evaluated and refined resulting in over 20
publications and 2 books. It allows for easy integration with various
Byzantine Fault-Tolerant (BFT) and Crash Fault-Tolerant (CFT) consensus
protocols. ResilientDB has been a key educational tool, thus far, 1
postdoc, 3 Ph.D., and 13 MSc students have graduated while working on it.
Furthermore, it has been used in the classroom for the past 5 years with
several hundred students utilizing it for their course projects. The
current core team of ResilientDB consists of 1 Postdoc, 2 PhD, 8 MSc, and 6
BSc.  In addition to academic success, it has been utilized by our industry
partners (e.g., Radix Ltd  and Mysten Labs
) for analysis and as an industrial-strength
framework to implement their consensus protocols. The broader team of
active contributors currently included UCB, UCI, UPenn, and McMaster U.

Our ResilientDB platform has now reached a stable point in its product
life-cycle, and we believe it is now an excellent candidate to be
considered for the Apache Incubation program to further expand its reach
and development by building a larger community and ecosystem around it.
Furthermore, considering the thriving field of blockchain / distributed
ledger, Apache does not have any core blockchain software in its portfolio.

We are looking for champions and mentors for our project. Your kind support
is greatly appreciated. We look forward to growing and expanding our
product as part of the Apache community.

Here is the live / latest draft of the proposal.

https://docs.google.com/document/d/12WPvs1A7tqH8VjkMrgXTGQ_z4fiL6f6oi32e7bxSjXc/edit?usp=sharing

Currently, we have *Anh Dinh*, Apache SINGA’s PMC, as our Apache mentor
(cc'ed).

---
Best Regards,
Mohammad Sadoghi, PhD
Associate Professor
Exploratory Systems Lab (ExpoLab)
Department of Computer Science
University of California, Davis

ExpoLab: https://expolab.org/
ResilientDB: https://resilientdb.com/
Phone: 914-319-7937





--
Best wishes！
CalvinKirs

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org







-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Feedback requested - How to deal with retired podling resources

[Daniel Gruno]

On 2023-07-31 22:46, Julian Hyde wrote:

In regard to assets, I see no particular reason to treat retired podlings differently 
from graduated podlings. Keep the foo.apache.org <http://foo.apache.org/> 
hostname; retain the repository (read-only); keep the website (tagged with a notice 
’This podling has retired. It may be contacted at …’.)

It is certainly useful for people to be able to access the podling’s source 
code as of the day it retired.

If there are other considerations (cost, security, legal) then we could 
reconsider.


I believe this covers two of the questions, but I have not gotten an 
answer on the middle question; who handles the retired resources?
We can keep the repositories as is and just archive/lock them, but infra 
is not going to start editing websites and READMEs to add the retirement 
notices. That responsibility still rests with the Incubator.




Julian


On Jul 31, 2023, at 3:51 AM, Daniel Gruno  wrote:

Hi incubator folks,
over at Infra, we occasionally have requests to retire podlings, and while we 
do have a specific set of policies for TLPs, it gets a bit vague when it comes 
to podlings. I have tried looking for the IPMC's own guidelines, but it seems 
that the retirement guide does not exist ( 
https://incubator.apache.org/guides/retirement.html 404s!).

Thus, I would like to get the incubator's official opinion on how podling 
retirements should be effectuated:

- Do we keep the podling foo.apache.org hostname in perpetuity?
- Are repositories and other material removed? handed to the attic? moved to a 
special incubator-retired-* prefix?
- What happens to the podling websites?

With regards,
Daniel on behalf of ASF Infra.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org







-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Apache infrastructure for CI?

[Daniel Gruno]

On 2023-08-02 16:41, Alex Porcelli wrote:

Is there an infrastructure in Apache for CI (Jenkins, etc) for its projects?


See https://infra.apache.org/build-supported-services.html



If yes, where can we find more information on how to onboard?

If not, how do projects deal with CI infrastructure?

Regards,
Alex Porcelli
KIE Podling

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Feedback requested - How to deal with retired podling resources

[Daniel Gruno]

Hi incubator folks,
over at Infra, we occasionally have requests to retire podlings, and 
while we do have a specific set of policies for TLPs, it gets a bit 
vague when it comes to podlings. I have tried looking for the IPMC's own 
guidelines, but it seems that the retirement guide does not exist ( 
https://incubator.apache.org/guides/retirement.html 404s!).


Thus, I would like to get the incubator's official opinion on how 
podling retirements should be effectuated:


- Do we keep the podling foo.apache.org hostname in perpetuity?
- Are repositories and other material removed? handed to the attic? 
moved to a special incubator-retired-* prefix?

- What happens to the podling websites?

With regards,
Daniel on behalf of ASF Infra.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: do we need to go through an Incubator PMC for a build tool?

[Daniel Gruno]

On 2023-07-04 11:44, Claude Warren wrote:

You could try the Petri route if the devs are ASF members.


Regardless of the route chosen, for an official release you will always 
need to adhere to the standard release process (72+ hours, min 3x+1, 
more +1s than -1s, must be ALv2, etc etc). I don't think spawning 
another project for this is ideal, as you'd then ulitmately be required 
to report for both projects to the board.




On Mon, Jul 3, 2023 at 5:12 PM Sheng Wu  wrote:


Hi

If we want that jar under asf package on maven central, yes, a new version
is required a vote on dev first, then incubator.
Meanwhile, if we have all mentors(ipmc members as well) voted, we just
need to carry votes to incubator mail list, and another 3 days.

Just one thing, if the jar has dependencies, we need to check license
compatibility.

PJ Fanning 于2023年7月3日 周一17:06写道：


Adding the Pekko mentors to the thread if that's ok.

It's not a blocker for us to use a snapshot version of the
Pekko-specific build tool but it would be tidier if we could release a
stable version to Maven Central. If this requires us to release a
source artifact via the full voting procedure then that is fine. I
just want to make sure that this is a necessary step before going that
route.

On Wed, 28 Jun 2023 at 18:38, PJ Fanning  wrote:


Hi everyone,

The Apache Pekko community has a tool that is used as part of building
our web site [1].
sbt-paradox-pekko [2] applies the theme to the Pekko web site. It is
not useful for outside users.
We require that a Java/Scala jar is published because this tool is
used in a number of different Pekko projects (ie different Apache git
repos that the Pekko team maintain).
We haven't yet released an official 1.0.0 jar and are using a snapshot

jar.

If we wanted to publish an official 1.0.0 jar, would we need to have
an Incubator PMC vote on it. We will have a Pekko discussion and
possibly a vote if it seems appropriate.

Any insights would be appreciated.

Regards,
PJ

[1] https://pekko.apache.org
[2] https://github.com/apache/incubator-pekko-sbt-paradox



--
Sheng Wu 吴晟

Apache SkyWalking
Apache Incubator
Apache ShardingSphere, ECharts, DolphinScheduler podlings
Zipkin
Twitter, wusheng1108






-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [REQUEST] Grant permission to deploy Maven project via GitHub Actions

[Daniel Gruno]

On 2023-07-03 12:52, PJ Fanning wrote:

Adding the Incubator general list.

My view would be that non-snapshot binary artifacts should be signed
with a personal signing key - ideally the signing key that was used to
release the related source release. Unfortunately, this would mean
adding a user's signing key to the Apache GitHub account as a secret
so that the automated GitHub Action job could access it. I don't see
how we could allow personal signing keys to be added like this.


We don't and won't put personal keys into any CI system.

Please see 
https://infra.apache.org/release-signing.html#automated-release-signing 
for how to go about this. There is a standardized workflow here.




On Mon, 3 Jul 2023 at 10:18, tison  wrote:


cc security

Missed in the first place.

Best,
tison.


tison  于2023年6月29日周四 22:21写道：


Hi security team members,

I'm tison from OpenDAL Podling[1], a Rust lib providing Java binding.

I already verify that GitHub Actions work well for automatically deploying 
OpenDAL Java binding[2].

When integrating it with upstream (apache/incuabtor-opendal), I met a problem 
that deploying Maven projects requires NEXUS credentials. For my personal repo, 
I can config my Apache ID and password as secrets. For apache repos, it 
requires handing over the credentials to INFRA team member. Even I can trust 
the member, it's a bit less than awesome.

Fortunately, INFRA provides two org-wise secrets NEXUS_USER and NEXUS_PW for 
doing so[3]. But it's limited to deploying snapshots only. INFRA member 
suggested me to consult security team for approval for such automatic 
deployment and they would help to grant related permissions if approved.

Please help review the request to support ASF projects deploying Maven project 
via GitHub Actions.

Best,
tison.

[1] http://github.com/apache/incubator-opendal
[2] https://github.com/tisonkun/ci-opendal/actions/runs/5326589752
[3] 
https://github.com/apache/incubator-opendal/blob/f887b671c0aae523d8862762eec71e6179e0975c/.github/workflows/bindings_java.yml#L192



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Question on GitHub

[Daniel Gruno]

On 2023-06-27 15:51, Brian Proffitt wrote:

Okay, but what if they have namespace issues with code pointing to their
existing GH repos? We had asked about this a while back, and I thought the
take away was we could keep the existing GH repos in place.


That is where transfers come into play. If a repository is _transferred_ 
(as opposed to copied or recreated), the old URL will automatically 
redirect to the new one. Thus https://github.com/foo/kie-blabla.git 
would automatically redirect to 
https://github.com/apache/incubator-kie-blabla.git


Transferring the canonical source repository to the ASF (which means a 
dual-master setup on gitbox and github) is a requirement for graduation, 
but I am not aware that this needs to happen at a specific point during 
incubation...so long as it happens.




Did I misunderstand?

BKP

On Tue, Jun 27, 2023 at 9:45 AM PJ Fanning  wrote:


Use the ASF Self Serve tool [1] to create the git repos in ASF gitbox
and they will be mirrored on GitHub automatically.

It's easy to copy the git history from an existing git repo into the
new ASF ones.

[1] https://selfserve.apache.org/

On Tue, 27 Jun 2023 at 14:42, Dave Fisher  wrote:


They are required to have an ASF served repository either SVN or GiT.

Infra has setup the ability to keep the ASF git repository in sync with
GitHub repositories in the Apache org space. Podlings starting incubation
are supposed to transfer their repositories to the ASF.


Best,
Dave

Sent from my iPhone


On Jun 27, 2023, at 6:33 AM, Brian Proffitt  wrote:

The KIE podling has a question that I don't know the answer to. They

are

wondering if they are required to mirror their source into the Apache
GitHib organization? They will be hosting their code in their own GH

repo,

but they want to know if the mirror is necessary as well.

BKP


Brian Proffitt
VP, Marketing & Publicity
Co-organizer, Community Over Code
Member, Apache Software Foundation
Member, Apache Community Development & Incubator PMCs
Red Hat Open Source Program Office



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org







-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: is it ok to modify copyright headers that have no end year?

[Daniel Gruno]

I would not modify the copyright notice. As it stands in the document 
right now, it is set to expire in the year 2111. If you modify, you are 
(incorrectly) extending that by a few years without any explicit request 
or consent from Lightbend.


Copyright notices are mainly a guard against noncompliance and should 
not be updated to reflect the current year unless you specifically have 
added new components and wish to extend the copyright for those by 
specifying a range (e.g. 2016-2022 etc).


My advice, keep it as is. Having ranges muddies the legal waters, as you 
then have parts of it copyrighted from 2016, then some bits in 2017, 
then 2018, etc. Sorting that out is a mess :)



On 2023-06-26 16:40, PJ Fanning wrote:

Hi everyone,

The Pekko community is working on a release of our core repository. We
have a number of other repositories that we will release later.

In one of these downstream repositories, the source code has Lightbend
copyrights that say (example [1]):

Copyright (C) since 2016 Lightbend Inc.

Since the Pekko forked this code at a point in September 2022, is it
ok to change this copyright to this?

Copyright (C) 2016-2022 Lightbend Inc.

It doesn't seem right to leave the copyright claim open ended and
effectively implying that any changes made this year by the Apache
Pekko community are covered by Lightbend copyright.

Generally, I wouldn't modify any headers like this but this one seems
to require modification.

Any insights would be appreciated.

Regards,
PJ

[1] 
https://github.com/apache/incubator-pekko-connectors/blob/178795f6882e2d06524962f30359691889489fd5/s3/src/main/scala/org/apache/pekko/stream/connectors/s3/Utils.scala#L11

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: July 2023 Incubator report timeline

[Daniel Gruno]

On 2023-06-21 15:25, Jia Fan wrote:

Hi Justin, SeaTunnel already graduated, are we still need report to
incubator?


No. Your reporting schedule can be found at reporter.apache.org - that's 
the only one you need to follow. Disregard this message :)




Justin Mclean  于2023年6月21日周三 20:45写道：


Hi,

https://cwiki.apache.org/confluence/display/INCUBATOR/July2023

 Wed July 05 -- Podling reports due by end of day
 Sun July 09 -- Shepherd reviews due by end of day
 Sun July 09 -- Summary due by end of day
 Tue July 11 -- Mentor signoff due by end of day
 Wed July 12 -- Report submitted to Board
 Wed July 19 -- Board meeting

Project expected to report:
- Annotator
- Datalab
- Hugegraph
- Liminal
- Livy
- Milagro
- Pegasus
- Pekko
- Ponymail
- Seatunnel
- Teaclave
- Toree
- Training

Kind Regards,
Justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org







-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[jira] [Deleted] (INCUBATOR-276) Usability issues with WebMod list moderator page

[Daniel Gruno (Jira)]

 [ 
https://issues.apache.org/jira/browse/INCUBATOR-276?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Daniel Gruno deleted INCUBATOR-276:
---


> Usability issues with WebMod list moderator page
> 
>
> Key: INCUBATOR-276
> URL: https://issues.apache.org/jira/browse/INCUBATOR-276
> Project: Incubator
>  Issue Type: Improvement
>Reporter: Andrew Wetmore
>Priority: Major
>
> The 'List moderator management' page needs a couple of improvements:
>  * There should be some padding to move the actionable area in from the edge 
> of the screen, so the experience is similar to that on the email moderation 
> page.
>  * Black text on a dark blue background is very hard to read.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Removed 'incubator.' from project status template

[Daniel Gruno]

On 2022-10-20 14:59, Dave Fisher wrote:

+1. Infra provides both urls immediately and incubator versions of urls live in 
the codebase forever.


Correct, we specifically made this change (from foo.incubator.a.o to 
foo.a.o) so that we would not have to migrate mailing lists after 
graduation, which used to be a very cumbersome task.




The exception would be git repository names and svn dist paths.


Agreed, for legal reasons :)



Regards,
Dave

Sent from my iPhone


On Oct 20, 2022, at 11:50 AM, Julian Hyde  wrote:

FYI, I removed 'incubator' from the project status template [1]. In
Baremaps we concluded that we wanted the shorter URL and email
addresses that would survive into graduation. And I figured that the
next podling would want to do the same.

If there are objections I can back it out.

Julian

[1] 
https://svn.apache.org/viewvc/incubator/public/trunk/content/projects/incubation-status-template.xml?r1=1882331=1904748_format=h

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] What to do with long incubating projects?

[Daniel Gruno]

On 2022-10-18 14:34, Julian Hyde wrote:

One idea is to schedule a review after the project has been in the
incubator longer than the median time (say after 2 years). Deep-dive
into what is going right and wrong, identify things that can be fixed,
and set targets. And schedule another review a year later. Or schedule
a vote to retire.

One might even do this review (gasp!) over Zoom, so that people can
ask questions and have them answered in real time.


Brainstorming etc in a synchronous way is totally fine, as long as it is 
open and scheduled in an inclusive manner with an exhaustive summary to 
the mailing list afterwards. The primary rule about asynchronicity 
concerns decisions and the data that flow to and from those decisions.


The rule "if it didn't happen on the mailing list..." is essentially two 
parts:

1. Everyone must be allowed to participate in shaping the project
2. All decisions and the inputs that shaped that MUST be archived on the 
mailing list for provenance/governance to work as intended.


I am satisfied that having a zoom meeting or whatever (slack huddle??) 
would be just fine here. Our board of directors also conduct their 
meetings via video :)





It sounds shockingly invasive, considering we at Apache tend to do
everything asynchronously. But it's better than the alternative, which
is a slow death as mentors and initial committers drift away.

Julian




On Tue, Oct 18, 2022 at 12:27 PM Justin Mclean  wrote:


Hi,

Looking at the longest incubating projects, one has graduated and needs some 
cleanup, one had a reboot, one is discussing a reboot, and several have roll 
calls in progress or are discussing retirement. However there are two or three 
other projects that either should retire or graduate and have been incubating 
for far too long.

But taking a step back what can we do to make projects life though the 
incubator shorter? Would having more resources help? (If so what resources?) 
What else might we be able to do - offer training for instance?

Kind Regards,
Justin


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [MENTORS] Late podling reports and missing signoffs

[Daniel Gruno]

On 2022-10-10 03:19, Calvin Kirs wrote:

Hi,
EventMesh, Milagro, and PonyMail haven't been signed off by a mentor yet.


Pony Mail hasn't had a mentor sign off for the last four reports. I 
think it's safe to say our mentor is not available right now :-).


Having said that, I think we'll be fine without one for now.



On Fri, Oct 7, 2022 at 6:06 AM Furkan KAMACI  wrote:


Hi,

Exactly! Most of the mentors (including me) at ApacheCon. I think they will
all take care of it before the deadline.

Kind Regards,
Furkan KAMACI

On 6 Oct 2022 Thu at 10:09 Calvin Kirs  wrote:


On Thu, Oct 6, 2022 at 10:45 PM Daniel Gruno  wrote:


On 2022-10-06 07:15, Calvin Kirs wrote:

Hi,

We are missing reports from:
- EventMesh
- HugeGraph
- MarvinAI
- Nuttx
- Spot
- Teaclave
- PonyMail

We are missing mentor sign-off on:(Mentor signoff due by end of days
is Tue Oct 9)
- DataLab
- Flagon
- Milagro



I suspect ApacheCon is causing some reports to be delayed for a couple
of days...

Yes, I know we have a lot of people who went to Apache Con, but it
doesn't matter, we still have time to submit our reports.


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




--
Best wishes！
CalvinKirs

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org









-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [MENTORS] Late podling reports and missing signoffs

[Daniel Gruno]

On 2022-10-06 07:15, Calvin Kirs wrote:

Hi,

We are missing reports from:
- EventMesh
- HugeGraph
- MarvinAI
- Nuttx
- Spot
- Teaclave
- PonyMail

We are missing mentor sign-off on:(Mentor signoff due by end of days
is Tue Oct 9)
- DataLab
- Flagon
- Milagro



I suspect ApacheCon is causing some reports to be delayed for a couple 
of days...


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [MENTORS] Download page issues

[Daniel Gruno]

On 02/11/2021 06.42, Justin Mclean wrote:

Hi,

My understanding is that https://www.apache.org/dist/ has been deprecated.

So for Pony Mail I would I change these links to go via 
https://downloads.apache.org/
  -  https://www.apache.org/dist/incubator/ponymail/KEYS
  - 
https://www.apache.org/dist/incubator/ponymail/apache-pony-mail-0.11-incubating.tar.gz.asc
  - 
https://www.apache.org/dist/incubator/ponymail/apache-pony-mail-0.11-incubating.tar.gz.sha256


I can change those, no problem. I just don't see it as 'incorrect' per se.



You also have a link to 
/dyn/closer.cgi/incubator/ponymail/apache-pony-mail-0.11-incubating.tar.gz. 
It’s not recommended to use closer.cgi anymore, you probably want to use 
https://www.apache.org/dyn/closer.lua instead.


They are the same file/script :) *.cgi goes to closer.lua internally, so 
this should be fine.




Kind Regards,
Justin


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [MENTORS] Download page issues

[Daniel Gruno]

Could you tell me what's wrong with the pony mail links?
/dist/ redirects to downloads.apache.org so technically it's valid.

with regards,
Daniel.
On 02/11/2021 04.09, Justin Mclean wrote:

Hi,

A while back we asked projects to correct their download pages, however I’m 
still seeing a lot of issues.

Project with issues seem to include the following. This this is auto generated 
so there a possibility it may have picked up some false positives.

Age
links to KEYS are missing
incorrect links to sha asc

Annotator
incorrect links to sha asc

DataLab
Links to signatures and hashes are missing
Links to KEYS are missing

Doris
incorrect links to sha asc downloads

EventMesh
incorrect links to downloads

HiveMall
incorrect links to sha asc downloads

Livy
incorrect links to sha asc

Milagro
incorrect links to sha asc downloads

Nemo
incorrect links to downloads
What is in dist area doesn’t match download page

NLPCraft
incorrect links to sha asc

NuttX
incorrect links to sha asc

Pagespeed
Links to signatures and hashes are missing
Links to KEYS are missing

Pegasus
incorrect links to downloads

Ponymail
incorrect links to sha asc downloads

Shenyu
What is in dist area doesn’t match download page

Spot
incorrect links to sha asc downloads

Teaclave
incorrect links to sha asc downloads

Training
Links to KEYS are missing
incorrect links to sha asc

Kind Regards,
Justin


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Unable to access Incubator's web page

[Daniel Gruno]

On 19/07/2021 12.03, Wei-Chiu Chuang wrote:

I am trying to access the Apache Incubator's web page
https://incubator.apache.org/

But it returned with an error message

Misdirected Request

The client needs a new connection for this request as the requested host
name does not match the Server Name Indication (SNI) in use for this
connection.

I tried a few other Apache project web pages and none else has the same
issue. Did someone update the web page recently?



There's currently an issue with the web site Jenkins job, in that it 
relies on a jbake that isn't available any longer.


I am working on fixing the issue, so the web site should be back soon...

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] YunionCloud Proposal

[Daniel Gruno]

On 14/04/2021 09.06, Jian Qiu wrote:

Hi, Dave,

When we decide to donate project to Apache Incubator, we consider several
candidate names and make a vote in our community, the results are
as follows:

* YunionCloud - a cloud union of Clouds, 26 vote
* UnioneCloud - to unify many clouds into One Cloud, 10 vote
* OpenYunion -  open source Cloud Union, 5 vote
* OpenMHCP - open source Multi/Hybrid Cloud Platform, 2 vote

So we decided to choose YunionCloud as the new name. But we did not
realize it conflicted with our company domain name.

As you suggested, we would like to consider UnioneCloud as the project name.

Would you consider UnioneCloud an appropriate project name?


What does the E in UnioneCloud signify? I must confess I find it 
distracting that there is what appears to the average reader as a typo, 
but if there is a reason you did not pick UnionCloud, I'd be happy to 
hear it :)




Many thanks,

Jian Qiu

Willem Jiang  于2021年4月14日周三 上午9:47写道：


Hi Dave,

I understand your concern. Actually,  I had a long discussion with the
team about the project name, but I missed that the company's domain
name has a close relationship with the project name.
Now the development team is working on finding a new name for it.  We
will come back with a new project name for this proposal.

Regards,

Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Tue, Apr 13, 2021 at 1:26 PM Dave Fisher  wrote:


This looks like an interesting project.

My concern is that the donation comes from https://www.yunion.cn which

has a similar name to the podling and that might cause trademark confusion.


Regards,
Dave


On Apr 11, 2021, at 9:40 PM, Jian Qiu  wrote:

Dear all,

We would like to propose YunionCloud as a new Apache Incubator project.

YunionCloud is a unified multi-cloud/hybrid-cloud management platform.

It

is an IaaS platform capable of managing on-premise resources, including
virtual machines and BareMetals. Further, it is extended to manage
resources from other cloud platforms, including public and private

cloud

providers. It provides consistent APIs and Web UI to access

heterogeneous

resources from multi-cloud/hybrid-cloud. The platform is implemented in
Golang, portable and lightweight, and can be deployed in Kubernetes
clusters.

The proposal can be found at


https://cwiki.apache.org/confluence/display/INCUBATOR/YunionCloud++Proposal


The project has been open-sourced since March 2019 at GitHub
https://github.com/yunionio/yunioncloud

The project used to be called OneCloud, but we are in the process of
changing the name to YunionCloud to avoid potential trademark

conflicts.


Many thanks to Willem Jiang as our champion and mentor to guide us to

set

up this proposal. We still need 2-3 mentors to set us on the track. If

you

are interested, please kindly let me know. Besides, we are eager to

hear

any of your thoughts on this project.

Looking forward to your feedback and thank you for your time.

Best regards,

Jian Qiu, Co-found of YunionCloud
sword...@gmail.com



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org







-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [MENTORS] Podling reports due today

[Daniel Gruno]

On 05/08/2020 00.51, Justin Mclean wrote:

Hi,

Podling report are due today and currently we’re waiting on the following 
projects.

Annotator
BlueMarlin
Doris
Liminal
Livy
NLPCraft
Pinot
S2Graph
SDAP
Sedona
Training
Tuweni
Warble


Warble effectively retired/went dormant, FWIW.
Don't expect a report.



Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Graduate Apache Hudi (Incubating) as a TLP

[Daniel Gruno]

On 13/05/2020 20.47, Justin Mclean wrote:

Hi,


Folks, just as a reminder. We are approaching 72 hours. Please provide your 
comments sooner than later!


There's no real time limit for discussion to graduate. I just wait for the 
conversation to die down, but input from other IPMC members would be 
appreciated.


One might say, if there's one final send-away message from the 
incubator, it's this :) 72 hours is a rule of thumb, if it takes a month 
to get a vote, release, whatever done, then a month it takes :). 72h is 
the established *minimum* votes should run for, not the maximum.




Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[ANNOUNCE] Apache Pony Mail (incubating) 0.11 released

[Daniel Gruno]

Hi folks,
I am pleased to announce the release of Apache Pony Mail (incubating) 
version 0.11.


You may download Pony Mail 0.11 at:

http://ponymail.incubator.apache.org/downloads.html


Fixes in Pony Mail 0.11 include:
##
Bug: Tidy up list names on seeding pages to avoid breakage
Enh: Enforce UTF-8 in content headers (#479)
Bug: elastic.lua#scroll forces sort to use _doc (#478)
Bug: cannot download more than 10K mails to a mbox file (#475)
Bug: no need to sort after scroll (#477)
Enh: Ensure non-printable chars are not lost in source and mbox output 
(#476)

Enh: display buttons even if no mails are found in a month (#470)
Bug: Javascript URLs must always use URL_BASE (#469)
Bug: setup.py uses ES library version to decide what features the 
database supports (#464)

Various tidyups suggested by Pylint
Bug: archiver.py can never detect content-type: flowed (#461)
Bug: import-mbox.py: imap code should not reset ES instance (#460)
Bug: tmpname used before it has been set up in import-mbox (#458)
Bug: variable 'mid' used before assignment in archiver.py (#459)
Enh: remove duplicated code in tools scripts by using elastic.py module 
(#456)

Enh: separate module to read config file
Bug: push-failures.py expects to find non-existent 'id' key in json file 
(#454)

Bug: ES 5.x does not support word-cloud (stats.lua) (#345)
Add version info to elastic module
Bug: setup.py fails with ES2 - fielddata (#453)
Bug: setup.py --default should not prompt for urlPrefix (#452)
Bug: copy-list.py does not work (#450)
Bug: unnecessary test (will always succeed) in copy-list.py (#451)
Bug: archiver ignores failures if dumponfail is not defined (#449)
Enh: make MboxoFactory optional (#442)
Bug: duplication of data in response from thread.lua (#440)
Bug: Indentation in mail content (leading white-space) not shown (#432)
Bug: does not make sense to allow empty domain name in LID (#434)
Bug: Inconsistent LID validation (#356)
Enh: option to reduce stats.lua output (#438)
Bug: Threading should take References header into account (#444)
##

With regards,
Daniel, on behalf of the Apache Pony Mail (incubating) team.



DISCLAIMER:
Apache Pony Mail (Incubating) is an effort undergoing incubation at The 
Apache Software Foundation (ASF), sponsored by the Apache Incubator. 
Incubation is required of all newly accepted projects until a further 
review indicates that the infrastructure, communications, and decision 
making process have stabilized in a manner consistent with other 
successful ASF projects. While incubation status is not necessarily a 
reflection of the completeness or stability of the code, it does 
indicate that the project has yet to be fully endorsed by the ASF.


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Recommend 'Apache NetBeans graduation to Top Level Project' resolution to board

[Daniel Gruno]

On 09/04/2019 15.00, Bertrand Delacretaz wrote:

On Tue, Apr 9, 2019 at 12:41 PM Geertjan Wielenga
 wrote:

...The Apache NetBeans podling community brings the resolution, after
discussion[1]...


Enthusiastic +1, with my NetBeans mentor hat on.


And me t, +1 with my mentor hat on!



-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[RESULT] [VOTE] Release Apache Pony Mail (incubating) 0.11

[Daniel Gruno]

On 3/14/19 10:34 AM, Daniel Gruno wrote:

Hi folks,
This is a vote to release 0.11 of Apache Pony Mail (incubating).
The vote passed on dev@ponymail with 5x +1 and no 0s or -1s.
Three binding IPMC +1s carry over in this vote (humbedooh, johndament, 
jleroux).


Since there were no additional votes cast, the result remain the same; 
vote passed with 5x+1 (3 binding +1s). I'll start prepping for the 
release/announcement as soon as possible.




Artifacts are available at:
https://dist.apache.org/repos/dist/dev/incubator/ponymail/

Specifically, this is a vote on the source in 
https://dist.apache.org/repos/dist/dev/incubator/ponymail/apache-pony-mail-0.11-incubating.tar.gz 



SHA256 for the artifact is:
0939a90112b95f393b8ca8f73e51540cf22a1629e046468c84689bad55999bf7

git tag for the release is: 8b00e7c8eabf01a68fc119d2ce58bfbfc3c3eea3 
(tagged as 0.11-rc)


Please vote accordingly, the vote will last 72 hours, ending Sunday 17th 
of March at 10AM UTC:



[ ] +1; Full steam ahead
[ ]  0; Meh, I don't care
[ ] -1; Don't release because... [insert reason]


With regards,
Daniel.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[VOTE] Release Apache Pony Mail (incubating) 0.11

[Daniel Gruno]

Hi folks,
This is a vote to release 0.11 of Apache Pony Mail (incubating).
The vote passed on dev@ponymail with 5x +1 and no 0s or -1s.
Three binding IPMC +1s carry over in this vote (humbedooh, johndament, 
jleroux).


Artifacts are available at:
https://dist.apache.org/repos/dist/dev/incubator/ponymail/

Specifically, this is a vote on the source in 
https://dist.apache.org/repos/dist/dev/incubator/ponymail/apache-pony-mail-0.11-incubating.tar.gz


SHA256 for the artifact is:
0939a90112b95f393b8ca8f73e51540cf22a1629e046468c84689bad55999bf7

git tag for the release is: 8b00e7c8eabf01a68fc119d2ce58bfbfc3c3eea3 
(tagged as 0.11-rc)


Please vote accordingly, the vote will last 72 hours, ending Sunday 17th 
of March at 10AM UTC:



[ ] +1; Full steam ahead
[ ]  0; Meh, I don't care
[ ] -1; Don't release because... [insert reason]


With regards,
Daniel.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Responsibilities and Improvements

[Daniel Gruno]

On 3/6/19 10:07 PM, Dmitriy Pavlov wrote:

Hi Daniel,

There are two independent questions here.

1) Removal question and its allowance in general:  this question asked
during every talk I gave related to ASF. My fellows ask me if someone can
remove Committer or PMCs. Some folks think it is possible by the vote of
PMC. They refer to docs I've shared: mnemonic project & incubator guide.


I'm not on the board, but if I was, I'd likely ask the same question 
again; what are you trying to solve by removing people? What is gained 
by removing people? I get that people may see a list of people with 30 
our of 40 being inactive as 'noisy', but removing the 30 isn't going to 
make the other 10 more active, nor is having inactive people a blocker 
for adding more to the list. That you have inactive people on the PMC 
is, plainly put, not a problem in itself, nor a blocker, catalyst or 
anything for whatever problems may exist. If the only reason is 
cosmetic, then that's likely not good enough a reason.


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check

[Daniel Gruno]

On 3/6/19 9:08 PM, Dmitriy Pavlov wrote:

Hi Ross,

Thank you for your reply. Apache Ignite PMCs do not support this idea, so
inactive PMCs will be still there.

But still, it is not clear for me in general, why following
projects/guidelines contains removal procedure for Committer PMC:
- https://mnemonic.apache.org/develop/bylaws/  after 6 months of inactivity
both PMC and Committer status may be removed.
- Default Incubator guidelines
https://wiki.apache.org/incubator/DefaultProjectGuidelines It contains
procedures of consensus-based removal, - it is ok to remove for Incubator?
is it ok for TLP?

If both PMC & Committer roles are merit-based, and merit does not expire,
how it even possible to remove TLP committer/PMC (excepting some extreme
cases)?

This question is not only mine, but it is also often asked and I would like
to know the answer.


Turn the question around; *why* are you looking to remove people? What 
is the problem you are trying to solve here? How will removing someone 
from the PMC/committer list help address the issues you are facing?




Sincerely,
Dmitriy Pavlov


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs check

[Daniel Gruno]

On 3/6/19 4:47 PM, Ross Gardler wrote:

Merit does not expire. People who are not active today should be able to become 
active tomorrow without having to jump through approval hoops.

In projects there is no concept of emeritus PMC. Here in the IPMC the issue is 
very different. Most people earn merit transitively - become a member, become a 
mentor, become an IPMC member. It's different.

Please don't use what is being discussed here as being transitive to a PMC 
based entirely on directly earned merit.


Or put differently; why would we care that someone is inactive on the 
IPMC? Are we short on bytes on the LDAP server and need to conserve 
space? ;). It should make no difference if there are inactive members of 
the IPMC or not.




Get Outlook for Android


From: Dmitriy Pavlov 
Sent: Tuesday, March 5, 2019 4:46:09 AM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy general@ subs 
check (was:  introduce "[DISCUSS]" threads for podling ... release 
candidates))

I absolutely agree with Greg Stein. I can't find any single reason to keep
unsubscribed members of IPMC in the roster. These members can be asked to
subscribe, and if they do, then ok; if don't - it is perfectly ok to remove.

Similarly, I don't see reasons for having inactive TLP PMC members. I've
suggested the same change in Apache Ignite, but I don't clearly understand
why remained members resisting this change.


пн, 4 мар. 2019 г. в 09:58, Ross Gardler :


That's right Greg. And since we are filling in gaps for people...

I was originally against the pTLP concept (though I supported the
experiments) or any of the derivatives that came from it. I think I have
changed my position. Largely based on the fact that every single project
I've discussed the ASF with in the last 3-5 years has had a very inaccurate
perception of how the ASF works. I believe a large part of this is due, in
part, to the issues being discussed in this thread.

I do not understand how a foundation which prides itself in having very
little bureaucratic red tape can be seen as having so much red tape. The
projects I talk to just want to build software. It used to be that the ASF
focused on running the legal and operational aspects of the foundation
projects and developers on projects wrote code. I'm not sure that's true
anymore.

We need to fix it.

I look forward to hearing how the IPMC will seek to strip down the
bureaucracy and get back to mentoring the incoming projects on how the ASF
is structured so they can get (relatively) quick and clear answers to their
questions.

Ross


From: Greg Stein 
Sent: Sunday, March 3, 2019 10:19 PM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Responsibilities and Improvements (was: Re: Whimsy
general@ subs check (was:  introduce "[DISCUSS]" threads for podling
... release candidates))

On Sun, Mar 3, 2019 at 10:37 PM Ross Gardler  wrote:


If a podling is a committee in its own right then it can be empowered to
act on behalf of the board and this its releases can be an act of the
foundation.

...



Podlings would only become full TLPs once they have demonstrated their
ability to do formal releases.



The above pair of concepts was offered in $priorCycle as "provisional TLPs"
(pTLP). I believe the idea ended when Sam pointed out that if a pTLP is
trusted, then why not just call it a TLP and trust it to label its releases
appropriately? Thus, just create TLPs immediately for a "podling"

[ I know Ross knows this; but for $others who may want to look at
historical proposals, and compare/contrast to current discussion ... search
for "pTLP" ]

Cheers,
-g

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org







-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [Cava] Suitable name search - choosing a name

[Daniel Gruno]

On 2/28/19 8:45 PM, Jim Jagielski wrote:

Hmm... in less than 20mins the request for Rainbow was shut down...

I'm not sure how I feel about this... The justification seems a real stretch to 
me:

 
https://issues.apache.org/jira/projects/PODLINGNAMESEARCH/issues/PODLINGNAMESEARCH-164?filter=allissues

It also seems to imply that usage of the name rainbow would somehow be offensive or 
insensitive. Again, I'm not sure how. Nor am I aware of situations where the LGBT+ 
community "has expressed concerns" about usage *of the name* Rainbow.


+1

Anyone could hypothetically be offended by anything, I could list a 
large number of theoretical offenses in project names. Let's please 
stick to *actual* feedback and not preemptively censor ourselves. If 
such feedback exists, fair enough, but I am also not aware of any such.




But, I guess another name needs to be found...
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Podlings not following ASF release policy

[Daniel Gruno]

On 2/9/19 9:38 AM, Makoto Yui wrote:

Justin,

Could you please tell us  what
issues exist in Hivemall?


I'd also be interested in knowing (you may use dev@ or private@ as you 
see fit) what issues exist with pony mail and release policies :)





Thanks,
Makoto

2019年2月9日(土) 9:51 Justin Mclean :


Hi,

So I just checked the next bunch of podlings to report to see if we have any 
other issues with ASF releases policy and sadly we do and again it larger than 
I expected. Some of these are minor issues and easily fixed, some are not. In a 
couple of cases I may not of looked deeply enough into the issue and it may 
actually be fine, if so apologies in advance for listing you here. In a couple 
of cases (e.g. Zipkin) I can see it’s been discussed on the list but there’s 
more to do.

Podlings having one or more issues with ASF release policy include:
- Crail
- Daffodil
- Dlab
- Druid
- Dubbo
- Hivemall
- Marvin-ai
- Memo
- Omid
- Openwhisk
- Pinot
- Ponymail
- Singa
- Skywalking
- Zipkin

Projects that I will be following up with include Dlab, Druid, Dubbo, 
Openwhisk, Singa, Skywalking and Zipkin.

If you are the mentors of these projects please take a look and see what you 
can do to improve the situation and educate your podling on proper release 
policy. If you can’t find the issue ping me and I’ll send an email with what I 
think it is to your private list. There is probably things I’ve missed as well, 
often were there’s one issue there’s others.

Please include something in the next podling report on this.

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org







-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Podlings not following ASF release policy

[Daniel Gruno]

On 2/9/19 8:50 AM, Justin Mclean wrote:

HI,


 From what I can see with httpd, the issue is the same(?)


Not quite as I not see any release candidates listed.


ah, well, httpd doesn't do release candidates :p we tag a release, vote 
on it, if it fails, you burn the version number and use a new one. so 
you'll see release "candidates" but just not recognize them unless you 
know which versions failed to get the proper votes.




Thanks,
Justin

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Podlings not following ASF release policy

[Daniel Gruno]

On 2/9/19 8:37 AM, Justin Mclean wrote:

Hi,


IMO either way it should be ok because


It’s not OK as it doesn’t agree with ASF release policy. You can’t provide 
release candidates to the general public and call them releases.

I do see that several ASF projects seem to avoid this issue but I’m not sure 
how they do it. (See for instance the httpd project) [1]


From what I can see with httpd, the issue is the same(?) - GitHub 
interprets a tag as a release at the time of tagging, not the time of 
releasing (github "released" 2.4.38 21 days ago, ASF released it 19 days 
ago). Short of going in and removing the tag, there's little we can do, 
it's just a bad hardcoded feature that GitHub has.




Thanks,
Justin

1. https://github.com/apache/httpd/releases
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Apache Unomi to TLP

[Daniel Gruno]

+1 - still in brussels, so lagging behind on email :)

On 04/02/2019 11.10, Serge Huber wrote:

Hello Daniel,

I'd like to close the vote soon but as you voted -1 because of the
lack of PNS we need your new vote.

For your information, here's the completed and accepted PNS [1].

Best regards,
   Serge Huber.

[1] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-161

On Tue, Jan 22, 2019 at 3:12 PM Daniel Gruno  wrote:


On 1/22/19 3:09 PM, Mark Thomas wrote:

On 22/01/2019 00:37, Greg Stein wrote:

On Mon, Jan 21, 2019 at 3:21 PM Dave Fisher  wrote:


   -0 (binding) - This podling has never completed a suitable podling name
search. It seems that people no longer consider that relevant as it is not
in the Maturity model and I’m not sure why. It could be because that is
ComDev and not the IPMC.



The "Maturity Model" (MM) is just a thing developed by ComDev peeps. It has
no bearing within the Foundation, other than as a lens for individuals to
view projects. That lens is not part of the Incubator, or any other PMC.

Personally, I do not view the "podling name search" (PNS) as a gate. That
is another imposition, from outside the Incubator, that has crept into the
"Must Be Performed(tm)" guidelines for graduation. The Board is the
ultimate arbiter of whether a podling can graduate, and a name search is
informative for them, rather than gating for us [on the IPMC]. If a podling
wants to be called "Apache Acme", and "gee, there are a lot of Acme
products out there", then that is on the community. Not something for the
Incubator to demand they change; just something for them to deal with. A
community problem, rather than one for the Incubator or the Foundation
itself.


I disagree on that point - as VP Brand I would, wouldn't I ;)

If there is an issue with the name (that the PNS would have uncovered)
then the likely solution is that the (now graduated) project will have
to rename. That has a cost for both the community and the foundation.

While in some cases there are clearly no conflicts, in others it is not
quite so clear cut. The aim of the PNS is to enable both the podling and
the foundation (delegated to the Branding Committee) to decide if the
choice of name is acceptable given the degree of risk associated with
any potential conflict and the associated costs of a rename should that
risk materialise.

(There is an assumption here that early renames result in lower costs
for both the community and the foundation).

As VP Brand I am likely recommend against a podling graduating without a
PNS on the basis that it represents an unknown level of risk. The board
may approve the resolution anyway but I suspect it would be tabled
(delayed) until the following meeting to allow a PNS or something along
those lines to take place.

As an aside, the policy docs still say a PNS is required to graduate. If
this view has changed (I'm not sure it has - I don't recall a
discussion) then those docs need updating.


I haven't heard of any policy change either, and with that in mind, I am
-1 (binding) on graduation till a PNS has been resolved. As Mark stated,
there are costs involved with name changes, on multiple fronts, and
making sure that we don't clash is quite important.

With that said, there is plenty of time till the next board meeting, a
PNS _could_ be done in time for that, and I'd remove my -1. :)



Mark

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org



-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [IPMC] What to do with retired podling repositories

[Daniel Gruno]

Just a note from infra that we'll need a decision from the IPMC on this 
matter no later than February 7th, preferably before :)


With regards,
Daniel.

On 1/13/19 10:14 AM, Daniel Gruno wrote:

Hello IPMC and other folks,

We have a big bunch of retired podlings with git repositories on 
git-wip-us. As we are working on retiring this service, we need to 
address what happens with these old project repositories.


The retired podlings we need to address are:
blur, cmda, concerted, corinthia, cotton, gearpump, gossip, hdt, horn, 
htrace, iota, mrql, openaz, pirk, provisionr, quickstep, ripple, s4, 
slider, wave


Before February 7th, we at ASF Infra, would love if the incubator could 
decide what happens to these repositories, either individually or as a 
whole.


Some suggested options are:

1) delete the repositories
2) rename them to incubator-retired-$foo.git
3) Do nothing, but put a note on github etc that they retired.
4) punt it to the attic if possible (you'd have to coordinate with the 
Attic PMC then)

5) Something else??

Please talk among yourselves and let Infra know :)

With regards,
Daniel on behalf of ASF Infra.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Apache Unomi to TLP

[Daniel Gruno]

On 1/22/19 3:09 PM, Mark Thomas wrote:

On 22/01/2019 00:37, Greg Stein wrote:

On Mon, Jan 21, 2019 at 3:21 PM Dave Fisher  wrote:


  -0 (binding) - This podling has never completed a suitable podling name
search. It seems that people no longer consider that relevant as it is not
in the Maturity model and I’m not sure why. It could be because that is
ComDev and not the IPMC.



The "Maturity Model" (MM) is just a thing developed by ComDev peeps. It has
no bearing within the Foundation, other than as a lens for individuals to
view projects. That lens is not part of the Incubator, or any other PMC.

Personally, I do not view the "podling name search" (PNS) as a gate. That
is another imposition, from outside the Incubator, that has crept into the
"Must Be Performed(tm)" guidelines for graduation. The Board is the
ultimate arbiter of whether a podling can graduate, and a name search is
informative for them, rather than gating for us [on the IPMC]. If a podling
wants to be called "Apache Acme", and "gee, there are a lot of Acme
products out there", then that is on the community. Not something for the
Incubator to demand they change; just something for them to deal with. A
community problem, rather than one for the Incubator or the Foundation
itself.


I disagree on that point - as VP Brand I would, wouldn't I ;)

If there is an issue with the name (that the PNS would have uncovered)
then the likely solution is that the (now graduated) project will have
to rename. That has a cost for both the community and the foundation.

While in some cases there are clearly no conflicts, in others it is not
quite so clear cut. The aim of the PNS is to enable both the podling and
the foundation (delegated to the Branding Committee) to decide if the
choice of name is acceptable given the degree of risk associated with
any potential conflict and the associated costs of a rename should that
risk materialise.

(There is an assumption here that early renames result in lower costs
for both the community and the foundation).

As VP Brand I am likely recommend against a podling graduating without a
PNS on the basis that it represents an unknown level of risk. The board
may approve the resolution anyway but I suspect it would be tabled
(delayed) until the following meeting to allow a PNS or something along
those lines to take place.

As an aside, the policy docs still say a PNS is required to graduate. If
this view has changed (I'm not sure it has - I don't recall a
discussion) then those docs need updating.


I haven't heard of any policy change either, and with that in mind, I am 
-1 (binding) on graduation till a PNS has been resolved. As Mark stated, 
there are costs involved with name changes, on multiple fronts, and 
making sure that we don't clash is quite important.


With that said, there is plenty of time till the next board meeting, a 
PNS _could_ be done in time for that, and I'd remove my -1. :)




Mark

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [IPMC] What to do with retired podling repositories

[Daniel Gruno]

On 1/14/19 12:12 PM, Sharan F wrote:

Hi Greg

You have a good point and my need is a more of a personal one (rather 
than an IPMC one) so if delete is the consensus,  then go for it. I 
won't hold it up.


If you are doing research on them, and you are (presumably) using Kibble 
there, you could just make sure they are scraped before they are 
deleted, and you should be fine.




Thanks
Sharan


On Mon, 14 Jan 2019, 11:25 Greg Stein <mailto:gst...@gmail.com> wrote:


If they didn't graduate, then they aren't Apache projects. So as
Myrle says, "what are they doing on our servers?" For the retired
podlings, our copy of their code could be misleading, relative to
where it came from, or where the community may have newly forked it.

Not an Infra opinion,
-g


On Mon, Jan 14, 2019 at 12:12 AM Myrle Krantz mailto:my...@apache.org>> wrote:

If we can’t name a reason for keeping the data, I’d be inclined
to just
delete.  We are not data squirrels.

: o),
Myrle

On Sun, Jan 13, 2019 at 10:15 AM Daniel Gruno
mailto:humbed...@apache.org>> wrote:

 > Hello IPMC and other folks,
 >
 > We have a big bunch of retired podlings with git repositories on
 > git-wip-us. As we are working on retiring this service, we
need to
 > address what happens with these old project repositories.
 >
 > The retired podlings we need to address are:
 > blur, cmda, concerted, corinthia, cotton, gearpump, gossip,
hdt, horn,
 > htrace, iota, mrql, openaz, pirk, provisionr, quickstep,
ripple, s4,
 > slider, wave
 >
 > Before February 7th, we at ASF Infra, would love if the
incubator could
 > decide what happens to these repositories, either
individually or as a
 > whole.
 >
 > Some suggested options are:
 >
 > 1) delete the repositories
 > 2) rename them to incubator-retired-$foo.git
 > 3) Do nothing, but put a note on github etc that they retired.
 > 4) punt it to the attic if possible (you'd have to coordinate
with the
 > Attic PMC then)
 > 5) Something else??
 >
 > Please talk among yourselves and let Infra know :)
 >
 > With regards,
 > Daniel on behalf of ASF Infra.
 >
 >
-
 > To unsubscribe, e-mail:
general-unsubscr...@incubator.apache.org
<mailto:general-unsubscr...@incubator.apache.org>
 > For additional commands, e-mail:
general-h...@incubator.apache.org
<mailto:general-h...@incubator.apache.org>
 >
 >




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[IPMC] What to do with retired podling repositories

[Daniel Gruno]

Hello IPMC and other folks,

We have a big bunch of retired podlings with git repositories on 
git-wip-us. As we are working on retiring this service, we need to 
address what happens with these old project repositories.


The retired podlings we need to address are:
blur, cmda, concerted, corinthia, cotton, gearpump, gossip, hdt, horn, 
htrace, iota, mrql, openaz, pirk, provisionr, quickstep, ripple, s4, 
slider, wave


Before February 7th, we at ASF Infra, would love if the incubator could 
decide what happens to these repositories, either individually or as a 
whole.


Some suggested options are:

1) delete the repositories
2) rename them to incubator-retired-$foo.git
3) Do nothing, but put a note on github etc that they retired.
4) punt it to the attic if possible (you'd have to coordinate with the 
Attic PMC then)

5) Something else??

Please talk among yourselves and let Infra know :)

With regards,
Daniel on behalf of ASF Infra.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Feedback requested: New committer invitation template

[Daniel Gruno]

On 12/30/18 6:41 PM, Matt Sicker wrote:

I like this template suggestion. It may also be helpful to note that the
Apache ids must be letters and numbers only as some people request special
characters in their ids.


Not to toot my own horn too much, but we also have 
https://asf.icla.online/ which simplifies the print-type-sign-scan-email 
routine for Apache ICLAs (and does verify that user ID is both available 
and matches our syntax). Could be an idea to point to that for easy ICLA 
work :)





On Sun, Dec 30, 2018 at 09:24, Craig Russell  wrote:


Hi Hugo,

The intent is for the PMC member sending the invitation to do the check
before sending the mail and edit the mail so the candidate only sees the
appropriate option.

I'll try to make this more clear in the instructions on the page that
contains the sample email. [I originally had three different sample emails
but they were all the same except for the paragraph B.]

Thanks for the feedback.

Craig


On Dec 29, 2018, at 9:32 PM, Hugo Louro  wrote:

Hi Craig,

+1 for the overall proposal. There is only one thing that I would like

to clarify. Do you plan to have a custom email for each of the three cases
(already have an Apache id, already filed an ICLA, and have not filed an
ICLA), and research ahead of time to which case the person applies, or have
an email that covers all the cases. If the later, my suggestion is that the
email should clearly direct the recipient to choose specifically the case
that applies to her/himself. I mean, have written something along the
lines: If you already have an Apache is, follow these instructions, if
already filed an ICLA follow these other instructions, otherwise follow
this instead.


Thanks,
Hugo


On Dec 29, 2018, at 3:29 PM, Craig Russell 

wrote:


Hi,

In order to simplify the process of granting new committers write

access to a project's repository, I'd like to propose a change in the
invitation letter sent to candidates after the PMC has voted to accept them
as committers.


The original is at

https://community.apache.org/newcommitter.html#committer-invite-template


It does not distinguish among these three cases: already have an Apache

id, already filed an ICLA, and have not filed an ICLA. There are many cases
where unnecessary work is done because of improper guidance.



To: joeblo...@foo.net
Cc: private@[PROJECT].apache.org
Subject: Invitation to become [PROJECT] committer: Joe Bloggs

Hello [invitee name],

The [Project] Project Management Committee] (PMC)
hereby offers you committer privileges to the project
[as well as membership in the PMC]. These privileges are
offered on the understanding that you'll use them
reasonably and with common sense. We like to work on trust
rather than unnecessary constraints.

Being a committer enables you to more easily make
changes without needing to go through the patch
submission process. [Being a PMC member enables you
to guide the direction of the project.]

Being a committer does not require you to
participate any more than you already do. It does
tend to make one even more committed.  You will
probably find that you spend more time here.

Of course, you can decline and instead remain as a
contributor, participating as you do now.

A. This personal invitation is a chance for you to
accept or decline in private.  Either way, please
let us know in reply to the [priv...@project.apache.org]
address only.

[check http://people.apache.org/committer-index.html]
[B. If you accept, since you already have an Apache id,
the PMC will grant you write access to the repository.
]

[check http://people.apache.org/unlistedclas.html]
[B. If you accept, since you already have an iCLA on file,
the PMC will request an Apache id for you. In your response,
please choose an id that is not already in use. See
http://people.apache.org/committer-index.html
]

[B. If you accept, the next step is to register an iCLA:
   1. Details of the iCLA and the forms are found
   through this link: http://www.apache.org/licenses/#clas

   2. Instructions for its completion and return to
   the Secretary of the ASF are found at
   http://www.apache.org/licenses/#submitting
   Do not submit ICLAs to anyone but secretary, but
   please do cc: [priv...@project.apache.org]

   3. When you transmit the completed iCLA, request
   to notify the Apache [Project] and choose a
   unique Apache id. Look to see if your preferred
   id is already taken at
   http://people.apache.org/committer-index.html
   This will allow the Secretary to notify the PMC
   when your iCLA has been recorded.
]

When your reply to this invitation is received, you will
receive a follow-up message with the next steps for
establishing you as a committer.

Craig L Russell
Secretary, Apache Software Foundation
c...@apache.org http://db.apache.org/jdo


-
To unsubscribe, e-mail: 

Re: Request incubator wiki admin access

[Daniel Gruno]

On 12/27/18 6:22 PM, Myrle Krantz wrote:

Sorry, forgot to say that: myrle


You should be good to go now :)



On Thu, Dec 27, 2018 at 3:52 PM Daniel Gruno  wrote:


On 12/27/18 3:44 PM, Myrle Krantz wrote:

I'd like to be able to give users from the project I'm mentoring write
access.

Best Regards,
Myrle



What's your 8exact) wiki username?

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org







-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Request incubator wiki admin access

[Daniel Gruno]

On 12/27/18 3:44 PM, Myrle Krantz wrote:

I'd like to be able to give users from the project I'm mentoring write
access.

Best Regards,
Myrle



What's your 8exact) wiki username?

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[NOTICE] Mandatory relocation of Apache git repositories on git-wip-us.apache.org

[Daniel Gruno]

[IF YOUR PROJECT DOES NOT HAVE GIT REPOSITORIES ON GIT-WIP-US PLEASE
 DISREGARD THIS EMAIL; IT WAS MASS-MAILED TO ALL APACHE PROJECTS]

Hello Apache projects,

I am writing to you because you may have git repositories on the
git-wip-us server, which is slated to be decommissioned in the coming
months. All repositories will be moved to the new gitbox service which
includes direct write access on github as well as the standard ASF
commit access via gitbox.apache.org.

## Why this move? ##
The move comes as a result of retiring the git-wip service, as the
hardware it runs on is longing for retirement. In lieu of this, we
have decided to consolidate the two services (git-wip and gitbox), to
ease the management of our repository systems and future-proof the
underlying hardware. The move is fully automated, and ideally, nothing
will change in your workflow other than added features and access to
GitHub.

## Timeframe for relocation ##
Initially, we are asking that projects voluntarily request to move
their repositories to gitbox, hence this email. The voluntary
timeframe is between now and January 9th 2019, during which projects
are free to either move over to gitbox or stay put on git-wip. After
this phase, we will be requiring the remaining projects to move within
one month, after which we will move the remaining projects over.

To have your project moved in this initial phase, you will need:

- Consensus in the project (documented via the mailing list)
- File a JIRA ticket with INFRA to voluntarily move your project repos
  over to gitbox (as stated, this is highly automated and will take
  between a minute and an hour, depending on the size and number of
  your repositories)

To sum up the preliminary timeline;

- December 9th 2018 -> January 9th 2019: Voluntary (coordinated)
  relocation
- January 9th -> February 6th: Mandated (coordinated) relocation
- February 7th: All remaining repositories are mass migrated.

This timeline may change to accommodate various scenarios.

## Using GitHub with ASF repositories ##
When your project has moved, you are free to use either the ASF
repository system (gitbox.apache.org) OR GitHub for your development
and code pushes. To be able to use GitHub, please follow the primer
at: https://reference.apache.org/committer/github


We appreciate your understanding of this issue, and hope that your
project can coordinate voluntarily moving your repositories in a
timely manner.

All settings, such as commit mail targets, issue linking, PR
notification schemes etc will automatically be migrated to gitbox as
well.

With regards, Daniel on behalf of ASF Infra.

PS:For inquiries, please reply to us...@infra.apache.org, not your 
project's dev list :-).




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Graduate Apache SkyWalking (incubating) as a TLP

[Daniel Gruno]

On 30/10/2018 05.19,  Sheng Wu wrote:

Hi Justin

- The podling roster lists both PPMC and committers [1], including people not 
on the initial list [2], but I??m unable to find any discussion or votes to why 
they were added.


I only see one person not on the initial list, and I found the vote for 
them, I think that's fine.


I am curious and a tad concerned about community growth in the project; 
you list that you have developers from 13 different companies, yet there 
are not that many committers/PPMC members in total, so why bring up the 
list of affiliations here? And why have you only voted in one new person 
(that I can find) as a committer/PPMC?


One of the main reasons we ask for diversity is because it matters in 
the decision making process, so if you're going to bring up this as a 
positive, I'd very much like to see it being actualized in form of more 
committers/PPMC members, before the project considers graduation. Having 
seemingly only invited one new person does not speak towards a diverse 
governance and inclusion. That is not to say it's impermissible as a 
TLP, but it is something that you should work on and demonstrate being 
adept at as a TLP, and thus as a podling seeking graduation as well.


I would love to see Skywalking hold off their graduation a little, and 
working towards demonstrating proper community growth where it matters. 
As for many of the other required aspects, I think you're mostly there :)


With regards,
Daniel.



Who is not in the initial list? They all are. Except Ignasi is our new mentors 
in incubating stage. And discussion happened. Do you mean him? We didn't add 
anyone without voting.



Sheng Wu
Apache SkyWalking

 From Wu Sheng 's phone.


-- Original --
From:  Sheng Wu 
Date: Tue,Oct 30,2018 6:06 PM
To: general 
Subject: Re:  [DISCUSS] Graduate Apache SkyWalking (incubating) as a TLP



Hi Justin


 From my personal perspective, I have some answers from the status I known.



- There still doesn??t seem to be a lot of discussion on the development list.

SkyWalking discussion shows up in GitHub issues according to our 
developers/contributors habits. They are tagged as question, bug, enhancement 
etc. based on the content. As we mentioned, 240+ Issues tagged as question[4] 
in GitHub created, 236 resolved.


- The initial PMC list doesn??t include all fo the current PPMC and committers 
on the roster (and I cannot see any discussion about this).
This has been proposed in discussion[1] ml, specific this one[2]



- A search of the private list show only one PPMC added past the initial 
commuter list and they were added without NOTICE being sent (and only corrected 
when I pointed it out).

Yes, that is correct. The community decided to accept him. But number of 
contributors grows well, from less than 20 to near 70 just in main repo.



- The podling roster lists both PPMC and committers [1], including people not 
on the initial list [2], but I??m unable to find any discussion or votes to why 
they were added.

That is because SkyWalking has the community, and its PMC and committer teams 
before join the incubator[3]. We keep that as same as before, in order to avoid 
more concerns.



- Has a software grant been received or IP clearance happened?

The SGA is not required from my understanding. This project is my personal 
project, and then belong to OpenSkywalking org which is just a virtual org in 
GitHub.


[1] 
https://lists.apache.org/thread.html/4ee8894c99275ee0f14fcdb250a66ef9d22a7ba87742fa613897849f@%3Cdev.skywalking.apache.org%3E
[2] 
https://lists.apache.org/thread.html/eb4f1c68ad475ce36456f248af6f7fabc1e6b3d4cb6de5d9d7d41063@%3Cdev.skywalking.apache.org%3E
[3] https://github.com/OpenSkywalking/Organization#organization-members
[4] 
https://github.com/apache/incubator-skywalking/issues?utf8=%E2%9C%93=is%3Aissue+label%3Aquestion+


--
Sheng Wu
Apache SkyWalking


  





-- Original --
From:  "justin";
Date:  Tue, Oct 30, 2018 05:41 PM
To:  "general";

Subject:  Re: [DISCUSS] Graduate Apache SkyWalking (incubating) as a TLP



Hi,

I think that perhaps that SkyWalking may need to stay a little longer in the 
incubator as:
- There still doesn??t seem to be a lot of discussion on the development list.
- The initial PMC list doesn??t include all fo the current PPMC and committers 
on the roster (and I cannot see any discussion about this).
- A search of the private list show only one PPMC added past the initial 
commuter list and they were added without NOTICE being sent (and only corrected 
when I pointed it out).
- The podling roster lists both PPMC and committers [1], including people not 
on the initial list [2], but I??m unable to find any discussion or votes to why 
they were added.
- Has a software grant been received or IP clearance happened?

Now I could be mistaken in the above, not searched deeply enough or there??s a 
perfectly good reason for 

Re: Getting through the hoops

[Daniel Gruno]

On 10/18/2018 08:59 PM, Matt Sicker wrote:

Finding the project for an ICLA isn't too hard provided the person's name
was mentioned in the mailing list recently. Finding the userid for someone
new, however, does require them to tell us ahead of time.


Mhmm, that's why I made it mandatory on icla.live, and also check 
against existing user IDs. It's not perfect (someone can still be stupid 
and insist on 'webmaster'), but it's better than before :)


On that note, I think I'm done for now with that site. Use it for 
projects if y'all want to :)




On Tue, 16 Oct 2018 at 09:31, Dave Fisher  wrote:


Hi -

Sent from my iPhone


On Oct 16, 2018, at 1:25 AM, Serge Huber  wrote:


Actually I think there is a lot of documentation and in itself it can be

a bit daunting. Also for the committer request, it would be great if it
could be streamlined by doing some kind of online form but there is the
question of the digital signature that might be an issue.


Also, some of the optional fields such as the Apache ID or the project

name should maybe be explained as less than optional. I’ve had the problem
recently that committers filled the ICLA without the optional fields, and
then the secretary asked for the ID and the project name. So this is
putting additional work on the secretary which could be avoided.


In other words, it’s not that hard when you know the process, but when

you’re learning it and want to do the right thing by not bothering mentors
for everything, I think it is less straightforward than setting up an
account on Github, which I think is what a lot of people are comparing the
experience too (at least that’s the feedback I get usually).

Your Mentors are the ones who need to update the roster in Whimsy. It used
to be only the VP Incubator.

If a Mentor is not helping drive onboarding then they aren’t engaged.

Regards,
Dave



Regards,
  Serge…


On 16 Oct 2018, at 10:06, Bertrand Delacretaz <

bdelacre...@codeconsult.ch> wrote:


Hi,


On Mon, Oct 15, 2018 at 7:29 PM Benjamin Young 

wrote:

...I've continued to reach out to other initial committers to get them

through the

hoops here at Apache--which took  a few weeks of setup,

reading, etc...

Mostly, I think folks find the process daunting. :-/...


I'm curious what's so hard, maybe we aren't explaining things properly?

IMO an initial or elected committer needs to choose an Apache ID,
register their iCLA, wait for their account to be created, sign up to
their project's dev (and maybe private) list and they're in business.
Ok, for now they also need to create accounts on Jira and Confluence
if the project uses that.

Is this what's considered too hard, or did I miss something?

-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org







-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Getting through the hoops

[Daniel Gruno]

On 10/16/2018 02:43 PM, Bertrand Delacretaz wrote:

On Tue, Oct 16, 2018 at 1:27 PM Daniel Gruno  wrote:
...

https://icla.live/

...

I love it! With a few comments ;-)

We should be very clear about which information is required or not, I
don't think we really need a phone number for example - it should be
clear what's the minimal required information.


I don't personally know which fields are required and which are merely 
optional, so I'm CCing secretary@ on this one. If we could get sojme 
clarity, I can improve the form a bunch.




I'd prefer a form with all fields on the same page, otherwise I'm
always wondering how many "next steps" there are ;-)


I could, of course say "step N/10" on the various pages for starters :)



Just nitpicks really, I think this is a big improvement, thanks Daniel!

-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Getting through the hoops

[Daniel Gruno]

I should note that this only generates a PDF, it doesn't send it - so 
test all you like!


On 10/16/2018 01:26 PM, Daniel Gruno wrote:

So, I took a stab at this, Work-In-Progress and what not:

https://icla.live/

Feedback is most welcome!

With regards,
Daniel.

On 10/16/2018 10:56 AM, Serge Huber wrote:
Indeed that would be really nice, and we could imagine a form that 
would give people through the process, and also sent expectations in 
terms of what happens next and how much time it might take.


Regards,
   Serge…

On 16 Oct 2018, at 10:33, Bertrand Delacretaz 
 wrote:


On Tue, Oct 16, 2018 at 10:29 AM Daniel Gruno  
wrote:

...Thinking out loud here...what if we made a form that better explains
things and checks if the userid is available etc, and then it generates
a PDF to review/sign with all the fields filled out?...


That would be fantastic - onboarding instructions that consist of a
single persistent URL are a Good Thing!

-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Getting through the hoops

[Daniel Gruno]

So, I took a stab at this, Work-In-Progress and what not:

https://icla.live/

Feedback is most welcome!

With regards,
Daniel.

On 10/16/2018 10:56 AM, Serge Huber wrote:

Indeed that would be really nice, and we could imagine a form that would give 
people through the process, and also sent expectations in terms of what happens 
next and how much time it might take.

Regards,
   Serge…


On 16 Oct 2018, at 10:33, Bertrand Delacretaz  
wrote:

On Tue, Oct 16, 2018 at 10:29 AM Daniel Gruno  wrote:

...Thinking out loud here...what if we made a form that better explains
things and checks if the userid is available etc, and then it generates
a PDF to review/sign with all the fields filled out?...


That would be fantastic - onboarding instructions that consist of a
single persistent URL are a Good Thing!

-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Getting through the hoops

[Daniel Gruno]

On 10/16/2018 10:25 AM, Serge Huber wrote:


Actually I think there is a lot of documentation and in itself it can be a bit 
daunting. Also for the committer request, it would be great if it could be 
streamlined by doing some kind of online form but there is the question of the 
digital signature that might be an issue.


Thinking out loud here...what if we made a form that better explains 
things and checks if the userid is available etc, and then it generates 
a PDF to review/sign with all the fields filled out?




Also, some of the optional fields such as the Apache ID or the project name 
should maybe be explained as less than optional. I’ve had the problem recently 
that committers filled the ICLA without the optional fields, and then the 
secretary asked for the ID and the project name. So this is putting additional 
work on the secretary which could be avoided.

In other words, it’s not that hard when you know the process, but when you’re 
learning it and want to do the right thing by not bothering mentors for 
everything, I think it is less straightforward than setting up an account on 
Github, which I think is what a lot of people are comparing the experience too 
(at least that’s the feedback I get usually).

Regards,
   Serge…


On 16 Oct 2018, at 10:06, Bertrand Delacretaz  
wrote:

Hi,

On Mon, Oct 15, 2018 at 7:29 PM Benjamin Young  wrote:

...I've continued to reach out to other initial committers to get them through 
the
hoops here at Apache--which took  a few weeks of setup, reading, 
etc...
Mostly, I think folks find the process daunting. :-/...


I'm curious what's so hard, maybe we aren't explaining things properly?

IMO an initial or elected committer needs to choose an Apache ID,
register their iCLA, wait for their account to be created, sign up to
their project's dev (and maybe private) list and they're in business.
Ok, for now they also need to create accounts on Jira and Confluence
if the project uses that.

Is this what's considered too hard, or did I miss something?

-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[DELAYED ANNOUNCE] Apache Pony Mail (incubating) 0.10 released

[Daniel Gruno]

Since the original message must have gotten lost somewhere (I can't find 
it in the archives :( ), I am re-sending:


Hi folks,
We are pleased to announce the availability of Apache Pony Mail 
(incubating) 0.10. This release brings about more than 150 fixes and 
improvements to the Pony Mail project, as well as a fix for 
CVE-2017-5658. For a full list of changes, please see 
https://github.com/apache/incubator-ponymail/blob/master/CHANGELOG.md


For download options, please visit http://ponymail.apache.org/downloads.html

Further information on CVE-2017-5658 will follow.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Email to be sent to inactive mentors

[Daniel Gruno]

On 09/09/2018 11:33 AM, Justin Mclean wrote:

HI,


There seems to be a bit of confusion here. I am not a mentor for Annotator, yet 
I am listed as one.


You listed as one here. [1]

It get it’s info (I believe) from the podling.xml files which has this in it 
for Annotator:
 
 Nick Kew
 Brian McCallister
 Daniel Gruno
 Jim Jagielski
 

Is that information perhaps out of date or incorrect? You are also listed as 
the champion.
Daniel Gruno


I did champion it (and offer advice/help on occasion), but AIUI the champion's 
duties officially stop once the project has entered incubation and gotten set 
up.


They can be the case, but some champions also continue on as mentors.

I take it from that that you would like to be removed as a mentor and not sent 
the email?


I honestly don't have the time to mentor them in an official capacity - 
if I'm listed as anything but champion, then yes, remove me as a mentor. 
I'll continue in a low-capacity to provide help when I can, but I have 
other priorities first and foremost :)




Thanks,
Justin

1. https://whimsy.apache.org/roster/ppmc/annotator


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Email to be sent to inactive mentors

[Daniel Gruno]

There seems to be a bit of confusion here. I am not a mentor for 
Annotator, yet I am listed as one. I did champion it (and offer 
advice/help on occasion), but AIUI the champion's duties officially stop 
once the project has entered incubation and gotten set up. If this is 
not the case, then our policies should be updated to reflect this, as it 
seems wrong to assume duties we did not explicitly ask people to take on.


With regards,
Daniel.

On 09/09/2018 11:14 AM, Justin Mclean wrote:

Hi,


Perhaps add some recognition in the text of the email that there may
be activity that we are unaware of? (Unlikely, but it seems rude to
presume.)


I guess it’s possible you can mentor by just watching and only directing were 
needed, so if everything going well there may be no need for any interaction. 
People can use different email address or names online and could of been missed 
when I searched the email lists. So yes if possible one or two people may be 
incorrectly sent this email.

I’ll add:

Of course it may be that we've got it wrong for one reason or another and you 
are actually active, if that’s the case apologies in advance, and we’re happy 
for you to continue as a mentor of your podling(s).


I strongly support your efforts to hold mentors accountable. Thanks
for doing it, Justin!


Thanks. I think it’s got to the point were some action needs to be taken, 
rather than keep discussing it :-)

Thanks,
Justin
-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Warble into the Apache Incubator

[Daniel Gruno]

+1 (binding) once more :)

With regards,
Daniel.

On 06/08/2018 09:43 AM, Chris Thistlethwaite wrote:

Hi All (again),

I'd like to start a vote on accepting Warble into the Apache Incubator.

https://lists.apache.org/thread.html/1d62a2948d047cea38e6f01f92d5f138f8
3acd2c9d86349023fb28e4@%3Cgeneral.incubator.apache.org%3E

The ASF voting rules are described:

https://www.apache.org/foundation/voting.html

A vote for accepting a new Apache Incubator podling is a majority vote
for which only Incubator PMC member votes are binding.

This vote will run for at least 72 hours. Please VOTE as follows
[ ] +1 Accept Warble into the Apache Incubator
[ ] +0 Abstain.
[ ] -1 Do not accept Warble into the Incubator

The proposal is listed below, but you can also access it on the wiki:
https://wiki.apache.org/incubator/WarbleProposal


Thank you,
Chris T.



= Apache Warble Proposal =

== Abstract ==

 Apache Warble is a distributed endpoint monitoring solution where
 the agent is hosted on your own hardware. The aim of Warble is to
 produce a more balanced and less binary view of services and
 systems, lowering the rates of false positives while also providing
 greater insight into possible peering issues and proactive trend
 analysis.
  
==Proposal ==
  
 The goal of Warble will be to bring internal control of

 distributed monitoring back to the end user. Warble can be used as
 an independent service running on your own infrastructure
 monitoring other services in your infrastructure.
  
== Background and Rationale ==
  
 The beginning of this project was prompted by the service

 pingmybox.com (PMB) going end of life. This brought up
 conversation about FOSS services that can monitor internal and
 external services. PMB offered a unique code base to build this
 service upon a known infrastructure.
  
===Initial Goals ===


 Bring PMB code into the ASF, refactor the client/server into
 a more reusable structure. Further reuse of code gives us the a
 great starting point to build a starting point.
  
==Current Status ==
  
 The software exists as a proprietary service. We wish to convert

 this to a FLOSS solution.
  
==Meritocracy ==
  
 The initial PMC list covers new folks coming into the ASF.
 
==Community ==
  
 There exists a large user-base of software like Warble, as well

 as existing users of the old propietary service. It is our hope
 that we can convert a great deal of these to contributors and
 testers for the new open source product.
  
==Core Developers ==
  
 The initial set of developers are a lot of newcomers:


 * Daniel Gruno 
 * Chris Thistlethwaite 
 * Haig Didizian 
 * Andrew Karetas 
 * Chandler Claxton 
 * Luke Stevens 
 * Mike Andescavage 
 * Chris Lambertus 
  
==Known Risks ==
 
 There are many existing services that provide external

 monitoring. They are well established and have large user bases.
  
===Orphaned Products ===
  
 The initial PMC has great interest in open source projects, though

 no formal projects have been run.
  
  
===Inexperience with Open Source ===
  
 Most of the initial PPMC members are new to the ASF and some are

 new to open source projects. However, all are very interested in
 giving back to the community and projects.  Having said that, there
 are several people involved with extensive experience in the
 Apache Way and our procedures and processes.
  
===Homogenous Developers ===
  
 The initial set of developers are employed by a variety of

 companies, located across the world, and used to working on a
 variety of distributed projects.
  
===Reliance on Salaried Developers ===
  
 We do not expect the interest of the proposed initial PMC to be

 directly tied to current employment, but will actively seek to
 grow our volunteer base regardless.
  
===Relationships with Other Apache Products ===
  
 Not much to say here. Many ASF projects make use of the proprietary

 offering, we wish to open source it and have people engage in the
 development of the project. There are, at present, indirect
 relationships in that some dependencies are built on Apache
 software, but these are generally by proxy and does not merit
 considering Warble as a sub-project of an existing TLP.
 
  
==Initial Source ==
  
 The initial task of the PMC will be assessing what we wish the

 project to contain. The proprietary vendor is willing to donate the
 software, but considerable rewriting and relicensing will have to
 take place. This will likely happen in stages, with the scrapers
 and UI being ported first, and a backend auth system being partly
 ported/donated

Re: [VOTE] Accept Warble into the Apache Incubator

[Daniel Gruno]

+1 (binding), despite the terrible formatting :P

With regards,
Daniel.

On 06/08/2018 09:06 AM, Chris Thistlethwaite wrote:

Hi All,
I'd like to start a vote on accepting Warble into the Apache Incubator.
https://lists.apache.org/thread.html/1d62a2948d047cea38e6f01f92d5f138f8
3acd2c9d86349023fb28e4@%3Cgeneral.incubator.apache.org%3E
The ASF voting rules are described:
https://www.apache.org/foundation/voting.html
A vote for accepting a new Apache Incubator podling is a majority
votefor which only Incubator PMC member votes are binding.
This vote will run for at least 72 hours. Please VOTE as follows[ ] +1
Accept Warble into the Apache Incubator[ ] +0 Abstain.[ ] -1 Do not
accept Warble into the Incubator
The proposal is listed below, but you can also access it on the wiki:ht
tps://wiki.apache.org/incubator/WarbleProposal

Thank you,Chris T.


= Apache Warble Proposal =
== Abstract ==
 Apache Warble is a distributed endpoint monitoring solution where
the agentis hosted on your own hardware. The aim of Warble is to
produce a more balanced and less binary view of services and
systems, lowering the rates of false positiveswhile also providing
greater insight into possible peering issues and proactive
trendanalysis. ==Proposal == The goal of Warble
will be to bring internal control of distributed monitoring back to
the end user. Warble can be used as an independentservice running
on your own infrastructure monitoring other servicesin your
infrastructure.  == Background and Rationale == The
beginning of this project was prompted by the service
pingmybox.com (PMB) going end of life. This brought up conversation
about FOSS services that can monitor internal and external
services. PMB offered a unique code base to build this service upon
a known infrastructure. ===Initial Goals ===
 Bring PMB code into the ASF, refactor the client/server into a
more reusable structure. Further reuse of code gives us the a great
starting point to build a starting point.  ==Current Status
== The software exists as a proprietary service. We wish to
convert this toa FLOSS solution. ==Meritocracy
== The initial PMC list covers new folks coming into the
ASF. ==Community == There exists a large user-base of
software like Warble, as well as existing users of the old propietary
service. It is our hope that wecan convert a great deal of these to
contributors and testers for thenew open source
product. ==Core Developers == The initial set of
developers are a lot of newcomers:
 * Daniel Gruno * Chris Thistlethwaite
* Haig Didizian * Andrew
Karetas * Chandler Claxton
* Luke Stevens
* Mike Andescavage
* Chris Lambertus
 ==Known Risks ==There are many
existing services that provide external monitoring. Theyare well
established and have large user bases. ===Orphaned Products
=== The initial PMC has great interest in open source projects,
though no formal projects have been
run.  ===Inexperience with Open Source === Most of
the initial PPMC members are new to the ASF and some are new to open
source projects. However,all are very interested in giving back to
the community and projects.  Having said that, there areseveral
people involved with extensive experience in the Apache Way and our
procedures and processes. ===Homogenous Developers
=== The initial set of developers are employed by a variety of
companies,located across the world, and used to working on a
variety ofdistributed projects. ===Reliance on Salaried
Developers === We do not expect the interest of the proposed
initial PMC to be directlytied to current employment, but will
actively seek to grow our volunteerbase
regardless. ===Relationships with Other Apache Products
=== Not much to say here. Many ASF projects make use of the
proprietaryoffering, we wish to open source it and have people
engage in thedevelopment of the project. There are, at present,
indirect relationships in that some dependencies are built on
Apache software, but these are generally by proxy and does not
merit considering Warble as a sub-projectof an existing
TLP.  ==Initial Source == The initial task of the
PMC will be assessing what we wish the project tocontain. The
proprietary vendor is willing to donate the software,
butconsiderable rewriting and relicensing will have to take place.
This willlikely happen in stages, with the scrapers and UI being
ported first,and a backend auth system being partly ported/donated,
and partlydeveloped from scratch at the ASF. ===Source and
Intellectual Property Submission Plan === All the existing code
in question (from the PMB suite) is owned byQuenda IvS

Re: Default webpages for new podlings

[Daniel Gruno]

On 04/16/2018 07:14 PM, Gian Merlino wrote:

Is there any ASF infra that would be usable for automatically running
Jekyll on the master branch and pushing the results to the "asf-git"
branch, where they can be served? Maybe CI/build infra, if we have that? It
would provide an experience that is somewhat like GitHub pages.


You have your choice of either buildbot or jenkins - both work and 
produce web sites for many projects already.




On Mon, Apr 16, 2018 at 9:53 AM, Julian Hyde  wrote:


Just to clarify, in case people are not familiar with Jekyll. It is a code
generator that a developer runs in their sandbox, and it generates the
site. The developer then checks in the site to git or svn.

So, the developer has complete control over the HTML that is checked in.
They can manually post-process the files produced by Jekyll, if they wish.

Jekyll is not in the code path running on ASF infrastructure that serves
the site. The ASF infra just sees HTML, CSS style sheets and images.

Julian



On Apr 16, 2018, at 8:21 AM, Bertrand Delacretaz <

bdelacre...@codeconsult.ch> wrote:


On Mon, Apr 16, 2018 at 4:39 PM, Matt Sicker  wrote:

...Most places I've seen the CMS still in use was because of svnpubsub,

not

necessarily cms.a.o. We use it to commit the output from

maven-site-plugin,

javadocs, scaladocs, etc. Am I confused here?...


AFAIK both svnpubsub and gitpubsub are fully supported by ASF infra.

It's the content management part of the ASF CMS that's deprecated.

-Bertrand

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org







-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Challenges using Gitbox

[Daniel Gruno]

On 04/11/2018 09:58 PM, Ted Dunning wrote:




3. The mailing list is a bit dated.



Totally true.  Pony helps a bit: https://lists.apache.org/

But not all that much.

Spam shouldn't be much of a problem (it isn't on other lists that I have
been part of). Aside from self-inflicted spam like notifications, that is.

SE is definitely poor. Pony makes the list more searchable, but not as well
as a Google thing.



I think this is a matter of newness and prominence, not as much whether 
the pony is good or bad. I can easily google stuff on there if I search 
for "site:lists.apache.org fosdem 2018" and read up on fosdem topics 
(Google knows how to crawl it)...but there are some 20 million emails to 
index on a relatively new sub domain, and that's probably gonna take a 
while. It will very likely change and be easier in the future, but I've 
no idea how fast that'll happen.


Anyway, as we always say, patches welcome :). If people have improvement 
suggestions, we'll gladly accept them at the pony mail project. There 
are several major overhauls on the drawing board, but with many users 
and very few contributors, this moves along quite slowly.


With regards,
Daniel.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Pony Mail (Incubating) 0.10

[Daniel Gruno]

On 02/16/2018 12:39 AM, Justin Mclean wrote:
> Hi,
> 
> I know the vote is over but I noticed a couple a minor things you may want to 
> fix in the next release:
> -  NOTICE has incorrect year
> - jQuery mentioned in LICENSE doesn’t seem to be bundled

Ack, we'll get those fixed up :)

> 
> It also might be a good idea to say if you have any IPMC binding votes when 
> calling for the vote here.

I did say in the initial email that we had 4 IPMC votes carrying over
from the first vote. If that was not clear enough, I'll make sure it's
clearer next time :)

> 
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[RESULT] [VOTE] Release Apache Pony Mail (Incubating) 0.10

[Daniel Gruno]

With the existing IPMC votes in the original vote, and no further votes
cast in the general@ vote, the release has passed. Yay :)

I'll start prepping for this.

With regards,
Daniel.

On 02/12/2018 02:08 PM, Daniel Gruno wrote:
> 
> As seen below ( full thread at https://s.apache.org/F689 ), the Pony
> Mail community has voted to release Apache Pony Mail (Incubating) 0.10.
> This serves as the official IPMC vote, with 4 binding IPMC votes already
> recorded. The vote will last 72h.
> 
> The release candidate voted on is available at:
> https://dist.apache.org/repos/dist/dev/incubator/ponymail/
> 
> Specifically, this is a vote on
> https://dist.apache.org/repos/dist/dev/incubator/ponymail/apache-pony-mail-0.10-incubating.tar.xz
> (md5, sha256 and sig files are provided as well).
> 
> 
> With regards,
> Daniel.
> 
> 
>  Forwarded Message 
> Subject: [RESULT] [VOTE] Release Apache Pony Mail (Incubating) 0.10
> Date: Mon, 12 Feb 2018 14:01:46 +0100
> From: Daniel Gruno <humbed...@apache.org>
> Reply-To: d...@ponymail.incubator.apache.org
> To: d...@ponymail.incubator.apache.org
> 
> With 5 +1s (of which 4 are binding IPMC votes) and 1 -1, the release
> vote has passed. I'll forward to general@incubator and continue the vote
> there for 72h.
> 
> With regards,
> Daniel.
> 
> On 02/09/2018 11:03 AM, Daniel Gruno wrote:
>> Hullo folks, time for a release methinks!
>>
>> This is a vote on the artifacts collected from the tree in the 0.10
>> branch with commit hash a8ea8a044996ba0aea08fe59156edb79cd6f9db8.
>>
>> The tree can be inspected at
>> https://github.com/apache/incubator-ponymail/tree/a8ea8a044996ba0aea08fe59156edb79cd6f9db8
>>
>> The release candidate is available at:
>> https://dist.apache.org/repos/dist/dev/incubator/ponymail/
>>
>> Specifically, this is a vote on
>> https://dist.apache.org/repos/dist/dev/incubator/ponymail/apache-pony-mail-0.10-incubating.tar.xz
>> (md5, sha256 and sig files are provided as well).
>>
>> Please inspect and vet the candidate and cast your votes accordingly:
>>
>> [ ] +1: Good to go
>> [ ]  0: Meh, either way is fine
>> [ ] -1: Don't release because
>>
>> Anyone is welcome to vote on this release.
>> PPMC members can cast binding votes for the podling's release decision,
>> and IPMC members may cast binding votes that carry over to the IPMC
>> release vote later. This initial vote will last 72 hours (or less if all
>> possible votes have been cast).
>>
>> With regards,
>> Daniel.
>>
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[VOTE] Release Apache Pony Mail (Incubating) 0.10

[Daniel Gruno]

As seen below ( full thread at https://s.apache.org/F689 ), the Pony
Mail community has voted to release Apache Pony Mail (Incubating) 0.10.
This serves as the official IPMC vote, with 4 binding IPMC votes already
recorded. The vote will last 72h.

The release candidate voted on is available at:
https://dist.apache.org/repos/dist/dev/incubator/ponymail/

Specifically, this is a vote on
https://dist.apache.org/repos/dist/dev/incubator/ponymail/apache-pony-mail-0.10-incubating.tar.xz
(md5, sha256 and sig files are provided as well).


With regards,
Daniel.


 Forwarded Message 
Subject: [RESULT] [VOTE] Release Apache Pony Mail (Incubating) 0.10
Date: Mon, 12 Feb 2018 14:01:46 +0100
From: Daniel Gruno <humbed...@apache.org>
Reply-To: d...@ponymail.incubator.apache.org
To: d...@ponymail.incubator.apache.org

With 5 +1s (of which 4 are binding IPMC votes) and 1 -1, the release
vote has passed. I'll forward to general@incubator and continue the vote
there for 72h.

With regards,
Daniel.

On 02/09/2018 11:03 AM, Daniel Gruno wrote:
> Hullo folks, time for a release methinks!
> 
> This is a vote on the artifacts collected from the tree in the 0.10
> branch with commit hash a8ea8a044996ba0aea08fe59156edb79cd6f9db8.
> 
> The tree can be inspected at
> https://github.com/apache/incubator-ponymail/tree/a8ea8a044996ba0aea08fe59156edb79cd6f9db8
> 
> The release candidate is available at:
> https://dist.apache.org/repos/dist/dev/incubator/ponymail/
> 
> Specifically, this is a vote on
> https://dist.apache.org/repos/dist/dev/incubator/ponymail/apache-pony-mail-0.10-incubating.tar.xz
> (md5, sha256 and sig files are provided as well).
> 
> Please inspect and vet the candidate and cast your votes accordingly:
> 
> [ ] +1: Good to go
> [ ]  0: Meh, either way is fine
> [ ] -1: Don't release because
> 
> Anyone is welcome to vote on this release.
> PPMC members can cast binding votes for the podling's release decision,
> and IPMC members may cast binding votes that carry over to the IPMC
> release vote later. This initial vote will last 72 hours (or less if all
> possible votes have been cast).
> 
> With regards,
> Daniel.
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Manually created binary data in ASF repos?

[Daniel Gruno]

On 02/12/2018 09:42 AM, Justin Mclean wrote:
> Hi,
> 
>> I have a little question regarding binary data in ASF repos.
> 
> IMO It’s only compiled code that’s not allowed, other binary formats like 
> image, pdfs, fonts etc ect are all OK so this should also be OK. I can point 
> to a number of releases reviewed here that have had binary files (but not 
> compiled source code) in them. Might be a good to label them clearly so 
> anyone who looks know what they are.

Totally fine, yep.
The reasoning is, we can't vote on binary _code_, only the source.
If the binary data is test data, there is nothing to _code_ to verify.
There are plenty of examples. We don't vote on JPEGs and PNGs either ;)

> 
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Apache Policy Quiz

[Daniel Gruno]

On 01/25/2018 07:07 AM, Roman Shaposhnik wrote:
> On Wed, Jan 24, 2018 at 9:55 PM, Justin Mclean  
> wrote:
>> Hi,
>>
>>> I got inconsistent results from the same answer out of the same choices on 
>>> the same question. It was not clear to me that many of the questions are 
>>> “check all that apply”.
>>
>> I will add that to make it clearer.
>>
>>> Some of the questions are poorly worded, e.g. something like “can Apache 
>>> rely on cat X  software”:
>>
>> I used that wording as it is used in the legal resolved page. [1] “depend” 
>> or “rely on a dependancy” may be better words to use.
>>
>>> For many of the questions I thought there was a mismatch between my 
>>> understanding of Apache policy and any of the possible answers presented, 
>>> and I ended up feeling vaguely insulted.
>>
>> Sorry that was certainly not my intention.
> 
> I was holding off on this -- but now I just can't resit. So here it goes:
> 
> Surely we are not talking about some kind of an official ASF exam test
> here, right?
> 
> This is more of a fun quiz that makes people think about certain things which
> means that anything goes -- trick questions, silly questions, whatever (not 
> that
> I'm making a judgement call on what Justin has there -- just pointing
> this out in
> general).
> 
> In that sense, how could anyone has a "...I ended up feeling vaguely insulted"
> is a tad beyond my understanding.
> 
> So I guess my only bit of feedback would be this: use this opportunity to make
> the test go: "ah well, here's the thing..." when somebody ends up with one
> of those "not quite" answers.

Trick questions could be fun ;) provided they are educational.

> 
> Just my 2c.
> 
> Thanks,
> Roman.
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Apache Policy Quiz

[Daniel Gruno]

On 01/25/2018 06:54 AM, Greg Stein wrote:
> On Wed, Jan 24, 2018 at 11:52 PM, Justin Mclean 
> wrote:
> 
>> Hi,
>>
>>> "manually placed into www.apache.org/dist" ... I left that box
>> unchecked,
>>> and well... dang. I still got it wrong, it seems.
>>
>> There no question with that answer that I can see. There’s is one that say
>> "Place the artifacts in www.apache.org/dist.” which you do need to check.
>> I could replace “Place” with “svn mv” if you think that is more accurate.
>>
> 
> That's the right text. I just typed from memory.
> 
> Point holds.
> 
> No, I'm not gonna issue PRs. The methodology of presenting 2 of 3 answers,
> then saying I got it wrong because I couldn't click that not-shown 3rd...
> Nah.
> 

I'm gonna add to this and say there can't be two correct answers in such
a quiz. Either the answer encompasses the full scope of the question, or
it's not the right answer if the aim is to teach people about our
policies and ways. Having one option in the cat-x question say "no, with
exceptions" and one say "yes, for release tools"...the former is still
the only correct answer and encompasses both pseudo-answers. The latter
omits several other allowed scenarios.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept ECharts for Apache Incubation

[Daniel Gruno]

:
> 
> Upon entering incubation: https://github.com/apache/incubator-echarts
> After incubation, we want to move the existing repo from
> github/ecomfe/echarts to Apache infrastructure.
> 
> Issue Tracking:
> 
> ECharts currently uses GitHub to track issues. there are more than 7k
> issues. Would like to continue to do so while we discuss migration
> possibilities with the ASF Infra committee.
> 
> URL:
> 
> Currently the website url is
> https://ecomfe.github.io/echarts-doc/public/en/index.html. It will be
> moved to http://echarts.incubator.apache.org/ to follow incubator
> conventions.
> 
> Initial Committers
> 
>     Lin Zhifeng (https://github.com/kener kener.linf...@gmail.com)
> 
>     Su Shuang (https://github.com/100pah sushuang0...@gmail.com)
> 
>     Shen Yi (https://github.com/pissang shenyi@gmail.com)
> 
>     Zhang Wenli (https://github.com/Ovilia m...@zhangwenli.com)
> 
>     Li Deqing (https://github.com/deqingli annong...@gmail.com)
>     Wang Junting
> 
>     Dong Rui (https://github.com/erik168 error...@gmail.com)
> 
>     Huang Houjin (https://github.com/chriswong w...@foxmail.com)
> 
> Sponsors:
> 
> Champion:
> 
>     Kevin A. McGrail
> 
> Mentors:
> 
>     Daniel Gruno
> 
>     Kevin A. McGrail
>     Dave Fisher
>     John D. Ament
> 
> Sponsoring Entity
> We are requesting the Incubator to sponsor this project.
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release of Apache BatchEE 0.5-incubating

[Daniel Gruno]

On 12/06/2017 06:18 PM, Romain Manni-Bucau wrote:
> 2017-12-06 18:14 GMT+01:00 Daniel Gruno <humbed...@apache.org>:
>> On 12/06/2017 06:10 PM, Mark Struberg wrote:
>>> As explained in the original GIT at ASF threads many years ago: you cannot 
>>> easily get rid of a branch at ASF.
>>> Even if we force-push a delete it will _not_ get propagated downstream and 
>>> would cause clashes if a release needs to be re-rolled.
>>
>> Move to gitbox, problem solved?
> 
> Doesn't change anything AFAIK since it is the exact same archi no?

No it's not the same architecture - that wouldn't make much sense :)
gitbox is github r/w access with pruning of deleted branches enabled.

> 
>> It strikes me as highly irregular that you are voting on something with
>> no guaranteed provenance in place. Perhaps this is based on
>> misinformation? I'd be inclined to vote -1 here, but I just can't be
>> bothered.
> 
> No guarantee is quite rude since it is still mainly about trust
> between asf people. Or is the issue to use github only?

It's not all about trust, it's trust BUT verify. We can verify on the
ASF side, we can't verify someone's private repository. I'd also point
to the incubator policy (as john linked to) that states that the source
must be at ASF for a release vote to be held. Arguably, this is not the
case here. I'd suggest you simply move the repos to gitbox, give us
sufficient provenance to vote on the release, and you get to delete
branches.

> 
>>
>>> That's the reason why we do NOT push the staging branch to the ASF 
>>> cannonical repo. Never did for most ASF projects.
>>> You can also read this up in the original GIT documentation I worked out 
>>> with Infra and CouchDB.
>>>
>>> LieGrue,
>>> strub
>>>
>>>
>>>> Am 06.12.2017 um 17:36 schrieb John D. Ament <johndam...@apache.org>:
>>>>
>>>> Right, but the IPMC has general oversight and responsibilities for
>>>> podlings.  Our requirements for what goes into a release are at
>>>> https://incubator.apache.org/policy/incubation.html#releases
>>>>
>>>> John
>>>>
>>>> On Wed, Dec 6, 2017 at 11:16 AM Romain Manni-Bucau <rmannibu...@gmail.com>
>>>> wrote:
>>>>
>>>>> @John: depends the project. DeltaSpike, BatchEE and several others
>>>>> don't and it is fine IMHO.
>>>>>
>>>>> Romain Manni-Bucau
>>>>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
>>>>>
>>>>>
>>>>> 2017-12-06 17:04 GMT+01:00 John D. Ament <johndam...@apache.org>:
>>>>>> On Wed, Dec 6, 2017 at 11:00 AM Romain Manni-Bucau <
>>>>> rmannibu...@gmail.com>
>>>>>> wrote:
>>>>>>
>>>>>>> 2017-12-06 16:41 GMT+01:00 sebb <seb...@gmail.com>:
>>>>>>>> On 6 December 2017 at 08:08, Reinhard Sandtner <rsandt...@apache.org>
>>>>>>> wrote:
>>>>>>>>> Hey incubator PMCs,
>>>>>>>>>
>>>>>>>>> The Apache BatchEE community has voted and approved the proposal to
>>>>>>> release Apache BatchEE 0.5-incubating.
>>>>>>>>> Apache BatchEE is a JBatch implementation (JSR-352) which provides
>>>>> many
>>>>>>> enhancements and extensions.
>>>>>>>>>
>>>>>>>>> You may find the VOTE thread here:
>>>>>>>>>
>>>>>>>
>>>>> https://lists.apache.org/thread.html/50c023e02cebcb61bc61aa2ea6112d366b1dba0db04c045b7c1b415b@%3Cdev.batchee.apache.org%3E
>>>>>>> <
>>>>>>>
>>>>> http://mail-archives.apache.org/mod_mbox/batchee-dev/201712.mbox/%3c501767c2-1220-41f1-a8f9-73330969d...@apache.org%3E
>>>>>>>>
>>>>>>>>>
>>>>>>>>> the RESULT VOTE thread can be found here:
>>>>>>>>>
>>>>>>>
>>>>> https://lists.apache.org/thread.html/6d05ea8439167e15d720d318c9c2845fbd134ae2967321e3b7540386@%3Cdev.batchee.apache.org%3E
>>>>>>> <
>>>>>>>
>>>>> https://lists.apache.org/thread.html/6d05ea8439167e15d720d318c9c2845fbd134ae2967321e3b7540386@%3Cdev.batchee.apache.org%3E
>>>>>>>>
>>>>>>>>>
>>>>>>>>> For information about the contents of 

Re: [VOTE] Release of Apache BatchEE 0.5-incubating

[Daniel Gruno]

On 12/06/2017 06:10 PM, Mark Struberg wrote:
> As explained in the original GIT at ASF threads many years ago: you cannot 
> easily get rid of a branch at ASF.
> Even if we force-push a delete it will _not_ get propagated downstream and 
> would cause clashes if a release needs to be re-rolled.

Move to gitbox, problem solved?
It strikes me as highly irregular that you are voting on something with
no guaranteed provenance in place. Perhaps this is based on
misinformation? I'd be inclined to vote -1 here, but I just can't be
bothered.

> That's the reason why we do NOT push the staging branch to the ASF cannonical 
> repo. Never did for most ASF projects.
> You can also read this up in the original GIT documentation I worked out with 
> Infra and CouchDB.
> 
> LieGrue,
> strub
> 
> 
>> Am 06.12.2017 um 17:36 schrieb John D. Ament :
>>
>> Right, but the IPMC has general oversight and responsibilities for
>> podlings.  Our requirements for what goes into a release are at
>> https://incubator.apache.org/policy/incubation.html#releases
>>
>> John
>>
>> On Wed, Dec 6, 2017 at 11:16 AM Romain Manni-Bucau 
>> wrote:
>>
>>> @John: depends the project. DeltaSpike, BatchEE and several others
>>> don't and it is fine IMHO.
>>>
>>> Romain Manni-Bucau
>>> @rmannibucau |  Blog | Old Blog | Github | LinkedIn
>>>
>>>
>>> 2017-12-06 17:04 GMT+01:00 John D. Ament :
 On Wed, Dec 6, 2017 at 11:00 AM Romain Manni-Bucau <
>>> rmannibu...@gmail.com>
 wrote:

> 2017-12-06 16:41 GMT+01:00 sebb :
>> On 6 December 2017 at 08:08, Reinhard Sandtner 
> wrote:
>>> Hey incubator PMCs,
>>>
>>> The Apache BatchEE community has voted and approved the proposal to
> release Apache BatchEE 0.5-incubating.
>>> Apache BatchEE is a JBatch implementation (JSR-352) which provides
>>> many
> enhancements and extensions.
>>>
>>> You may find the VOTE thread here:
>>>
>
>>> https://lists.apache.org/thread.html/50c023e02cebcb61bc61aa2ea6112d366b1dba0db04c045b7c1b415b@%3Cdev.batchee.apache.org%3E
> <
>
>>> http://mail-archives.apache.org/mod_mbox/batchee-dev/201712.mbox/%3c501767c2-1220-41f1-a8f9-73330969d...@apache.org%3E
>>
>>>
>>> the RESULT VOTE thread can be found here:
>>>
>
>>> https://lists.apache.org/thread.html/6d05ea8439167e15d720d318c9c2845fbd134ae2967321e3b7540386@%3Cdev.batchee.apache.org%3E
> <
>
>>> https://lists.apache.org/thread.html/6d05ea8439167e15d720d318c9c2845fbd134ae2967321e3b7540386@%3Cdev.batchee.apache.org%3E
>>
>>>
>>> For information about the contents of this release, see:
>>>
>
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314924=12334679
> <
>
>>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?projectId=12314924=12334679
>>
>>>
>>> The tag is available on my github fork
>>>
>
>>> https://github.com/rsandtner/incubator-batchee/tree/batchee-0.5-incubating
> <
>
>>> https://github.com/rsandtner/incubator-batchee/tree/batchee-0.5-incubating
>>
>>
>> That does not seem right.
>> Tags need to be permanent and 'owned' by the (P)PMC
>
> During the vote - and for git - the tags shouldnt hit git@asf to
> ensure that they are permanent (naming convention hacks don't work so
> using forks is the choice which has been done by several projects,
> including BatchEE).
>
> If it helps I can push the tag on my fork (which would make it owned
> by the PMC) but since Reihard is a committer I don't see any issue
> here.
>

 I think what we've been doing is pushing to the ASF repos and pointing to
 the specific commit hash.


>
>>
>>> Staging Repo is here:
>>>
>
>>> https://repository.apache.org/content/repositories/orgapachebatchee-1005 <
>
>>> https://repository.apache.org/content/repositories/orgapachebatchee-1005>
>>
>> That is only the Maven staging area.
>>
>> The source must be released through the ASF mirror system,
>>
>> The staging area for that is here:
>>
>> https://dist.apache.org/repos/dist/dev/incubator/batchee/
>>
>> [If the vote succeeds, the files can be moved here:
>> https://dist.apache.org/repos/dist/release/incubator/batchee/]
>>
>>> Sources can be found here:
>>>
>
>>> https://repository.apache.org/content/repositories/orgapachebatchee-1005/org/apache/batchee/batchee/0.5-incubating/batchee-0.5-incubating-source-release.zip
> <
>
>>> https://repository.apache.org/content/repositories/orgapachebatchee-1005/org/apache/batchee/batchee/0.5-incubating/batchee-0.5-incubating-source-release.zip
>>
>>>
>>> Release artifacts are singed with the KEY:
>>> https://github.com/apache/incubator-batchee/blob/master/KEYS <
> 

Re: Where to edit a podling's data for whimsey?

[Daniel Gruno]

On 03/24/2017 11:18 PM, Stack wrote:
> I am having trouble finding where to edit to fix a podling's whimsey view?
> Pointers appreciated.
> Thanks,
> St.Ack
> 

TL;DR: https://whimsy.apache.org/roster/ppmc/ ;)

With regards,
Daniel

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Apache Fineract podling graduation (restarted with corrected proposal)

[Daniel Gruno]

+1 (binding), best of luck!!

On 03/22/2017 03:11 PM, Myrle Krantz wrote:
> Greetings Incubator,
> 
> I propose that we graduate Apache Fineract from the Incubator.  The
> full text of the proposal is below.
> 
> This is a restarted VOTE thread to correct an error in the resolution
> from the original thread. Here's the previous VOTE thread:
> 
> [https://lists.apache.org/thread.html/1cbc738bbb4083e50b7772d5226b88d3fe321b91451303a69dbc4fa8@%3Cgeneral.incubator.apache.org%3E]
> 
> And here's the DISCUSS thread:
> 
> [https://lists.apache.org/thread.html/630d3ec22b4f72f827cd817a0a4da5c3c52dee4f96f47a1369f5dc50@%3Cgeneral.incubator.apache.org%3E]
> 
> 
> Thank you,
> Myrle Krantz
> 
> 
> Resolution:
> 
> Establish the Apache Fineract Project
> 
> WHEREAS, the Board of Directors deems it to be in the best
> interests of the Foundation and consistent with the
> Foundation's purpose to establish a Project Management
> Committee charged with the creation and maintenance of
> open-source software, for distribution at no charge to the
> public, related to a core banking platform that provides a reliable,
> robust, and affordable solution for entrepreneurs, financial
> institutions, and service providers to offer financial
> services to the world's underbanked and unbanked.
> 
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> Committee (PMC), to be known as the "Apache Fineract Project",
> be and hereby is established pursuant to Bylaws of the
> Foundation; and be it further
> 
> RESOLVED, that the Apache Fineract Project be and hereby is
> responsible for the creation and maintenance of software
> related to a core banking platform that provides a reliable,
> robust, and affordable solution for entrepreneurs, financial
> institutions, and service providers to offer financial
> services to the world's underbanked and unbanked.
> 
> RESOLVED, that the office of "Vice President, Apache Fineract" be
> and hereby is created, the person holding such office to
> serve at the direction of the Board of Directors as the chair
> of the Apache Fineract Project, and to have primary responsibility
> for management of the projects within the scope of
> responsibility of the Apache Fineract Project; and be it further
> 
> RESOLVED, that the persons listed immediately below be and
> hereby are appointed to serve as the initial members of the
> Apache Fineract Project:
> 
> * Vishwas Babu AJ 
> * Edward Cable 
> * Markus Geiss 
> * Sander van der Heijden 
> * Ishan Khanna 
> * Myrle Krantz 
> * Terence Monteiro 
> * Adi Nayaran Raju 
> * Gaurav Saini 
> * Nazeer Hussain Shaik 
> * Jim Jagielski 
> * Michael Vorburger 
> 
> 
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Myrle Krantz
> be appointed to the office of Vice President, Apache Fineract, to
> serve in accordance with and subject to the direction of the
> Board of Directors and the Bylaws of the Foundation until
> death, resignation, retirement, removal or disqualification,
> or until a successor is appointed; and be it further
> 
> RESOLVED, that the initial Apache Fineract PMC be and hereby is
> tasked with the creation of a set of bylaws intended to
> encourage open development and increased participation in the
> Apache Fineract Project; and be it further
> 
> RESOLVED, that the Apache Fineract Project be and hereby
> is tasked with the migration and rationalization of the Apache
> Incubator Fineract podling; and be it further
> 
> RESOLVED, that all responsibilities pertaining to the Apache
> Incubator Fineract podling encumbered upon the Apache Incubator
> Project are hereafter discharged.
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: GitHub workflows?

[Daniel Gruno]

On 03/06/2017 04:56 AM, Niclas Hedhman wrote:
> Everyone,
> I need to get an understanding of the use of GitHub workflows on Apache
> projects.
> 
> In GH, it is possible to comment on commits and pull requests. Are those
> captured by infra@ and replicated somewhere, or is this "lost data" (I
> suspect) in case GitHub goes out of business?

Pull requests and issues are relayed back to the projects' mailing
list(s) automatically. Check, for instance,
https://lists.apache.org/list.html?iss...@trafficserver.apache.org

> 
> Cheers
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Archives for project private lists

[Daniel Gruno]

On 03/03/2017 05:32 PM, Bruce Snyder wrote:
> Where can I find the archives for project private lists nowadays? Things
> seem to have changed a bit regarding archives, so I have looked in the
> mod_mbox archives (http://mail-archives.apache.org/mod_mbox/) and in the
> Pony Mail archives (https://lists.apache.org/) but I am unable to locate
> any project private lists in either archive.

Log in (top right, choose ASF Oauth when asked) to lists.a.o and the
secret stuff should appear :)

> 
> I'm trying to locate the URL to a new committer vote thread.
> 
> Can someone please help me find them?
> 
> Bruce
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: 回复：[VOTE] Weex to enter the Apache Incubator

[Daniel Gruno]

On 11/28/2016 04:06 PM, 吴志华(天施) wrote:
> 
>  +1 (binding)

For binding +1s, we generally require a name we can compare with our
Apache Phonebook to make sure you are on the IPMC. I was unable to find
you as a committer, could you please tell me your apache ID?

With regards,
Daniel.

> --发件人：Stephan 
> Ewen 发送时间：2016年11月28日(星期一) 18:02收件人：general 
> 主　题：Re: [VOTE] Weex to enter the Apache 
> Incubator
> +1 (binding)
> 
> 
> On Sun, Nov 27, 2016 at 1:44 AM, Luke Han  wrote:
> 
>>  +1 binding
>>
>>  Get Outlook for iOS
>>
>>
>>
>>
>>  On Sat, Nov 26, 2016 at 8:41 PM +0800, "Willem Jiang" <
>>  willem.ji...@gmail.com> wrote:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>  +1 （binding）
>>
>>
>>  Willem Jiang
>>
>>  Blog: http://willemjiang.blogspot.com (English)
>>http://jnn.iteye.com  (Chinese)
>>  Twitter: willemjiang
>>  Weibo: 姜宁willem
>>
>>  On Fri, Nov 25, 2016 at 6:47 AM, Edward J. Yoon
>>  wrote:
>>
>>  > Greetings!
>>  >
>>  > I would like to call a vote for accepting "Weex" for incubation in the
>>  > Apache Incubator. The full proposal is available below.  We ask the
>>  > Incubator PMC to sponsor it, with myself (Edward J. Yoon) as Champion,
>>  and
>>  > Luke Han, Willem Jiang, Stephan Ewen, and Niclas Hedhman volunteering to
>>  be
>>  > Mentors.
>>  >
>>  > Please cast your vote:
>>  >
>>  > [ ] +1, bring Weex into Incubator
>>  > [ ] +0, I don't care either way,
>>  > [ ] -1, do not bring Weex into Incubator, because...
>>  >
>>  > This vote will be open at least for 72 hours and only votes from the
>>  > Incubator PMC are binding.
>>  >
>>  > --
>>  > https://wiki.apache.org/incubator/WeexProposal
>>  >
>>  > = Weex Proposal =
>>  >
>>  > == Abstract ==
>>  > Weex is a framework for building Mobile cross-platform high performance
>>  UI.
>>  > Weex enables developers to use Web-like syntax to build iOS, Android and
>>  > Web
>>  > UI with a single codebase.
>>  >
>>  > == Proposal ==
>>  > Weex provide an uniform Web-like syntax for develop native Mobile App UI.
>>  > By
>>  > leverage the Javascript engine that enable dynamic update, the process of
>>  > App interfce and content update can be simple and controllable just like
>>  > Web.Compared with WebView based UI framework which performance are
>>  limited,
>>  > Weex use build-in native components instead.
>>  >
>>  > Because of tag based syntax that maintain a consistent style with Web
>>  > standards Weex using. Developers write in this language just like
>>  writting
>>  > in HTML. After transforming to JSBundle by Weex tools, these tags will be
>>  > rendered by build-in platform-specific components. The logic part of Weex
>>  > syntax write in Javascript which don't need be compiled control these
>>  > components.
>>  >
>>  > The vision of Weex is to complement gap between platform-specific Native
>>  UI
>>  > and Web technical based UI in Mobile age. The team behind Weex believe
>>  that
>>  > dynamicly interface update and high performance should be achieved at the
>>  > same time when people develop a Mobile App. Meanwhile duplicate work
>>  > between
>>  > the different platforms should be avoided.
>>  >
>>  > == Background ==
>>  > Prior to Weex, in order to develop high performance mobile application we
>>  > need write at least three different codebase(iOS, Android, Mobile Web) or
>>  > adopt WebView based UI technique(Apache Cordova for example) which can't
>>  > satisfy the demand for performance.
>>  >
>>  > A special task force at Alibaba Inc try to provide a solution for this
>>  > problem has been setup since 2013.  At first the team release a
>>  > cross-platform rendering engine which render a special format JSON to
>>  > native
>>  > components on different platform. To output this JSON file the team had
>>  > build a website which other developer can use to simply design final
>>  > interface.
>>  >
>>  > Although This solution had worked for a while, we found it not able to
>>  meet
>>  > our UI developer's habits. Most of our UI developer have Web background
>>  > which make them used to use tag based language to design App interface.
>>  > Meanwhile we found the JSON file lacks of enough flexibility. The
>>  following
>>  > discussion inspire we start to develop Weex.
>>  >
>>  > Nowaday, Mobile Taobao App which developed by Alibaba Inc, the largest
>>  user
>>  > volume eCommerce App in China has adapted Weex in a lot of UI. In the
>>  > latest
>>  > November 11th promotions(Alibaba's annual Singles' Day online shopping
>>  > event), UI developers from Alibaba Inc have build more then 1,500 pages
>>  > using Weex, 99.6% of all the promotional pages. The ratio of less than
>>  one
>>  > second page open time is more than 90%, the frame rate is
>>  53.0~58.5(depend
>>  > on device) due to the high performance of Weex. In addition to user
>>  > experience improvement, the productivity 

Re: Most successful projects in Apache in the past 2 years

[Daniel Gruno]

On 11/27/2016 05:22 PM, Genoveffa Pagano wrote:
> Thanks Daniel,
> even generic data would be interesting for me.
> Is there a web page that collects this type on info? Can you advise me on
> where to find the data?

It's not publicly available to everyone (at least, not for the time being).

If you reach out to Sally Khudairi (sk@a.o or press@a.o) she should be
able to introduce you to the statistics we have access to.

> 
> Gen
> 
> Genoveffa Pagano
> VP of Product
> MIRACL
> T: +44 (0) 20 3389 08190
> M: +44 (0) 7749 159 824
> Skype: genoveffa.pagano
> https://www.miracl.com
> 81 Rivington Street
> London UK, EC2A 3AY
> Registered in England and Wales 7017635
> 
> 
> On 27 November 2016 at 15:47, Daniel Gruno <humbed...@apache.org> wrote:
> 
>> On 11/27/2016 04:35 PM, Genoveffa Pagano wrote:
>>> Hello,
>>> I am trying to gather some data on the most successful Apache projects,
>>> including incubating projects, in the past couple of years.
>>> With successful, I mean the ones with most development from diverse
>>> developers and companies, when applicable.
>>> Is there a place where I can find such statistics?
>>> Thanks
>>> gen
>>
>> While such statistics are generally available to all committers, I must
>> point out that contributions to Apache projects are made by individuals,
>> not companies, and as such, we don't publish statistics on companies'
>> contributions (because, as stated, it's not a thing).
>>
>> If you are looking for a *correlation* between contributions and company
>> affiliations (which is not to say that any company has any pull on
>> projects, they don't), it's possible to get an educated estimation
>> through our organization at Snoot (requires apache committership to
>> access right now). You could also process the publicly available data
>> yourself, although it's a very intensive operation, even on a
>> per-project basis.
>>
>> With regards,
>> Daniel.
>>
>>>
>>>
>>> Genoveffa Pagano
>>> VP of Product
>>> MIRACL
>>> T: +44 (0) 20 3389 08190
>>> M: +44 (0) 7749 159 824
>>> Skype: genoveffa.pagano
>>> https://www.miracl.com
>>> 81 Rivington Street
>>> London UK, EC2A 3AY
>>> Registered in England and Wales 7017635
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Most successful projects in Apache in the past 2 years

[Daniel Gruno]

On 11/27/2016 04:35 PM, Genoveffa Pagano wrote:
> Hello,
> I am trying to gather some data on the most successful Apache projects,
> including incubating projects, in the past couple of years.
> With successful, I mean the ones with most development from diverse
> developers and companies, when applicable.
> Is there a place where I can find such statistics?
> Thanks
> gen

While such statistics are generally available to all committers, I must
point out that contributions to Apache projects are made by individuals,
not companies, and as such, we don't publish statistics on companies'
contributions (because, as stated, it's not a thing).

If you are looking for a *correlation* between contributions and company
affiliations (which is not to say that any company has any pull on
projects, they don't), it's possible to get an educated estimation
through our organization at Snoot (requires apache committership to
access right now). You could also process the publicly available data
yourself, although it's a very intensive operation, even on a
per-project basis.

With regards,
Daniel.

> 
> 
> Genoveffa Pagano
> VP of Product
> MIRACL
> T: +44 (0) 20 3389 08190
> M: +44 (0) 7749 159 824
> Skype: genoveffa.pagano
> https://www.miracl.com
> 81 Rivington Street
> London UK, EC2A 3AY
> Registered in England and Wales 7017635
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Weex for Apache Incubator

[Daniel Gruno]

What we are concerned with is whether the name clashes with other
projects or have other potential branding issues. Whether it means
something funny in $language, who cares... :)

I think Weex is just fine. Let's move on.

With regards,
Daniel.

On 11/22/2016 02:44 PM, Emilian Bold wrote:
> Not long ago we had a thread here about English being the work language on
> Apache.
> 
> We can't expect projects to check (and change) their name based on such
> loose criteria.
> 
> I bet a lot of names come "close" to some slang word in some world language.
> 
> Bertrand's remark seems reasonable to me:
> 
>> the comments in this thread should be considered
> friendly advice, nothing more.
> 
> So there is no incubation-impacting decision to be made here.
> 
> În mar., 22 nov. 2016 la 15:03 Jochen Wiedmann 
> a scris:
> 
> On Tue, Nov 22, 2016 at 1:27 PM, Emilian Bold 
> wrote:
>> How can the project name be a problem when "weex" sounds to me like the
>> very common English word *weeks*?
> 
> Depends on the language. In german, it's close to a slang word for
> "masturbation", Not sufficiently close, IMO, to cause problems, but
> others may have a different point of view.
> 
> 
> Jochen
> 
> --
> The next time you hear: "Don't reinvent the wheel!"
> 
> http://www.keystonedevelopment.co.uk/wp-content/uploads/2014/10/evolution-of-the-wheel-300x85.jpg
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Policy Question: GA for GitHub for Podlings

[Daniel Gruno]

On 11/09/2016 01:00 AM, Christopher wrote:
> Sorry if these questions have already been answered, but I'm still a bit
> confused, so if anybody can answer I'd be grateful.
> 
> Why is GA for podlings being considered before GA for TLPs? Or, is GitHub
> already generally available to TLPs, and I missed that? If I didn't miss
> anything, what are the arguments in favor of and against enabling this for
> podlings first?

Likely because podlings are not TLPs, so they have more freedom in where
they put their source code before graduation. Once graduated, you HAVE
to follow the very specific ruleset of the ASF as a TLP. Podling
experiments going wrong is not nearly as 'deadly' as with a TLP.

> 
> How does this relate to M.A.T.T.? Is that still being piloted, or is that
> now generally available to projects? Is this something different?

MATT will still play a vital role in linking accounts.

> 
> Are we talking about granting PMCs admin on the repos, and committers
> write-access? Or, only PMC chair admin, or some other combination of access
> grants?

This will only be write-access to all committers. There will be no admin
access until we are confident that the granularity of the GitHub ACL is
sufficient for this.

> 
> Will this enable projects to manage GitHub issue labels and milestones?
> That's been really sorely lacking in the Fluo podling since we transitioned
> to incubation from our previous GitHub home, and it'd be *really* nice to
> get that working again.

Yes, you will be able to set labels etc and work with GH issues.

> 
> On Tue, Nov 8, 2016 at 6:47 PM Niall Pemberton 
> wrote:
> 
>> I'm +1 to this for OpenWhisk.
>> I'm -1 to this as a general availability.
>>
>> There could be issues down the road which means that this option is
>> withdrawn. I'd hate to have alot of podlings with an expectation that were
>> later disappointed.
>>
>> Niall
>>
>> On Mon, Nov 7, 2016 at 9:50 PM, Chris Mattmann 
>> wrote:
>>
>>> Hi,
>>>
>>> As some of you may have seen the OpenWhisk podling being discussed now
>> has
>>> requested to use GitHub as its primary master. Greg Stein our ASF Infra
>>> Admin
>>> has OK’ed this for OpenWhisk iff the IPMC is OK with it.
>>>
>>> I ask now:
>>>
>>> 1. Is the IPMC OK with this for OpenWhisk?
>>> 2. Is the IPMC OK with this in general availability for Podlings?
>>>
>>> I am +1 on both (IPMC hat on).
>>>
>>> Thanks.
>>>
>>> Cheers,
>>> Chris
>>>
>>>
>>>
>>>
>>>
>>>
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>>
>>>
>>
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Apache Geode (incubating)

[Daniel Gruno]

On 11/09/2016 12:58 AM, Roman Shaposhnik wrote:
> On Tue, Nov 8, 2016 at 3:30 PM, Daniel Gruno <humbed...@apache.org> wrote:
>> On 11/09/2016 12:26 AM, Niall Pemberton wrote:
>>> On Tue, Nov 8, 2016 at 10:42 PM, Daniel Gruno <humbed...@apache.org> wrote:
>>>
>>>> On 11/08/2016 11:14 PM, Roman Shaposhnik wrote:
>>>>> On Tue, Nov 8, 2016 at 1:54 PM, Rich Bowen <rbo...@rcbowen.com> wrote:
>>>>>>
>>>>>>
>>>>>> On 11/07/2016 10:05 PM, Niall Pemberton wrote:
>>>>>>> On Mon, Nov 7, 2016 at 6:34 PM, Daniel Gruno <humbed...@apache.org>
>>>> wrote:
>>>>>>>
>>>>>>>>> I was looking at Snoot, and some figures jumped at me.
>>>>>>>>>
>>>>>>>>> Is the Podling (and the IPMC) satisfied that there is no concern with
>>>>>>>>> people affiliated with a single company providing more than 90% of
>>>> all
>>>>>>>>> commits over the past year and, as far as I can tell, the vast
>>>> majority
>>>>>>>>> of tickets and email, as well as a 73% stake in the proposed PMC?
>>>>>>>>>
>>>>>>>>> Is the IPMC satisfied that, should this company opt to not further
>>>> spend
>>>>>>>>> resources on this project, that the project would still be as viable?
>>>>>>>>>
>>>>>>> Hi Daniel,
>>>>>>>
>>>>>>> I've observed this project since it joined the incubator and they've
>>>> worked
>>>>>>> hard to create an open and welcoming community and to fix all the
>>>> issues
>>>>>>> raised that could be barriers to their graduation.
>>>>>>>
>>>>>>> In terms of percentages, these things have been debated previously in
>>>>>>> graduation of projects such as Ignite, Flume, Tez etc and I'm not
>>>> going to
>>>>>>> repeat the arguments from those discussions. Geode would be better with
>>>>>>> served with a wider community, but I think what matters is 1) have they
>>>>>>> demonstrated the behaviors we expect and 2) are they moving in the
>>>> right
>>>>>>> direction. Geode is a great community and a pleasure to be involved
>>>> with
>>>>>>> and I would say yes to both of these. I believe they are going in the
>>>> right
>>>>>>> direction to make this project less dependent on one company and
>>>> except to
>>>>>>> change the percentages you've pointed out, theres no purpose left for
>>>> them
>>>>>>> being in the incubator. They've shown that they can manage themselves
>>>> and
>>>>>>> theres enough independent oversight to mitigate concerns which is why I
>>>>>>> think we should vote for them to graduate.
>>>>>>
>>>>>> Given the discussions around single-vendor projects that are raging on
>>>>>> board@ I would have to agree with Daniel's concerns here. Projects that
>>>>>> are heavily dominated by a single vendor/company/organization
>>>>>> historically cause problems over time.
>>>>>
>>>>> I think that other discussion addresses a very different set of problems.
>>>>>
>>>>>> Is there a huge rush to get this project graduated?
>>>>>
>>>>> I'd rather flip your argument around and say: at this point sitting in
>>>> the
>>>>> Incubator adds no value to the project nor does it teach anything
>>>>> new or useful to its PPMC or a community at large.
>>>>
>>>> If it turns the project into a more diverse/dispersed community, I'd say
>>>> that's added value. We can argue all night whether that's up to the
>>>> IPMC, the project or the board to figure out, I'm not sure we'll agree
>>>> there :)
>>>>
>>>>>
>>>>>> Surely we serve the
>>>>>> Foundation, and this project, better, by ensuring that this problem
>>>>>> (and, yes, it's a problem) is addressed before we grant them TLP status?
>>>>>
>>>>> I disagree. The Incubator is a place to make sure that the community
>>>>> (regardless of its composition

Re: [VOTE] Graduate Apache Geode (incubating)

[Daniel Gruno]

On 11/09/2016 12:26 AM, Niall Pemberton wrote:
> On Tue, Nov 8, 2016 at 10:42 PM, Daniel Gruno <humbed...@apache.org> wrote:
> 
>> On 11/08/2016 11:14 PM, Roman Shaposhnik wrote:
>>> On Tue, Nov 8, 2016 at 1:54 PM, Rich Bowen <rbo...@rcbowen.com> wrote:
>>>>
>>>>
>>>> On 11/07/2016 10:05 PM, Niall Pemberton wrote:
>>>>> On Mon, Nov 7, 2016 at 6:34 PM, Daniel Gruno <humbed...@apache.org>
>> wrote:
>>>>>
>>>>>>> I was looking at Snoot, and some figures jumped at me.
>>>>>>>
>>>>>>> Is the Podling (and the IPMC) satisfied that there is no concern with
>>>>>>> people affiliated with a single company providing more than 90% of
>> all
>>>>>>> commits over the past year and, as far as I can tell, the vast
>> majority
>>>>>>> of tickets and email, as well as a 73% stake in the proposed PMC?
>>>>>>>
>>>>>>> Is the IPMC satisfied that, should this company opt to not further
>> spend
>>>>>>> resources on this project, that the project would still be as viable?
>>>>>>>
>>>>> Hi Daniel,
>>>>>
>>>>> I've observed this project since it joined the incubator and they've
>> worked
>>>>> hard to create an open and welcoming community and to fix all the
>> issues
>>>>> raised that could be barriers to their graduation.
>>>>>
>>>>> In terms of percentages, these things have been debated previously in
>>>>> graduation of projects such as Ignite, Flume, Tez etc and I'm not
>> going to
>>>>> repeat the arguments from those discussions. Geode would be better with
>>>>> served with a wider community, but I think what matters is 1) have they
>>>>> demonstrated the behaviors we expect and 2) are they moving in the
>> right
>>>>> direction. Geode is a great community and a pleasure to be involved
>> with
>>>>> and I would say yes to both of these. I believe they are going in the
>> right
>>>>> direction to make this project less dependent on one company and
>> except to
>>>>> change the percentages you've pointed out, theres no purpose left for
>> them
>>>>> being in the incubator. They've shown that they can manage themselves
>> and
>>>>> theres enough independent oversight to mitigate concerns which is why I
>>>>> think we should vote for them to graduate.
>>>>
>>>> Given the discussions around single-vendor projects that are raging on
>>>> board@ I would have to agree with Daniel's concerns here. Projects that
>>>> are heavily dominated by a single vendor/company/organization
>>>> historically cause problems over time.
>>>
>>> I think that other discussion addresses a very different set of problems.
>>>
>>>> Is there a huge rush to get this project graduated?
>>>
>>> I'd rather flip your argument around and say: at this point sitting in
>> the
>>> Incubator adds no value to the project nor does it teach anything
>>> new or useful to its PPMC or a community at large.
>>
>> If it turns the project into a more diverse/dispersed community, I'd say
>> that's added value. We can argue all night whether that's up to the
>> IPMC, the project or the board to figure out, I'm not sure we'll agree
>> there :)
>>
>>>
>>>> Surely we serve the
>>>> Foundation, and this project, better, by ensuring that this problem
>>>> (and, yes, it's a problem) is addressed before we grant them TLP status?
>>>
>>> I disagree. The Incubator is a place to make sure that the community
>>> (regardless of its composition) truly understands and practices the
>>> "Apache Way". As has been suggested on this thread by a number of
>>> votes from project's mentors and IPMC members embedded in the
>>> Geode community that mission has been accomplished.
>>>
>>> I see no reason to hold the project hostage over the diversity
>> requirement
>>> simply because it is pointless for IPMC, project and the foundation.
>>
>> Except it's not pointless for the foundation, we've seen that. we're
>> seeing that right now with several projects that either die completely
>> or take a very wrong turn because someone higher up the food chain
>> thinks otherwise about the project(s), and that also

Re: [VOTE] Graduate Apache Geode (incubating)

[Daniel Gruno]

On 11/08/2016 11:43 PM, Konstantin Boudnik wrote:
> Besides, last time I checked there's no such thing as "diversity requirement"
> in the graduation.  It is indeed being asked here and there, but so far it
> isn't an official IPMC requirement.

It's very prominently displayed in our graduation guideline.
http://incubator.apache.org/guides/graduation.html#community

> 
> And I'd hate to make a "diversity scape-goat" out of the project that has
> created a very welcome environment!
> 
> Cos
>  
> On Tue, Nov 08, 2016 at 02:14PM, Roman Shaposhnik wrote:
>> On Tue, Nov 8, 2016 at 1:54 PM, Rich Bowen <rbo...@rcbowen.com> wrote:
>>>
>>>
>>> On 11/07/2016 10:05 PM, Niall Pemberton wrote:
>>>> On Mon, Nov 7, 2016 at 6:34 PM, Daniel Gruno <humbed...@apache.org> wrote:
>>>>
>>>>>> I was looking at Snoot, and some figures jumped at me.
>>>>>>
>>>>>> Is the Podling (and the IPMC) satisfied that there is no concern with
>>>>>> people affiliated with a single company providing more than 90% of all
>>>>>> commits over the past year and, as far as I can tell, the vast majority
>>>>>> of tickets and email, as well as a 73% stake in the proposed PMC?
>>>>>>
>>>>>> Is the IPMC satisfied that, should this company opt to not further spend
>>>>>> resources on this project, that the project would still be as viable?
>>>>>>
>>>> Hi Daniel,
>>>>
>>>> I've observed this project since it joined the incubator and they've worked
>>>> hard to create an open and welcoming community and to fix all the issues
>>>> raised that could be barriers to their graduation.
>>>>
>>>> In terms of percentages, these things have been debated previously in
>>>> graduation of projects such as Ignite, Flume, Tez etc and I'm not going to
>>>> repeat the arguments from those discussions. Geode would be better with
>>>> served with a wider community, but I think what matters is 1) have they
>>>> demonstrated the behaviors we expect and 2) are they moving in the right
>>>> direction. Geode is a great community and a pleasure to be involved with
>>>> and I would say yes to both of these. I believe they are going in the right
>>>> direction to make this project less dependent on one company and except to
>>>> change the percentages you've pointed out, theres no purpose left for them
>>>> being in the incubator. They've shown that they can manage themselves and
>>>> theres enough independent oversight to mitigate concerns which is why I
>>>> think we should vote for them to graduate.
>>>
>>> Given the discussions around single-vendor projects that are raging on
>>> board@ I would have to agree with Daniel's concerns here. Projects that
>>> are heavily dominated by a single vendor/company/organization
>>> historically cause problems over time.
>>
>> I think that other discussion addresses a very different set of problems.
>>
>>> Is there a huge rush to get this project graduated?
>>
>> I'd rather flip your argument around and say: at this point sitting in the
>> Incubator adds no value to the project nor does it teach anything
>> new or useful to its PPMC or a community at large.
>>
>>> Surely we serve the
>>> Foundation, and this project, better, by ensuring that this problem
>>> (and, yes, it's a problem) is addressed before we grant them TLP status?
>>
>> I disagree. The Incubator is a place to make sure that the community
>> (regardless of its composition) truly understands and practices the
>> "Apache Way". As has been suggested on this thread by a number of
>> votes from project's mentors and IPMC members embedded in the
>> Geode community that mission has been accomplished.
>>
>> I see no reason to hold the project hostage over the diversity requirement
>> simply because it is pointless for IPMC, project and the foundation.
>>
>>> I'm personally less concerned with the sustainability of the project
>>> should the company opt out of working on the project, and more concerned
>>> with the kind of monoculture "we own it" problems that we're starting to
>>> see crop up in other projects that were allowed to graduate without
>>> building the community first.
>>
>> Then you really should be voting "yes" on this thread. There's a good number
>> of us on IPMC who believe that "we own it" is really not a problem with this
>> community.
>>
>> Thanks,
>> Roman.
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Graduate Apache Geode (incubating)

[Daniel Gruno]

On 11/08/2016 11:14 PM, Roman Shaposhnik wrote:
> On Tue, Nov 8, 2016 at 1:54 PM, Rich Bowen <rbo...@rcbowen.com> wrote:
>>
>>
>> On 11/07/2016 10:05 PM, Niall Pemberton wrote:
>>> On Mon, Nov 7, 2016 at 6:34 PM, Daniel Gruno <humbed...@apache.org> wrote:
>>>
>>>>> I was looking at Snoot, and some figures jumped at me.
>>>>>
>>>>> Is the Podling (and the IPMC) satisfied that there is no concern with
>>>>> people affiliated with a single company providing more than 90% of all
>>>>> commits over the past year and, as far as I can tell, the vast majority
>>>>> of tickets and email, as well as a 73% stake in the proposed PMC?
>>>>>
>>>>> Is the IPMC satisfied that, should this company opt to not further spend
>>>>> resources on this project, that the project would still be as viable?
>>>>>
>>> Hi Daniel,
>>>
>>> I've observed this project since it joined the incubator and they've worked
>>> hard to create an open and welcoming community and to fix all the issues
>>> raised that could be barriers to their graduation.
>>>
>>> In terms of percentages, these things have been debated previously in
>>> graduation of projects such as Ignite, Flume, Tez etc and I'm not going to
>>> repeat the arguments from those discussions. Geode would be better with
>>> served with a wider community, but I think what matters is 1) have they
>>> demonstrated the behaviors we expect and 2) are they moving in the right
>>> direction. Geode is a great community and a pleasure to be involved with
>>> and I would say yes to both of these. I believe they are going in the right
>>> direction to make this project less dependent on one company and except to
>>> change the percentages you've pointed out, theres no purpose left for them
>>> being in the incubator. They've shown that they can manage themselves and
>>> theres enough independent oversight to mitigate concerns which is why I
>>> think we should vote for them to graduate.
>>
>> Given the discussions around single-vendor projects that are raging on
>> board@ I would have to agree with Daniel's concerns here. Projects that
>> are heavily dominated by a single vendor/company/organization
>> historically cause problems over time.
> 
> I think that other discussion addresses a very different set of problems.
> 
>> Is there a huge rush to get this project graduated?
> 
> I'd rather flip your argument around and say: at this point sitting in the
> Incubator adds no value to the project nor does it teach anything
> new or useful to its PPMC or a community at large.

If it turns the project into a more diverse/dispersed community, I'd say
that's added value. We can argue all night whether that's up to the
IPMC, the project or the board to figure out, I'm not sure we'll agree
there :)

> 
>> Surely we serve the
>> Foundation, and this project, better, by ensuring that this problem
>> (and, yes, it's a problem) is addressed before we grant them TLP status?
> 
> I disagree. The Incubator is a place to make sure that the community
> (regardless of its composition) truly understands and practices the
> "Apache Way". As has been suggested on this thread by a number of
> votes from project's mentors and IPMC members embedded in the
> Geode community that mission has been accomplished.
> 
> I see no reason to hold the project hostage over the diversity requirement
> simply because it is pointless for IPMC, project and the foundation.

Except it's not pointless for the foundation, we've seen that. we're
seeing that right now with several projects that either die completely
or take a very wrong turn because someone higher up the food chain
thinks otherwise about the project(s), and that also hurts the
foundation - let's not pretend that never happens. I can't say whether
this would be true for Geode (how would I know?), but a 96+% chunk of
all contributions coming from people affiliated with a single company is
worrisome to me.

> 
>> I'm personally less concerned with the sustainability of the project
>> should the company opt out of working on the project, and more concerned
>> with the kind of monoculture "we own it" problems that we're starting to
>> see crop up in other projects that were allowed to graduate without
>> building the community first.
> 
> Then you really should be voting "yes" on this thread. There's a good number
> of us on IPMC who believe that "we own it" is really not a problem with this
> community.

I'd say Rich should vote what

Re: [VOTE] Graduate Apache Geode (incubating)

[Daniel Gruno]

I was looking at Snoot, and some figures jumped at me.

Is the Podling (and the IPMC) satisfied that there is no concern with
people affiliated with a single company providing more than 90% of all
commits over the past year and, as far as I can tell, the vast majority
of tickets and email, as well as a 73% stake in the proposed PMC?

Is the IPMC satisfied that, should this company opt to not further spend
resources on this project, that the project would still be as viable?

With regards,
Daniel.

On 11/07/2016 07:17 PM, Mattmann, Chris A (3010) wrote:
> +1 (binding). Great work!
> 
> ++
> Chris Mattmann, Ph.D.
> Principal Data Scientist, Engineering Administrative Office (3010)
> Manager, Open Source Projects Formulation and Development Office (8212)
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 180-503E, Mailstop: 180-502
> Email: chris.a.mattm...@nasa.gov
> WWW:  http://sunset.usc.edu/~mattmann/
> ++
> Director, Information Retrieval and Data Science Group (IRDS)
> Adjunct Associate Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> WWW: http://irds.usc.edu/
> ++
>  
> 
> On 11/7/16, 10:16 AM, "gch...@gmail.com on behalf of Greg Chase" 
>  wrote:
> 
> +1!
> 
> On Mon, Nov 7, 2016 at 10:13 AM, Nabarun Nag  wrote:
> 
> > +1
> >
> > On Mon, Nov 7, 2016 at 10:11 AM Mark Bretl  wrote:
> >
> > > +1
> > >
> > > --Mark
> > >
> > > On Sun, Nov 6, 2016 at 11:07 PM, Avinash Dongre 
> > > wrote:
> > >
> > > > +1
> > > >
> > > > On Mon, Nov 7, 2016 at 12:35 PM, Sergio Fernández 
> 
> > > > wrote:
> > > >
> > > > > +1
> > > > >
> > > > > good luck, guys!
> > > > >
> > > > > On Sun, Nov 6, 2016 at 11:42 PM, John D. Ament <
> > johndam...@apache.org>
> > > > > wrote:
> > > > >
> > > > > > +1
> > > > > >
> > > > > > On Nov 6, 2016 15:58, "Roman Shaposhnik" 
> > > wrote:
> > > > > >
> > > > > > > Hi!
> > > > > > >
> > > > > > > after a very positive discussion in the Geode community
> > > > > > > and at the IPMC level:
> > > > > > > http://markmail.org/message/z4prj62hr7rn6cu6
> > > > > > > I'd like to bring the following resolution for a formal vote.
> > > > > > >
> > > > > > > Please vote on the resolution pasted below to graduate
> > > > > > > Apache Geode from the incubator to top level project.
> > > > > > >
> > > > > > > [ ] +1 Graduate Apache Geode from the Incubator.
> > > > > > > [ ] +0 Don't care.
> > > > > > > [ ] -1 Don't graduate Apache Geode from the Incubator 
> because...
> > > > > > >
> > > > > > > This vote will be open for at least 72 hours.
> > > > > > >
> > > > > > > Many thanks to our mentors and everyone else for the support,
> > > > > > > Roman (on behalf of the Apache Geode PPMC).
> > > > > > >
> > > > > > > Resolution:
> > > > > > >
> > > > > > > Establish the Apache Geode Project
> > > > > > >
> > > > > > > WHEREAS, the Board of Directors deems it to be in the best
> > > > > > > interests of the Foundation and consistent with the
> > > > > > > Foundation's purpose to establish a Project Management
> > > > > > > Committee charged with the creation and maintenance of
> > > > > > > open-source software, for distribution at no charge to the
> > > > > > > public, related to a data management platform that provides
> > > > > > > real-time, consistent access to data-intensive applications
> > > > > > > throughout widely distributed cloud architectures.
> > > > > > >
> > > > > > > NOW, THEREFORE, BE IT RESOLVED, that a Project Management
> > > > > > > Committee (PMC), to be known as the "Apache Geode Project",
> > > > > > > be and hereby is established pursuant to Bylaws of the
> > > > > > > Foundation; and be it further
> > > > > > >
> > > > > > > RESOLVED, that the Apache Geode Project be and hereby is
> > > > > > > responsible for the creation and maintenance of software
> > > > > > > related to a data management platform that provides real-time,
> > > > > > > consistent access to data-intensive applications throughout
> > > > > > > widely distributed cloud architectures.
> > > > > > >
> > > > > > > RESOLVED, that the office of "Vice President, Apache Geode" be
> > > > > > > and hereby is created, the person holding such office to
> > > > > > > serve at the direction of the Board of Directors as the chair
> > > > > > > of the Apache Geode Project, and to have primary 
> 

Re: Preliminary NetBeans cost findings

[Daniel Gruno]

On 09/25/2016 06:22 PM, Bertrand Delacretaz wrote:
> Hi Daniel,
> 
> On Sat, Sep 24, 2016 at 12:17 PM, Daniel Gruno <humbed...@apache.org> wrote:
>> ...ballpark costs, bandwidth, machines needed and so forth, and the cliff
>> notes are as follows...
> 
> Thanks very much for this - it is useful and I think we should do that
> for any "big" podling that comes in, from now on.
> 
>> ...Thus, I would submit to the IPMC that they consider asking the board for
>> a budget of roughly $10k per year for the NetBeans project, as well as
>> the additional time required of Infrastructure to implement this into
>> the existing ASF infra
> 
> I don't think asking for budget is a task of the Incubator PMC, I would 
> suggest
> 
> 1. Incubator PMC/infra estimates the cost of new podlings as you did
> 2. Incubator PMC reports those numbers to ASF infra at regular
> intervals, maybe just include them in their monthly reports
> 3. Infra adds the numbers up and if needed asks for more budget based
> on these podlings

I think it very much _is_ the job of the IPMC to argue for increased
spending, as any other project would if they required additional funds
for specific requirements. The IPMC (or rather, a part of it) wants to
add NetBeans as a podling, it should be up to the IPMC to argue the
podling's case.

Infra has already expressed concerns with the costs of the podling
(remember VP Infra started this discussion), it's up to the IPMC to get
an ack that this increased expenditure is okay. I'm not saying this
needs to be voted on by the board (I honestly don't know/care how this
is done), but it should be acked by operations that the added expense is
okay.

> 
> For now, considering that the numbers you indicate won't make a big
> dent in the current infra budget [1] and considering that it's the
> first time we do such an analysis I suggest for the infra team to
> accept decoupling the NetBeans acceptance vote from the details of
> these numbers, and we'll sort out the corresponding budget later at
> the board / infra level.

Infra doesn't decide which podlings the IPMC lets into the fold, but it
may say "sorry, we're not going to offer you the services you require"
if there's no acknowledgement that an increased expense is okay.

The IPMC is, for all I care, free to hold a vote, in which people may
vote -1 if they don't think the budget is sound/warranted. Infra doesn't
have binding votes there :)

My only concern, if you go ahead with a vote before you get an ack, is
that you vote in a podling that may not get the resources it needs.

With regards,
Daniel.

> 
> -Bertrand
> 
> [1] 
> https://www.apache.org/foundation/records/minutes/2015/board_minutes_2015_04_22.txt
> for example
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Preliminary NetBeans cost findings (was: [DISCUSS] Apache NetBeans Incubator Proposal)

[Daniel Gruno]

Hi folks,

I've been going over the requirements for NetBeans infrastructure, it's
ballpark costs, bandwidth, machines needed and so forth, and the cliff
notes are as follows:

- 40-50TB/month in traffic required (mostly downloads+plugins)
- 8-13 machines/VMS are required
- Ballpark hardware costs are between $3k and $10k per year, depending
  on how much we can move to existing infrastructure and how close we
  come to the original setup. The most likely figure we are working with
  is $4.9k, but we should be prepared for a larger cost, just in case.
- The maintenance will be split between infra (downloads, web site, CI,
  new build machines) and the project (services, plugins, statistics),
  which will undoubtedly incur additional costs in terms of infra time
  spent on this, possibly to the tune of $10-20k in the initial phase.

Certain services like the plugins hosting will rely on Legal giving the
go-ahead for it, otherwise we'll have to find other people willing to
host this.

Other items like downloads may be offset by CDN providers offering their
assistance, but we should be prepared for this not being the case from
the beginning, thus the 40-50TB/month. Likewise, some machine costs
may be offset by cloud providers offering services for free.

Thus, I would submit to the IPMC that they consider asking the board for
a budget of roughly $10k per year for the NetBeans project, as well as
the additional time required of Infrastructure to implement this into
the existing ASF infra. As we may be able to pool resources and utilize
the new hardware for multiple projects, the cost may go down in the
coming years, but this is the baseline I suggest we consider when
approving NetBeans as a new podling.

With regards,
Daniel.


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Daniel Gruno]

On 09/15/2016 02:15 PM, Bertrand Delacretaz wrote:
> Hi Incubator PMC,
> 
> On Tue, Sep 13, 2016 at 9:40 AM, Geertjan Wielenga
> <geertjan.wiele...@googlemail.com> wrote:
>> ... https://wiki.apache.org/incubator/NetBeansProposal ...
> 
> At this point I ask anyone with concerns or questions that haven't
> been addressed so far and would prevent us from voting on this
> proposal to chime in.
> 
> Based on the discussions in this thread we have added Mark Struberg
> and Jim Jagielski to the proposal as mentors. Daniel Gruno mentioned
> the need for someone from ASF infra as a mentor, if needed it's easy
> to add a mentor later, or Daniel just confirm if you want to join.
> Emmanuel Lécharny was unsure and hasn't confirmed AFAICS, he can also
> be removed from the list later on easily if he wants to leave, that's
> no big deal.

Seeing as no one else from that PMC chimed in, I guess I'll be the
punching bag here, Bertrand :) Count me in.

With regards,
Daniel.

> 
> I have changed the SIR03 special infrastructure requirement (migration
> of plugins.netbeans.org) to exclude it from the incubation process as
> discussed here - we have envisioned possible solutions and realized
> that incubating NetBeans is not necessarily dependent on that, and I
> think the project can address this in due time.
> 
> Are there other things to discuss that might affect our vote on
> accepting NetBeans?
> 
> I'm planning to start the vote in about 24 hours unless things still
> need to be discussed.
> 
> -Bertrand
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Daniel Gruno]

On 09/14/2016 03:51 PM, Wade Chandler wrote:
>>
>> On Sep 14, 2016, at 09:38, Wade Chandler <cons...@wadechandler.com> wrote:
>>
>>>
>>> On Sep 14, 2016, at 09:28, Daniel Gruno <humbed...@apache.org 
>>> <mailto:humbed...@apache.org>> wrote:
>>>
>>> On 09/14/2016 03:17 PM, Geertjan Wielenga wrote:
>>>> NetBeans.org <http://netbeans.org/> has forums that mirror the mailing 
>>>> lists (well, not always,
>>>> sometimes we've had syncing problems). My feeling is that since Apache
>>>> doesn't support forums, we could simply drop them. No need to convert the
>>>> forums to mailing lists, instead our mailing lists will need to be moved if
>>>> possible to Apache's mailing lists, while the forums can simply be dropped.
>>>> That would be my proposal for this, though some NetBeans community members
>>>> may differ and indeed it will be good to explicitly list this so that we
>>>> can track it when moving forward into incubation.
>>>
>>> While not a forum in the traditional sense, lists.apache.org 
>>> <http://lists.apache.org/> does offer
>>> interacting with lists without having to use a separate mail client. You
>>> just log in via oauth and then read/write stuff :)
>>>
>>
>> Wow…all these years using the Apache lists in some way or another I never 
>> knew about that. That is pretty cool, and I do think it could replace 
>> forums. Certainly users have to get used to anything new. I think the Apache 
>> OAuth button, and the Mozilla Persona buttons, should perhaps be slightly 
>> different. The button itself could read “Apache Commiters Login” with a 
>> sub-link bottom right justified “using Apache OAuth” and “Apache Users 
>> Login” and a sub-link bottom right justified “using Mozilla Persona”; just 
>> to make it more intuitive, but certainly works, and is awesome! I had never 
>> used Persona, but it was easy to setup and get going.
>>
> 
> Hmm, so it seems if I’m subscribed to a list the message goes through without 
> a hiccup, but if not, then it takes a good bit if it will be delivered at 
> all. Does anyone know if you are not subscribed to a list if you can start 
> conversations in other lists from lists.apache.org <http://lists.apache.org/>?


External provider aside, Pony Mail is an Apache project, so people are
welcome to help improve it :) Jump in and...do stuff :)

With regards,
Daniel.

> 
> Thanks,
> 
> Wade
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Daniel Gruno]

On 09/14/2016 03:17 PM, Geertjan Wielenga wrote:
> NetBeans.org has forums that mirror the mailing lists (well, not always,
> sometimes we've had syncing problems). My feeling is that since Apache
> doesn't support forums, we could simply drop them. No need to convert the
> forums to mailing lists, instead our mailing lists will need to be moved if
> possible to Apache's mailing lists, while the forums can simply be dropped.
> That would be my proposal for this, though some NetBeans community members
> may differ and indeed it will be good to explicitly list this so that we
> can track it when moving forward into incubation.

While not a forum in the traditional sense, lists.apache.org does offer
interacting with lists without having to use a separate mail client. You
just log in via oauth and then read/write stuff :)

With regards,
Daniel.

> 
> On Tue, Sep 13, 2016 at 4:35 PM, Raphael Bircher <rbircherapa...@gmail.com>
> wrote:
> 
>> Hi all
>>
>> They have also a fairly big forum at http://forums.netbeans.org/ wich
>> is not listed on the proposal
>>
>> Regards Raphael
>>
>> On Tue, Sep 13, 2016 at 4:29 PM, Bertrand Delacretaz
>> <bdelacre...@apache.org> wrote:
>>> Hi Daniel,
>>>
>>> On Tue, Sep 13, 2016 at 3:17 PM, Daniel Gruno <humbed...@apache.org>
>> wrote:
>>>> ...Might I suggest, that if the project has a wider-than-normal
>>>> infrastructure requirement, that it accepts a member of the infra PMC as
>>>> a mentor or PPMC member (whatever fits best) so as to have a liaison
>>>> that knows what is possible to provide and what routes to take?...
>>>
>>> That's a good idea, we are open to your suggestions, I think an infra
>>> mentor makes absolute sense here.
>>>
>>> Mark Struberg is a mentor already, AFAIK he is involved infra but if
>>> you want someone else that's possible of course.
>>>
>>> -Bertrand
>>>
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Daniel Gruno]

On 09/13/2016 11:48 AM, Bertrand Delacretaz wrote:
> Hi Daniel,
> 
> On Tue, Sep 13, 2016 at 11:19 AM, Daniel Gruno <humbed...@apache.org> wrote:
>> What is the expected impact on infrastructure here?...
> 
> I'll let Geertjan or someone else who's familiar with the existing
> setups comment on the below list, from the Special Infrastructure
> Requests in the proposal (I have numbered them now for clarity).
> 
> Instead of "migrating internal Oracle release infrastructure" for
> example we might discuss build/release requirements that might be
> specific to NetBeans, I'm not sure if reproducing existing
> infrastructure matches the ASF's infra view of the world. So maybe
> what we need at this point is a rough outline of the expectations of
> the current NetBeans team.
> 
>> SIR01 Migration of large existing Mercurial repository to Apache Git
>> SIR02 Migration of internal Oracle release infrastructure to Apache 
>> infrastructure
>> SIR03 Migration of plugin publication system, plugins.netbeans.org, to 
>> Apache infrastructure
>> SIR04 Migration of website and related content management system to Apache 
>> infrastructure
>> SIR05 Evaluation and identification of other NetBeans infrastructure to be 
>> migrated to Apache infastructures
> 
> -Bertrand
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 

Might I suggest, that if the project has a wider-than-normal
infrastructure requirement, that it accepts a member of the infra PMC as
a mentor or PPMC member (whatever fits best) so as to have a liaison
that knows what is possible to provide and what routes to take? We often
have projects that cause infra headaches because they make decisions
without knowing the full scope of work that is required to fulfill them,
I think it would be better to nip these in the bud instead and not have
too many headaches.

With regards,
Daniel.


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] Apache NetBeans Incubator Proposal

[Daniel Gruno]

What is the expected impact on infrastructure here? I see a lot of
mentions of moving existing infrastructure to the ASF, I see very little
about what it really entails and how large it is.

For instance, what is plugins.netbeans.org and what's the setup there like?

With regards,
Daniel.

On 09/13/2016 09:40 AM, Geertjan Wielenga wrote:
> Hello everyone,
> 
> Attached to this message is a proposed new project - Apache NetBeans, a
> development environment, tooling platform, and application framework.
> 
> The text of the proposal is included below. Additionally, the proposal is
> in draft form on the Wiki, where we will make any required changes:
> 
> https://wiki.apache.org/incubator/NetBeansProposal
> 
> We look forward to your feedback and input.
> 
> Kind regards,
> 
> Geertjan
> 
> 
> 
> = NetBeans Proposal =
> 
> == Abstract ==
> 
> NetBeans is an open source development environment, tooling platform,
> and application framework, used by 1.5 million individuals each month.
> 
> == Proposal ==
> 
> Apache NetBeans will continue to focus on the areas it has focused on
> while sponsored by Sun Microsystems and Oracle. It will continue to
> primarily focus on providing tools for the Java ecosystem, while also
> being focused on tools for other ecosystems, languages and
> technologies, such as JavaScript, PHP, and C/C++. It will continue to
> actively support its community by means of mailing lists, tutorials,
> and documentation.
> 
> == Background ==
> 
> NetBeans started in 1995/96 in Prague, in the Czech Republic, as a
> student project. Sun Microsystems acquired and open sourced it in 2000
> and, with the acquisition of Sun Microsystems by Oracle in 2010,
> became part of Oracle. Throughout its history in Sun Microsystems and
> Oracle, NetBeans has been free and open source and has been leveraged
> by its sponsor as a mechanism for driving the Java ecosystem forward.
> 
> == Rationale ==
> 
> Although NetBeans is already open source, moving it to a neutral place
> like Apache, with its strong governance model, is expected to help get
> more contributions from various organizations. For example, large
> companies are using NetBeans as an application framework to build
> internal or commercial applications and are much more likely to
> contribute to it once it moves to neutral Apache ground. At the same
> time, though Oracle will relinquish its control over NetBeans,
> individual contributors from Oracle are expected to continue
> contributing to NetBeans after it has been contributed to Apache,
> together with individual contributors from other organizations, as
> well as self-employed individual contributors.
> 
> == Initial Goals ==
> 
> The initial goals of the NetBeans contribution under the Apache
> umbrella are to establish a new home for an already fully functioning
> project and to open up the governance model so as to simplify and
> streamline contributions from the community.
> 
> == Current Status ==
> 
> Meritocracy: NetBeans has been run by Oracle, with the majority of
> code contributions coming from Oracle. The specific reason for moving
> to Apache is to expand the diversity of contributors and to increase
> the level of meritocracy in NetBeans. Apache NetBeans will be actively
> seeking new contributors and will welcome them warmly and provide a
> friendly and productive environment for purposes of providing a
> development environment, tooling environment, and application
> framework.
> 
> Community: NetBeans has approximately 1.5 million active users around
> the world, in extremely diverse structures and organizations. NetBeans
> is used by teachers and instructors at schools and universities to
> teach Java and other languages. It is used by students as an
> educational tool. It is used by large organizations who base their
> software on the application framework beneath NetBeans. It is used by
> web developers for creating web sites and by developers using a range
> of tools, languages, and technologies to be productive and efficient
> software developers.
> 
> Core Developers: The core developers will come from a range of
> organizations, including Oracle, which will continue its investment in
> NetBeans.
> 
> Alignment: The application framework is the basis of a range of
> mission critical scientific software at large organizations in
> defense, aerospace, logistics, and research, such as at Boeing,
> Airbus, NASA, and NATO.
> 
> == Known Risks ==
> 
> Orphaned Products: The community proposing NetBeans for incubation is
> strong and vibrant. The size and diversity of the community is a
> guarantee against the project being orphaned.
> 
> Inexperience with Open Source: NetBeans has been free and open source
> since the early days of its sponsorship by Sun Microsystems. Though
> some in the NetBeans community may have worked on Apache projects, the
> majority who haven't are well versed in the principles of open source.
> 
> Homogenous Developers: Individual contributors 

Re: [VOTE] Apache Annotator

[Daniel Gruno]

Obviously a binding +1 from me :)

With regards,
Daniel.

On 08/08/2016 09:41 PM, Benjamin Young wrote:
> Hi all!
> 
> Thanks for everyone who's contributed to the discussion around the Apache 
> Annotator proposal:
> https://wiki.apache.org/incubator/AnnotatorProposal
> 
> From what our Champion tells me, we're now ready to go to a vote!
> 
> We have a long and eager list of contributors, a key focus around existing 
> code and completed W3C standards for annotation, and a growing world of 
> annotation-centric tools on and off the Web (including NLP and machine 
> learning).
> 
> I'd also like to say a quick "thanks" to our Champion to our Mentors for 
> their input and help along the way.
> 
> Cheers!
> Benjamin
> --
> http://bigbluehat.com/
> http://linkedin.com/in/benjaminyoung
> 
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [DISCUSS] move the Incubator Report section to SVN or GIT?

[Daniel Gruno]

On 08/08/2016 10:03 AM, Christopher wrote:
> On Mon, Aug 8, 2016 at 3:34 AM Mark Struberg 
> wrote:
> 
>> Another possible option would be to move it to our CMS.
>>
>> That would bring us SVN for the people who prefer vi, but also a graphical
>> UI for editing.
>> And it would make people make familiar with our CMS.
> 
> 
> I prefer the Wiki over CMS. I find CMS to be clumsy and annoying. I'm glad
> the projects I'm involved in no longer use (or never have used) it. I'd be
> willing to use SVN (reluctantly, and with git-svn), but if it were tied to
> CMS, there'd still be the second publication step using CMS which would be
> annoying.
> 
> There is something to be said about the low barrier to entry of a Wiki,
> though. Anybody can do it. It's the least developer-centric way of doing
> things out there. I know CMS tries to be that, but it hasn't quite
> succeeded.
> 

Why not make a whimsy-like application for this? That would ensure that
you are only meddling with the specific sub-section of the report you
are working on, and would allow multiple people to work on the report at
the same time, maybe even have a simple sign-off button for mentors?

Shouldn't take long to make that :)

With regards,
Daniel.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[RESULT] [VOTE] Release Apache Pony Mail (Incubating) 0.9.RC2 as 0.9

[Daniel Gruno]

Binding +1s:
 - Daniel Gruno
 - Josh Elser
 - John D Ament
 - Justin McClean
 - Sergio Fernández

Non-binding +1s:  None
0s: None
-1s: None

With 5 binding +1s and no -1s, the vote has passed.
I will prepare the release and announcement once my break day is over :)

With regards,
Daniel.

On 07/17/2016 11:08 AM, Daniel Gruno wrote:
> Hello IPMC and lurkers,
> This is a vote to release Apache Pony Mail (Incubating) 0.9.RC2 as 0.9.
> 
> Podling vote thread is at:
> https://lists.apache.org/thread.html/9fd77b14753bbde462bea06fc2e1c03d5cf5a89cea2fabd6751d805a@%3Cdev.ponymail.apache.org%3E
> 
> The release artefact can be found at:
> https://dist.apache.org/repos/dist/dev/incubator/ponymail/
> Specifically, this is a vote on
> https://dist.apache.org/repos/dist/dev/incubator/ponymail/apache-pony-mail-0.9.RC2-incubating.tar.gz
> 
> The git hash for the current 0.9.RC2 head is:
> 116797982cec1e483349ed48a397e0b0cdad5b1d
> 
> Signing keys etc can be found in the same dir as the RC (
> https://dist.apache.org/repos/dist/dev/incubator/ponymail/KEYS )
> 
> Change-log for 0.9 can be found at:
> https://git1-us-west.apache.org/repos/asf?p=incubator-ponymail.git;a=blob;f=CHANGELOG.md
> 
> With regards,
> Daniel.
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Pony Mail (Incubating) 0.9.RC2 as 0.9

[Daniel Gruno]

On 07/17/2016 06:03 PM, Josh Elser wrote:
> +1 (binding)

Yay!

> 
> * Verified SHA1 and sig
> * DISCLAIMER present
> * LICENSE and NOTICE look good after glance through source release
> * Didn't find anything to explicitly build or any automated tests to run
> (maybe I missed them?)

Pony Mail is strange (in ASF terms) in that there is nothing to build.
It just runs :)

We'd love some tests for the UI/UX, but...from what I gather, you have
to be slightly mad to get into UI/UX testing short of manually testing
as a human being. We are however looking into that (see dev@ponymail).

> * Verified commit ID in repo
> 
> Things to fix for your next release (I don't _think_ these need to block
> this release -- but would happily be corrected)
> 
> * What about the images in site/images? Were these generated from an SVG
> -- what are their origins?

This is home grown stuff. The Pony Mail logo itself should be in SVG
somewhere (if not in that repo, then in the site repo). I don't think
there are any "sources" for the rest, maybe I have some Gimp/Photoshop
files on my old hard-drive.


> * Need license headers:
> - site/js/dev/combine.sh
> - dockerfiles/debian/Dockerfile
> - dockerfiles/ponymail_httpd_docker.conf
> - docs/*
> - CHANGELOG.md

Change-logs do typically not (at least in the ASF projects I've been
involved with) carry a license header (who is going to use it??).
http://www.apache.org/legal/src-headers.html#faq-exceptions allows for
this exception, I believe. We believe the same could apply to the docs/*
stuff, which is why we haven't done it yet (we felt that it "cluttered"
the docs, making them harder to read, and also that it was clear from
them what they related to. The policy page states: "The expectation is
that these files make it obvious which product they relate to") but
we'll err on placing a short form license header in the next release :).


> 
> Assorted other comments
> 
> * Any instructions on the provided Dockerfile? :)
> - I did get it running, but can't seem to access it via my host
> machine, only from within the container. Probably something I did (or
> didn't do), but this seems like it would be a nice entry-point for users
> to mess around.

I hate Docker - there, I said it :p
There is some way to finagle your way to open a port in the container
and bind it to a port on your local machine, but I forget how, sorry.
If I figure it out, I'll put it in the docs for next release (or someone
else could do it, patches welcome :) ).

> 
> Daniel Gruno wrote:
>> Hello IPMC and lurkers,
>> This is a vote to release Apache Pony Mail (Incubating) 0.9.RC2 as 0.9.
>>
>> Podling vote thread is at:
>> https://lists.apache.org/thread.html/9fd77b14753bbde462bea06fc2e1c03d5cf5a89cea2fabd6751d805a@%3Cdev.ponymail.apache.org%3E
>>
>>
>> The release artefact can be found at:
>> https://dist.apache.org/repos/dist/dev/incubator/ponymail/
>> Specifically, this is a vote on
>> https://dist.apache.org/repos/dist/dev/incubator/ponymail/apache-pony-mail-0.9.RC2-incubating.tar.gz
>>
>>
>> The git hash for the current 0.9.RC2 head is:
>> 116797982cec1e483349ed48a397e0b0cdad5b1d
>>
>> Signing keys etc can be found in the same dir as the RC (
>> https://dist.apache.org/repos/dist/dev/incubator/ponymail/KEYS )
>>
>> Change-log for 0.9 can be found at:
>> https://git1-us-west.apache.org/repos/asf?p=incubator-ponymail.git;a=blob;f=CHANGELOG.md
>>
>>
>> With regards,
>> Daniel.
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Release Apache Pony Mail (Incubating) 0.9.RC2 as 0.9

[Daniel Gruno]

I should note that this vote will run for 72 hours.
Also, it currently carries one binding IPMC vote (me).

With regards,
Daniel.

On 07/17/2016 11:08 AM, Daniel Gruno wrote:
> Hello IPMC and lurkers,
> This is a vote to release Apache Pony Mail (Incubating) 0.9.RC2 as 0.9.
> 
> Podling vote thread is at:
> https://lists.apache.org/thread.html/9fd77b14753bbde462bea06fc2e1c03d5cf5a89cea2fabd6751d805a@%3Cdev.ponymail.apache.org%3E
> 
> The release artefact can be found at:
> https://dist.apache.org/repos/dist/dev/incubator/ponymail/
> Specifically, this is a vote on
> https://dist.apache.org/repos/dist/dev/incubator/ponymail/apache-pony-mail-0.9.RC2-incubating.tar.gz
> 
> The git hash for the current 0.9.RC2 head is:
> 116797982cec1e483349ed48a397e0b0cdad5b1d
> 
> Signing keys etc can be found in the same dir as the RC (
> https://dist.apache.org/repos/dist/dev/incubator/ponymail/KEYS )
> 
> Change-log for 0.9 can be found at:
> https://git1-us-west.apache.org/repos/asf?p=incubator-ponymail.git;a=blob;f=CHANGELOG.md
> 
> With regards,
> Daniel.
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[VOTE] Release Apache Pony Mail (Incubating) 0.9.RC2 as 0.9

[Daniel Gruno]

Hello IPMC and lurkers,
This is a vote to release Apache Pony Mail (Incubating) 0.9.RC2 as 0.9.

Podling vote thread is at:
https://lists.apache.org/thread.html/9fd77b14753bbde462bea06fc2e1c03d5cf5a89cea2fabd6751d805a@%3Cdev.ponymail.apache.org%3E

The release artefact can be found at:
https://dist.apache.org/repos/dist/dev/incubator/ponymail/
Specifically, this is a vote on
https://dist.apache.org/repos/dist/dev/incubator/ponymail/apache-pony-mail-0.9.RC2-incubating.tar.gz

The git hash for the current 0.9.RC2 head is:
116797982cec1e483349ed48a397e0b0cdad5b1d

Signing keys etc can be found in the same dir as the RC (
https://dist.apache.org/repos/dist/dev/incubator/ponymail/KEYS )

Change-log for 0.9 can be found at:
https://git1-us-west.apache.org/repos/asf?p=incubator-ponymail.git;a=blob;f=CHANGELOG.md

With regards,
Daniel.

-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: [VOTE] Accept Traffic Control into the Apache Incubator

[Daniel Gruno]

+1 (binding) also.

With regards,
Daniel.

On 07/09/2016 10:08 AM, Nick Kew wrote:
> On Fri, 2016-07-08 at 18:16 -0600, Jan van Doorn wrote:
> 
>> I don't think the association with ATS would hold us back, but I do think it 
>> could give prospective users of Traffic Control the impression that it only 
>> works with ATS. This is true now, but won't be in the future.
> 
> I'm not sure a bit of internal organisation will make much difference
> once you start listing TC+TS and TC+Other as equally valid options.
> But I don't want to make an issue of it.
> 
>> Only one or two people actively work on both projects, the development 
>> communities are mostly separate.
> 
> OK, thanks.
> 
>> I'm not familiar with the HTTPD and APR history, is there a lesson we should 
>> learn from that?
> 
> The main issue we've found is that with a close relationship and with
> a large overlap between the dev teams, we've often found a development
> in HTTPD driving one in APR, even to the point of "we need a new APR
> release that'll support [new HTTPD feature]".  At the same time, the
> original reason for the separation - that APR has applications outside
> httpd (Apache SVN being one such) - works well.
> 
> On reflection, you probably have a cleaner separation than that anyway.
> 
> +1 (binding) to your vote.
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: *.incubator.apache.org and lists.apache.org?

[Daniel Gruno]

On 06/28/2016 04:19 PM, John D. Ament wrote:

On Tue, Jun 28, 2016 at 10:17 AM Daniel Gruno <humbed...@apache.org> wrote:


Let's keep the two things separate: There's Pony Mail, and then there's
lists.apache.org which is a specific installation of it.

In the specific agreement we have about lists.apache.org, we wanted the
'.incubator' part of the mailing list IDs stripped, so we wouldn't have
to fix that every single time on graduation - it would just work when
projects became TLPs.

I realize this poses an issue with the subscribe button, but it's
something we (infra) are willing to live with for the time being, if it
means less overall work for an understaffed infra team.

We could, as I said on the JIRA ticket you raised, have
$podling.apache.org be a valid MX record from the beginning, but I'm
sure someone on this list will protest ;-)



You're incorrect.


I merely said 'protest', I'm sure if we wait long enough, we can get 
someone to do that :p I am not saying it's against policy. However, it 
hasn't been formally requested (to the best of my knowledge), which 
would be a good thing, so infra knows how to set up podlings in the 
future, should the IPMC with for this to work like you say.


This was discussed previously on this mailing list, and

the lazy consensus was that the IPMC is fine if both $podling.a.o and
$podling.incubator.a.o work, as long as the podling website includes proper
incubator branding.

So I'm not sure what needs to be done to enable the MX record, I can hold a
more formal vote on the subject if lazy consensus isn't enough.

John




So, in a way, we're caught between what's practical and what's proper.

With regards,
Daniel.

On 06/28/2016 04:02 PM, Stian Soiland-Reyes wrote:

Hi,

I'm helping the new Juneau podling, and some confusion came because

https://lists.apache.org/list.html?d...@juneau.apache.org

claims the address is d...@juneau.apache.org

and lists dev-subscr...@juneau.apache.org as it's "Subscribe" address.


Reply-To on the list is however d...@juneau.incubator.apache.org, as
you would expect.


Generally for podling both address styles work - and we just keep the
non-incubator address "secret". However in this case the DNS has not
been updated and sending to d...@juneao.apache.org fails.

The new lists.apache.org interface makes it a bit confusing for
committers and specially newcomers.


Are we moving to using the style dev@$project.apache.org straight away
for new podlings, or is this simply a bug in Ponymail?   (We have
earlier discussed this as a possibility for website URLs)

I've raised the bug
https://github.com/apache/incubator-ponymail/issues/100 but wanted to
check here as well.




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org







-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: *.incubator.apache.org and lists.apache.org?

[Daniel Gruno]

Let's keep the two things separate: There's Pony Mail, and then there's 
lists.apache.org which is a specific installation of it.


In the specific agreement we have about lists.apache.org, we wanted the 
'.incubator' part of the mailing list IDs stripped, so we wouldn't have 
to fix that every single time on graduation - it would just work when 
projects became TLPs.


I realize this poses an issue with the subscribe button, but it's 
something we (infra) are willing to live with for the time being, if it 
means less overall work for an understaffed infra team.


We could, as I said on the JIRA ticket you raised, have 
$podling.apache.org be a valid MX record from the beginning, but I'm 
sure someone on this list will protest ;-)


So, in a way, we're caught between what's practical and what's proper.

With regards,
Daniel.

On 06/28/2016 04:02 PM, Stian Soiland-Reyes wrote:

Hi,

I'm helping the new Juneau podling, and some confusion came because

https://lists.apache.org/list.html?d...@juneau.apache.org

claims the address is d...@juneau.apache.org

and lists dev-subscr...@juneau.apache.org as it's "Subscribe" address.


Reply-To on the list is however d...@juneau.incubator.apache.org, as
you would expect.


Generally for podling both address styles work - and we just keep the
non-incubator address "secret". However in this case the DNS has not
been updated and sending to d...@juneao.apache.org fails.

The new lists.apache.org interface makes it a bit confusing for
committers and specially newcomers.


Are we moving to using the style dev@$project.apache.org straight away
for new podlings, or is this simply a bug in Ponymail?   (We have
earlier discussed this as a possibility for website URLs)

I've raised the bug
https://github.com/apache/incubator-ponymail/issues/100 but wanted to
check here as well.




-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Number of projects in Incubation [was: [VOTE] Release Apache Mynewt 0.9.0-incubating-rc1]

[Daniel Gruno]

On 05/28/2016 05:31 AM, Niclas Hedhman wrote:
> And where is the sources for that?

https://svn.apache.org/repos/asf/comdev/projects.apache.org/

With regards,
Daniel.

> 
> On Sat, May 28, 2016 at 11:27 AM, Daniel Gruno <humbed...@apache.org> wrote:
> 
>> On 05/28/2016 05:25 AM, Niclas Hedhman wrote:
>>> Thanks Justin,
>>> as always, snapshots in time is not as useful as trending data over
>> time. I
>>> guess it is time to take a look at whimsy.. :-)
>>
>> Or projects.apache.org :) Since there's already an incubator chart there
>> - should be easy to add another one.
>>
>>>
>>> Cheers
>>>
>>> On Sat, May 28, 2016 at 9:38 AM, Justin Mclean <jus...@classsoftware.com
>>>
>>> wrote:
>>>
>>>> Hi,
>>>>
>>>>> An additional graph that would be super-interesting to get is "Months
>> in
>>>>> Incubation" for the current podlings, plotted over time.
>>>>
>>>> Some of the data can be found here [1] (column B)
>>>>
>>>> Thanks,
>>>> Justin
>>>>
>>>> 1. http://incubator.apache.org/clutch.html
>>>>
>>>> -
>>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>>>
>>>>
>>>
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
> 
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

Re: Number of projects in Incubation [was: [VOTE] Release Apache Mynewt 0.9.0-incubating-rc1]

[Daniel Gruno]

On 05/28/2016 05:25 AM, Niclas Hedhman wrote:
> Thanks Justin,
> as always, snapshots in time is not as useful as trending data over time. I
> guess it is time to take a look at whimsy.. :-)

Or projects.apache.org :) Since there's already an incubator chart there
- should be easy to add another one.

> 
> Cheers
> 
> On Sat, May 28, 2016 at 9:38 AM, Justin Mclean 
> wrote:
> 
>> Hi,
>>
>>> An additional graph that would be super-interesting to get is "Months in
>>> Incubation" for the current podlings, plotted over time.
>>
>> Some of the data can be found here [1] (column B)
>>
>> Thanks,
>> Justin
>>
>> 1. http://incubator.apache.org/clutch.html
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
> 
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[RESULT] [VOTE] Accept Pony Mail into the Apache Incubator

[Daniel Gruno]

With a wonderful 26 +1's (21 binding, 5 non-binding),
this vote passes :)

I shall start preparing the podling setup ASAP :)

With regards and neighs,
Daniel.

On 05/27/2016 04:06 PM, Amol Kekre wrote:
> +1 (non-binding)
> 
> Thks
> Amol
> 
> On Fri, May 27, 2016 at 6:35 AM, Shane Curcuru <a...@shanecurcuru.org> wrote:
> 
>> +1 (binding)
>>
>> Daniel Gruno wrote on 5/24/16 1:56 AM:
>>> Since it seems the discussion has died down, I am now calling a vote on
>>> accepting Pony Mail into the Incubator. Sorry in advance for potato.
>>>
>>> This vote will run for the usual 72 hours.
>>>
>>> ### PROPOSAL BELOW ###
>>>
>>> Abstract
>>>
>>> Pony Mail is a mail-archiving, archive viewing, and interaction service,
>>> that can be integrated with many email platforms.
>> ...
>>
>>> Affiliations
>>>
>>> Daniel Gruno - Quenda IvS
>>> Tony Stevenson - pctony ltd, VocalIQ Ltd
>>> Richard Bowen - Redhat, inc.
>>> Ulises Beresi - Datastax, inc.
>>> David P Kendal - Quenda IvS
>>> Francesco Chicchiriccò - Tirasa S.r.l.
>>> Sam Ruby - IBM
>>> Shane Curcuru - IBM(?)
>>> Jim Jagielski - Capital One
>>
>> Please note I will (very, very soon) be independent, as my last day with
>> $Employer is Tuesday, so we should take off my affiliation.
>>
>> Thanks,
>> - Shane
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org

[VOTE] Accept Pony Mail into the Apache Incubator

[Daniel Gruno]

Since it seems the discussion has died down, I am now calling a vote on
accepting Pony Mail into the Incubator. Sorry in advance for potato.

This vote will run for the usual 72 hours.

### PROPOSAL BELOW ###

Abstract

Pony Mail is a mail-archiving, archive viewing, and interaction service,
that can be integrated with many email platforms.

Proposal

Background

Pony Mail began as a response to two things; the lack of diversity in
mailing list archives that are less bureaucratic all-or-nothing and more
fluid way to interact with mailing lists than what is typically offered,
and the lack of a performant system that solves this issue. Modern users
of software want to jump right into a discussion they see, but cannot
normally do so in a mailing list driven environment because of the rules
generally surrounding said environment. Pony Mail, along with a select
handful of newer archive systems, provides an interface that allows
people to just hop into a thread, and take part. Without the need to
subscribe, download the mbox archive, load it into your MTA, and respond.

As Rich writes in a very short essay:

You see a thread in which someone is WRONG ON THE INTERNET! You need to
correct them. How do you do this today? You kinda don't. If you really
wanted, you could download mbox files (and who the hell knows where they
are?) and then try to get them into your mail client (which never works)
and then reply to it. Which will break threading, because you did
something wrong. Then you tear out your hair. PONY MAIL TO THE RESCUE!!!
(sound of hoof beats)

Rationale

One of the oft-heard complaints about Apache's development model is that
mailing lists are an old person's tool, and web-based communication -
forums - are the way to go in the 21st Century. Providing a
full-featured forum-like interface to mailing lists is one goal,while
keeping all of the enormous benefits that mailing lists already provide.
Asecond goal is to provide the ability to "jump in" to a mailing list
conversation - even one that was a while back, without the convolutions
that a mailing list requires. That is, to join this conversation the old
way, one would have had to subscribe to the mailing list, download an
mbox, and import it into ones mail client, in order that I be able to
reply to this message with correct threading. With Pony Mail, one has to
do none of those things, but can simply reply using the Web UI. To us,
this is a HUGE benefit for building community. The requirement to jump
through hoops to join a mailing list conversation drives away a lot of
people (at least, anecdotally, it does) and if we can remove that
barrier I think we'll have an easier time of drawing a new generation
into our projects.

Initial Goals

The initial goals of transitioning to the ASF is to expand and grow both
the Pony codebase and community, and ensure the project's continued
growth and stability through forming a diverse and reliable community,
in which the various facets of developers and contributors help keep the
project up to date with latest developments and technical as well as
social needs.

Current Status

Meritocracy:

The bulk of the code has been written by Daniel Gruno to date, but has
had oversight from other committers, and mentors.

All members of the Pony project and wider community have a deep
understanding and appreciation for the ASF meritocracy ideals, and are
almost solely current ASF Members.

Community:
The community is currently heavily focused within the ASF, and
more specifically the Infrastructure group. This is to be expected given
the nature of how the code came into existence in the first place. It
should be noted that we have started reaching out to other groups who we
know are using mailing list systems and therefore also rely on mailing
list archive interfaces.

Core Developers:

Almost all core developers are ASF members, and are already intimately
familiar with the Apache Way.

Alignment:

Pony will be very in line with ASF practices and processes as many of
the founding members are long term ASF members and committers.

Known Risks

Orphaned products:

We are not aware of any issues with orphaned products related to this
project.

Pony Mail relies on a set of CSS3 templates as well as some very stable
programming languages. We have no reason to believe these would
be orphaned or, should they become orphaned, that it would impact the
development of the project.

Inexperience with Open Source:
Most of the current committers are already ASF members and
committers, we do not believe there to be any concerns around OSS
inexperience.

Homogenous Developers:
While the current mix of people involved in the project spans
several continents with a wide variety of skills and experience, a long
standing relation with the ASF applies to all committers (even the
non-ASF people in this proposal are intimately familiar wi

Re: [PROPOSAL] Pony Mail

[Daniel Gruno]

On 05/21/2016 12:45 AM, John D. Ament wrote:

> 
> It does very clearly.
> 
> If you're looking for more mentors, I'd be happy to help (we recommend 3
> mentors for a podling).  Granted most of the proposed PPMC qualify as
> mentors as well.


You are most welcome to add your name to the proposal :)
My computer decided to wipe all browser cookies (yay!), so I'm a bit
slow to get back on all the sites at the moment, adding yourself would
be faster.

With regards,
Daniel.

> 
> I'd also be interested in helping out, I know quite a bit about
> elasticsearch, can do some UI, and would be interested in picking up more
> lua and python.
> 
> John
> 
> 


-
To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
For additional commands, e-mail: general-h...@incubator.apache.org