Board report feedback

[Justin Mclean]

Hi,

The feedback from the new board report format (i.e. using markdown) was 
positive, so unless there are any objections, we’ll continue with it. Over the 
next couple of days I’ll update the tooling to generate the report in the new 
format.

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

Re: [VOTE] (Re)Release Apache Flagon UserALE.js (Incubating) 1.0.0

[Justin Mclean]

Hi,

> We did not receive any VOTEs from general@ within the 72 hour voting period. 
> Therefore, we are initiating another VOTE on general@, which will last for 72 
> hours.

Voting should late for a minimum of 72 hours or until you get a result, in 
general they no need to call a revote, but just remind your mentors (who are 
IPMC members) and the IPMC that you need votes.

Thanks,
Justin


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

[VOTE] (Re)Release Apache Flagon UserALE.js (Incubating) 1.0.0

[Joshua Poore]

Hello,

On Jun 17th we posted an IPMC VOTE on the (Re)Release of Apache Flagon 
UserALE.js (Incubating) 1.0.0, in accordance with a request by IPMC to 
correctly annotate the release file names.

We did not receive any VOTEs from general@ within the 72 hour voting period. 
Therefore, we are initiating another VOTE on general@, which will last for 72 
hours.

Our community has voted in favor of this release by a majority of +7 in favor, 
0 in favor of additional development and, 0 against the release. This tally 
includes +1 Binding Vote from PPMC. 

WE NEED +2 BINDING VOTES FOR THIS RELEASE VOTE TO PASS. 


VOTE thread:
https://lists.apache.org/thread.html/7a3c960ee54692cd6d88fb88b83c787244bb0e1b4a476050093d3b4a@%3Cdev.flagon.apache.org%3E
 


VOTE thread II (split accidentally to private):
https://lists.apache.org/thread.html/83a96438bd60ea4c0aec2d5f103d68cbb430a44c72ef2d3d0cfe655f@%3Cdev.flagon.apache.org%3E
 


Please VOTE on Apache FLAGON UserALE.js 1.0.0 Release Candidate #3:

We solved 50 issues:
https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12341550=Text=12320621=Create_token=A5KQ-2QAV-T4JA-FDED%7Cd2c9eccb98c0590b13b40b9d863a18bfc463546f%7Clin
 


Git source tag (d99ad9a2757fb5e412437227c6f9508d06c192e1):
https://github.com/apache/incubator-flagon-useralejs/releases/tag/1.0.0r-RC3_06_12_2019
 



Source Release Branch:
https://github.com/apache/incubator-flagon-useralejs/tree/v1.0.0ReRelease 



Source Release Candidate Artifacts:
https://dist.apache.org/repos/dist/dev/incubator/flagon/ 


PGP release keys (signed with F9374FAE3FCADF6E):
https://dist.apache.org/repos/dist/dev/incubator/flagon/KEYS 


Vote will be open for 72 hours. Please VOTE as follows:

[ ] +1, let's get it released!!!
[ ] +/-0, fine, but consider to fix few issues before...
[ ] -1, nope, because... (and please explain why)

Thank you to everyone that is able to VOTE as well as everyone that
contributed to Apache FLAGON 1.0.0 & 1.0.0r.



> On Jun 18, 2019, at 7:03 AM, Michael Schreiber 
>  wrote:
> 
> +1
> 
> On Mon, Jun 17, 2019 at 9:35 PM Joshua Poore  wrote:
> 
>> Hello,
>> 
>> I am calling a VOTE to (re)Release Apache Flagon UserALE.js (Incubating)
>> v1.0.0.
>> 
>> There are two reasons for this (re)Release:
>> 
>> 1. Original release artifacts were not properly annotated with
>> (incubating) flag—IPMC asked us to regenerate the release with appropriate
>> annotation.
>> 2. Our name was officially changed from Apache SensSoft —> Flagon. This
>> release bears our new project name.
>> 
>> We conducted a VOTE within our own community, resulting in +6 votes in
>> favor of the (re)Release, including +1 binding vote from PPMC:
>> 
>> VOTE thread:
>> https://lists.apache.org/thread.html/7a3c960ee54692cd6d88fb88b83c787244bb0e1b4a476050093d3b4a@%3Cdev.flagon.apache.org%3E
>> <
>> https://lists.apache.org/thread.html/7a3c960ee54692cd6d88fb88b83c787244bb0e1b4a476050093d3b4a@%3Cdev.flagon.apache.org%3E
>>> 
>> VOTE thread II (split accidentally to private):
>> https://lists.apache.org/thread.html/83a96438bd60ea4c0aec2d5f103d68cbb430a44c72ef2d3d0cfe655f@%3Cdev.flagon.apache.org%3E
>> <
>> https://lists.apache.org/thread.html/83a96438bd60ea4c0aec2d5f103d68cbb430a44c72ef2d3d0cfe655f@%3Cdev.flagon.apache.org%3E
>>> 
>> 
>> Please VOTE on Apache FLAGON UserALE.js 1.0.0 Release Candidate #3:
>> 
>> We solved 50 issues:
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12341550=Text=12320621=Create_token=A5KQ-2QAV-T4JA-FDED%7Cd2c9eccb98c0590b13b40b9d863a18bfc463546f%7Clin
>> <
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12341550=Text=12320621=Create_token=A5KQ-2QAV-T4JA-FDED%7Cd2c9eccb98c0590b13b40b9d863a18bfc463546f%7Clin>
>> <
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12341550=Text=12320621=Create_token=A5KQ-2QAV-T4JA-FDED|d2c9eccb98c0590b13b40b9d863a18bfc463546f|lin
>> <
>> https://issues.apache.org/jira/secure/ReleaseNote.jspa?version=12341550=Text=12320621=Create_token=A5KQ-2QAV-T4JA-FDED|d2c9eccb98c0590b13b40b9d863a18bfc463546f|lin
 
>> 
>> Git source tag (d99ad9a2757fb5e412437227c6f9508d06c192e1):
>> https://github.com/apache/incubator-flagon-useralejs/releases/tag/1.0.0r-RC3_06_12_2019
>> <
>> 

Re: [VOTE] Release Apache Druid (incubating) 0.15.0 [RC2]

[Jihoon Son]

Thank you for your detailed review!

We will address your comments on signing keys in the future votes.

Regarding the commit id, "44c9323" is the correct commit id for the tag.
Maybe the link is not valid.
Is https://github.com/apache/incubator-druid/commits/44c9323 or
https://github.com/apache/incubator-druid/tree/druid-0.15.0-incubating-rc2 more
valid one?

Finally, would you elaborate more on what looks wrong to you in NOTICE and
NOTICE.BINARY files?
We will fix them if necessary for this release.

Jihoon

On Thu, Jun 20, 2019 at 9:46 AM sebb  wrote:

> On Thu, 20 Jun 2019 at 03:39, Jihoon Son  wrote:
> >
> > Hi IPMC,
> >
> > The Apache Druid community has voted on and approved a proposal to
> release
> > Apache Druid (incubating) 0.15.0 (rc2).
> >
> > We now kindly request the Incubator PMC members review and vote on this
> > incubator release.
> >
> > Apache Druid (incubating) is a high performance analytics data store for
> > event-driven data.
> >
> > The community voting thread can be found here:
> >
> https://lists.apache.org/thread.html/f4b1b708bcb7e6ec08e6a9cfcb2c0dfcb565fab353ccbb8c5f362218@%3Cdev.druid.apache.org%3E
> >
> > The release notes are available here:
> > https://github.com/apache/incubator-druid/issues/7854
> >
> > The release candidate has been tagged in GitHub as
> > druid-0.15.0-incubating-rc2 (44c9323), available here:
> >
> https://github.com/apache/incubator-druid/releases/tag/druid-0.15.0-incubating-rc2
>
> I'm not sure that's the correct URL for the tag; it points to a couple
> of archives.
>
> I would expect a pointer to the source code.
> This should use the commit id that corresponds to the release
> candidate tag, i.e. the commit id that corresponds to
> https://github.com/apache/incubator-druid/tree/druid-0.15.0-incubating-rc2
> AIUI only commit ids are truly immutable
>
> The NOTICE and NOTICE.BINARY files look wrong to me; they have a lot
> of superfluous text.
>
> > The artifacts to be voted on are located here:
> >
> https://dist.apache.org/repos/dist/dev/incubator/druid/0.15.0-incubating-rc2/
> >
> > A staged Maven repository is available for review at:
> > https://repository.apache.org/content/repositories/orgapachedruid-1007/
> >
> > Release artifacts are signed with the key [95574000]:
> > https://people.apache.org/keys/committer/jihoonson.asc
> >
> > This key and the key of other committers can also be found in the
> project's
> > KEYS file here:
> > https://dist.apache.org/repos/dist/release/incubator/druid/KEYS
> >
> > As part of the validation process, the release artifacts can be generated
> > from source by running:
> > mvn clean install -Papache-release,dist
> >
> > The RAT license check can be run from source by:
> > mvn apache-rat:check -Prat
> >
> > This vote will be open for at least 72 hours. The vote will pass if a
> > majority of at least three +1 IPMC votes are cast.
> >
> > [ ] +1 Release this package as Apache Druid (incubating) 0.15.0
> > [ ]  0 I don't feel strongly about it, but I'm okay with the release
> > [ ] -1 Do not release this package because...
> >
> > Thank you IPMC! We appreciate your efforts in helping the Apache Druid
> > community to validate this release.
> >
> > On behalf of the Apache Druid PPMC,
> > Jihoon
> >
> > Apache Druid (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: Podlings, the Incubator, relationships and Apache

[Davor Bonaci]

I second every single sentence said here. Every. Single. Sentence.

On Thu, Jun 20, 2019 at 10:04 AM David Nalley  wrote:

> There's been a lot of discussion in various threads about bureaucracy,
> whether podlings are part of the ASF, etc. As a result of that I've
> spent a good deal of time reading resolutions and older discussions
> and organizing those thoughts from a legal and community perspective.
> I've also read a number of conversations from the more august members
> of our body about this subject. Altogether it has somewhat changed
> some of my opinions and assumptions. I've also sensed that there is a
> community/business/legal disconnect in our conversations. We're using
> the same words to mean very different things in each of those
> contexts. That said I am but one member of the IPMC, but maybe this
> will be helpful to someone else - I've tried to avoid my assumptions
> in this.
>
> The IPMC's first 'job'[1] is "accepting new products into the
> Foundation" The second 'job' of the IPMC is to "provide guidance and
> support to ensure that the Incubator's sub-projects[2] develop
> products according to the Foundation's philosophy and guidelines". The
> final 'job' is evaluating the products and determining whether they
> should be abandoned, continue to receive guidance and support, or be
> promoted to "full project status".
>
> So there are several realizations I gained from this from the
> Incubator perspective.
> 1. Acceptance into the Incubator is acceptance of the product into the
> Foundation.
> 2. That product is then a sub-project of the Incubator.
> 3. The IPMC has the "primary responsibility for the management of
> those subprojects".
>
> From the Foundation's perspective there are a number of things that
> come to mind:
> 1. We aren't a github/sourceforge/google code type platform where
> random people can upload/post what they want.
> 2. We do not have DMCA Safe Harbor protection - e.g. we are
> responsible for everything that we publish or distribute. With the
> exception of wikis and bug trackers anyone who can put something up on
> an Apache property has some form of legal relationship with the
> Foundation. This could be as simple as an ICLAs where you've
> contractually said you won't contribute anything you don't have rights
> to.
> 3. Most of the project's who have come to us aren't entities in and of
> themselves. E.g. the 'project' doesn't truly exist from a legal entity
> perspective - and even those who do are at best an unincorporated
> association of individuals. From a legal perspective - projects can't
> make or distribute a release - they don't exist - only the ASF and the
> individual(s) doing the work. Given that one of the explicit reasons
> the Foundation was created was to[5]: "provide a means for individual
> volunteers to be sheltered from legal suits"; we want them to create
> and distribute releases as the Foundation.
> 4. Whether we like it or not - the Foundation is judged on the output
> from our projects and subprojects. We have a reputation of having
> clean IP, permissively licensed open source code, with clear
> provenance. Many people explicitly copy our standards, guidelines, and
> policies because they are the gold standard for good open source
> governance.
> 5. Disclaimers generally don't remove liability, and even if they did,
> our disclaimer talks about the maturity of our projects. - And it
> certainly doesn't remove the public's expectations from us - frankly -
> losing the publics trust is as scary as the potential legal liability.
> 6. The Board has delegated the responsibility of managing and ensuring
> adherence to policies and guidelines to the IPMC. I don't see this
> responsibility as boolean. It's not perfect compliance vs. failure.
> IMO, the IPMC has been delegated the decision making process, and may
> often find themselves making the business decision that an imperfect
> release is better than a community stalled for months or years. Don't
> let the perfect be the enemy of the good.
>
> From a podling's perspective:
> 1. Once you join the incubator you're a part of the ASF (Yay!?)
> 2. Your project is now a subproject of the IPMC.
> 3. There are rules, and you're entering a world of pain[4] In fact,
> you're likely to find that the ASF has more rules and structure that
> apply to projects than virtually any other home your project could
> choose. This is good and bad.
> 4. The incubator has a long, storied history of producing successful
> projects that flourish.
>
>
> [1]
> http://apache.org/foundation/records/minutes/2002/board_minutes_2002_10_16.txt
> [2] What we call Podlings, the initial resolution refers to as
> subprojects of the Incubator
> [3] It's worth noting that there were two resolutions proposed to
> create the Incubator - small differences, but interesting to read the
> differences.
> [4] https://youtu.be/3vB9U2hx6Qg
> [5] https://www.apache.org/foundation/faq.html#why
>
> 

Podlings, the Incubator, relationships and Apache

[David Nalley]

There's been a lot of discussion in various threads about bureaucracy,
whether podlings are part of the ASF, etc. As a result of that I've
spent a good deal of time reading resolutions and older discussions
and organizing those thoughts from a legal and community perspective.
I've also read a number of conversations from the more august members
of our body about this subject. Altogether it has somewhat changed
some of my opinions and assumptions. I've also sensed that there is a
community/business/legal disconnect in our conversations. We're using
the same words to mean very different things in each of those
contexts. That said I am but one member of the IPMC, but maybe this
will be helpful to someone else - I've tried to avoid my assumptions
in this.

The IPMC's first 'job'[1] is "accepting new products into the
Foundation" The second 'job' of the IPMC is to "provide guidance and
support to ensure that the Incubator's sub-projects[2] develop
products according to the Foundation's philosophy and guidelines". The
final 'job' is evaluating the products and determining whether they
should be abandoned, continue to receive guidance and support, or be
promoted to "full project status".

So there are several realizations I gained from this from the
Incubator perspective.
1. Acceptance into the Incubator is acceptance of the product into the
Foundation.
2. That product is then a sub-project of the Incubator.
3. The IPMC has the "primary responsibility for the management of
those subprojects".

>From the Foundation's perspective there are a number of things that
come to mind:
1. We aren't a github/sourceforge/google code type platform where
random people can upload/post what they want.
2. We do not have DMCA Safe Harbor protection - e.g. we are
responsible for everything that we publish or distribute. With the
exception of wikis and bug trackers anyone who can put something up on
an Apache property has some form of legal relationship with the
Foundation. This could be as simple as an ICLAs where you've
contractually said you won't contribute anything you don't have rights
to.
3. Most of the project's who have come to us aren't entities in and of
themselves. E.g. the 'project' doesn't truly exist from a legal entity
perspective - and even those who do are at best an unincorporated
association of individuals. From a legal perspective - projects can't
make or distribute a release - they don't exist - only the ASF and the
individual(s) doing the work. Given that one of the explicit reasons
the Foundation was created was to[5]: "provide a means for individual
volunteers to be sheltered from legal suits"; we want them to create
and distribute releases as the Foundation.
4. Whether we like it or not - the Foundation is judged on the output
from our projects and subprojects. We have a reputation of having
clean IP, permissively licensed open source code, with clear
provenance. Many people explicitly copy our standards, guidelines, and
policies because they are the gold standard for good open source
governance.
5. Disclaimers generally don't remove liability, and even if they did,
our disclaimer talks about the maturity of our projects. - And it
certainly doesn't remove the public's expectations from us - frankly -
losing the publics trust is as scary as the potential legal liability.
6. The Board has delegated the responsibility of managing and ensuring
adherence to policies and guidelines to the IPMC. I don't see this
responsibility as boolean. It's not perfect compliance vs. failure.
IMO, the IPMC has been delegated the decision making process, and may
often find themselves making the business decision that an imperfect
release is better than a community stalled for months or years. Don't
let the perfect be the enemy of the good.

>From a podling's perspective:
1. Once you join the incubator you're a part of the ASF (Yay!?)
2. Your project is now a subproject of the IPMC.
3. There are rules, and you're entering a world of pain[4] In fact,
you're likely to find that the ASF has more rules and structure that
apply to projects than virtually any other home your project could
choose. This is good and bad.
4. The incubator has a long, storied history of producing successful
projects that flourish.


[1] 
http://apache.org/foundation/records/minutes/2002/board_minutes_2002_10_16.txt
[2] What we call Podlings, the initial resolution refers to as
subprojects of the Incubator
[3] It's worth noting that there were two resolutions proposed to
create the Incubator - small differences, but interesting to read the
differences.
[4] https://youtu.be/3vB9U2hx6Qg
[5] https://www.apache.org/foundation/faq.html#why

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

Re: [VOTE] Release Apache Druid (incubating) 0.15.0 [RC2]

[sebb]

On Thu, 20 Jun 2019 at 03:39, Jihoon Son  wrote:
>
> Hi IPMC,
>
> The Apache Druid community has voted on and approved a proposal to release
> Apache Druid (incubating) 0.15.0 (rc2).
>
> We now kindly request the Incubator PMC members review and vote on this
> incubator release.
>
> Apache Druid (incubating) is a high performance analytics data store for
> event-driven data.
>
> The community voting thread can be found here:
> https://lists.apache.org/thread.html/f4b1b708bcb7e6ec08e6a9cfcb2c0dfcb565fab353ccbb8c5f362218@%3Cdev.druid.apache.org%3E
>
> The release notes are available here:
> https://github.com/apache/incubator-druid/issues/7854
>
> The release candidate has been tagged in GitHub as
> druid-0.15.0-incubating-rc2 (44c9323), available here:
> https://github.com/apache/incubator-druid/releases/tag/druid-0.15.0-incubating-rc2

I'm not sure that's the correct URL for the tag; it points to a couple
of archives.

I would expect a pointer to the source code.
This should use the commit id that corresponds to the release
candidate tag, i.e. the commit id that corresponds to
https://github.com/apache/incubator-druid/tree/druid-0.15.0-incubating-rc2
AIUI only commit ids are truly immutable

The NOTICE and NOTICE.BINARY files look wrong to me; they have a lot
of superfluous text.

> The artifacts to be voted on are located here:
> https://dist.apache.org/repos/dist/dev/incubator/druid/0.15.0-incubating-rc2/
>
> A staged Maven repository is available for review at:
> https://repository.apache.org/content/repositories/orgapachedruid-1007/
>
> Release artifacts are signed with the key [95574000]:
> https://people.apache.org/keys/committer/jihoonson.asc
>
> This key and the key of other committers can also be found in the project's
> KEYS file here:
> https://dist.apache.org/repos/dist/release/incubator/druid/KEYS
>
> As part of the validation process, the release artifacts can be generated
> from source by running:
> mvn clean install -Papache-release,dist
>
> The RAT license check can be run from source by:
> mvn apache-rat:check -Prat
>
> This vote will be open for at least 72 hours. The vote will pass if a
> majority of at least three +1 IPMC votes are cast.
>
> [ ] +1 Release this package as Apache Druid (incubating) 0.15.0
> [ ]  0 I don't feel strongly about it, but I'm okay with the release
> [ ] -1 Do not release this package because...
>
> Thank you IPMC! We appreciate your efforts in helping the Apache Druid
> community to validate this release.
>
> On behalf of the Apache Druid PPMC,
> Jihoon
>
> Apache Druid (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] Release Apache Druid (incubating) 0.15.0 [RC2]

[sebb]

On Thu, 20 Jun 2019 at 03:39, Jihoon Son  wrote:
>
> Hi IPMC,
>
> The Apache Druid community has voted on and approved a proposal to release
> Apache Druid (incubating) 0.15.0 (rc2).
>
> We now kindly request the Incubator PMC members review and vote on this
> incubator release.
>
> Apache Druid (incubating) is a high performance analytics data store for
> event-driven data.
>
> The community voting thread can be found here:
> https://lists.apache.org/thread.html/f4b1b708bcb7e6ec08e6a9cfcb2c0dfcb565fab353ccbb8c5f362218@%3Cdev.druid.apache.org%3E
>
> The release notes are available here:
> https://github.com/apache/incubator-druid/issues/7854
>
> The release candidate has been tagged in GitHub as
> druid-0.15.0-incubating-rc2 (44c9323), available here:
> https://github.com/apache/incubator-druid/releases/tag/druid-0.15.0-incubating-rc2
>
> The artifacts to be voted on are located here:
> https://dist.apache.org/repos/dist/dev/incubator/druid/0.15.0-incubating-rc2/
>
> A staged Maven repository is available for review at:
> https://repository.apache.org/content/repositories/orgapachedruid-1007/
>
> Release artifacts are signed with the key [95574000]:
> https://people.apache.org/keys/committer/jihoonson.asc

The key id is actually 1E9284D8B647DDE8 (or B647DDE8), not 95574000
The id is the last 16 (or 8) hex digits, not the first 8.

Also the above URL is not guaranteed to contain the key (or even
exist), should someone wish to revisit the vote thread much later.

It is a good idea to quote the signing key id (if correct!), but
please only link to the official KEYS file in future emails.

> This key and the key of other committers can also be found in the project's
> KEYS file here:
> https://dist.apache.org/repos/dist/release/incubator/druid/KEYS

In future vote emails, please use the same URL as must be used on the
download page:

https://www.apache.org/dist/incubator/druid/KEYS

Thanks!
(the email looks fine otherwise)

> As part of the validation process, the release artifacts can be generated
> from source by running:
> mvn clean install -Papache-release,dist
>
> The RAT license check can be run from source by:
> mvn apache-rat:check -Prat
>
> This vote will be open for at least 72 hours. The vote will pass if a
> majority of at least three +1 IPMC votes are cast.
>
> [ ] +1 Release this package as Apache Druid (incubating) 0.15.0
> [ ]  0 I don't feel strongly about it, but I'm okay with the release
> [ ] -1 Do not release this package because...
>
> Thank you IPMC! We appreciate your efforts in helping the Apache Druid
> community to validate this release.
>
> On behalf of the Apache Druid PPMC,
> Jihoon
>
> Apache Druid (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: overzealous bureaucracy (was: [VOTE] Zipkin leave incubator, return back to OpenZipkin)

[Craig Russell]

Hi Greg,

> On Jun 19, 2019, at 12:17 AM, Greg Stein  wrote:
> 
> On Wed, Jun 19, 2019 at 1:48 AM Justin Mclean  >
> wrote:
> 
>> Hi,
>> 
>>> The VOTE was ridiculous. It can only come out "Yes", so why?
>> 
>> Which is the outcome of most votes, they confirm consensus.
> 
> 
> A vote has two outcomes. This kind of vote should never have a "no"
> outcome. Thus, it is specious on its face.
> 
> 
>> But to be more specific in this case, to give a clear searchable record in
>> the mail archives that this wasn’t a fork or other adverse situation.
> 
> 
> That was already established and recorded in the Zipkin community, with
> their vote to depart.
> 
> 
>> Others might have other reasons for thinking it was needed. Also, a mentor
>> called the vote and I respect their decision to do so.
> 
> 
> Which mentor? Sheng Wu? Bullied into holding a vote?
> 
> Or maybe from the private@incubator list, the one who said "I would say we
> should take a discuss/vote in general@incubator to retire the podling".

As the author os that statement I stand by it.

> That is simply participating in IPMC overreach.

You may characterize the existing process as overreach. I characterize it as 
making sure that we have consensus before we take irreversible actions in the 
Apache realm (moving repositories, removing podling infrastructure, etc.)

> It is a sign of disrespect
> for the Zipkin community, that the IPMC has "final say" and requires a vote
> to (ahem) "allow them to leave".

The IPMC does have final say on the disposition of Apache assets related to the 
community's decision to leave.

> The IPMC is NOT in control of communities.

The vote is not in any sense trying to control communities. It is to formalize 
the decision to update Apache assets to reflect the community's decision.

> It is foolish to believe so, and to construct "procedures" and "policy" and
> "bureaucracy" to pretend so.
> 
> I'm fine stating all this nonsensical behavior in public.

Well, I strongly disagree with the characterization of the process as 
nonsensical.

And I would like to suggest that words like these:

Ridiculous
Specious
Bullied
Foolish
Nonsensical

Do Not Help with civil discourse. I understand your passion on the subject but 
I'd like you to disagree without using such language. 

Craig

> -g

Craig L Russell
c...@apache.org

Re: overzealous bureaucracy (was: [VOTE] Zipkin leave incubator, return back to OpenZipkin)

[Lars Francke]

Honestly, I don't know. I agree that Github++ might not have been the best
term but as I said: I didn't think this through to the end.

I guess (all of this is a bunch of unfinished ideas) what it boils down to
is that we can do the incubation outside of the ASF.

I didn't even think about what you read into my statements, to be honest
but only as a "path" into the ASF. This is getting philosophical.

On Thu, Jun 20, 2019 at 11:44 AM Greg Stein  wrote:

> On Thu, Jun 20, 2019 at 4:33 AM Ted Dunning  wrote:
>
> > On Thu, Jun 20, 2019 at 1:59 AM Greg Stein  wrote:
> >
> > >
> > > > On Thu, Jun 20, 2019 at 9:38 AM Lars Francke  >
> > > > wrote:
> > > >
> > > > > This is very much not thought through to the end. One question
> raised
> > > for
> > > > > example is whether projects would even want to become a TLP.
> > > > > The mission states: "We do this by providing services and support
> for
> > > > many
> > > > > like-minded software project communities consisting of individuals
> > who
> > > > > choose to participate in ASF activities."
> > > > > I don't see anything in there requiring anyone to "join" (I
> remember
> > > the
> > > > > recent discussions about that). If you sign up to Github you're not
> > all
> > > > of
> > > > > a sudden a "Github project" but still benefit from its services.
> > > > >
> > > > > We could do something similar.
> > > >
> > > > Do I understand correctly that you're proposing a sort of "indefinite
> > > > incubation" for projects which want to benefit from our infra but
> don't
> > > > want to follow one or more of the principles we have deemed important
> > to
> > > > producing open source software?
> > > >
> > > ...
> > > I don't see Lars suggesting allowing such projects. There would still
> be
> > a
> > > Proposal, and retirement is still an option.
> >
> >
> > Actually, I think that he quite literally did suggest what he called
> > github++ where projects would be free to make releases based on whatever
> > rules that they chose and to not all themselves apache projects for as
> long
> > as they like.
> >
> > I am with Myrle. That isn't what we want. There has to be some ooomph
> > toward becoming an Apache project.
> >
>
> I totally agree. Just saying I didn't read Lars that way.  *shrug*
>

Re: overzealous bureaucracy (was: [VOTE] Zipkin leave incubator, return back to OpenZipkin)

[Greg Stein]

On Thu, Jun 20, 2019 at 4:33 AM Ted Dunning  wrote:

> On Thu, Jun 20, 2019 at 1:59 AM Greg Stein  wrote:
>
> >
> > > On Thu, Jun 20, 2019 at 9:38 AM Lars Francke 
> > > wrote:
> > >
> > > > This is very much not thought through to the end. One question raised
> > for
> > > > example is whether projects would even want to become a TLP.
> > > > The mission states: "We do this by providing services and support for
> > > many
> > > > like-minded software project communities consisting of individuals
> who
> > > > choose to participate in ASF activities."
> > > > I don't see anything in there requiring anyone to "join" (I remember
> > the
> > > > recent discussions about that). If you sign up to Github you're not
> all
> > > of
> > > > a sudden a "Github project" but still benefit from its services.
> > > >
> > > > We could do something similar.
> > >
> > > Do I understand correctly that you're proposing a sort of "indefinite
> > > incubation" for projects which want to benefit from our infra but don't
> > > want to follow one or more of the principles we have deemed important
> to
> > > producing open source software?
> > >
> > ...
> > I don't see Lars suggesting allowing such projects. There would still be
> a
> > Proposal, and retirement is still an option.
>
>
> Actually, I think that he quite literally did suggest what he called
> github++ where projects would be free to make releases based on whatever
> rules that they chose and to not all themselves apache projects for as long
> as they like.
>
> I am with Myrle. That isn't what we want. There has to be some ooomph
> toward becoming an Apache project.
>

I totally agree. Just saying I didn't read Lars that way.  *shrug*

Re: overzealous bureaucracy (was: [VOTE] Zipkin leave incubator, return back to OpenZipkin)

[Ted Dunning]

On Thu, Jun 20, 2019 at 1:59 AM Greg Stein  wrote:

>
> > On Thu, Jun 20, 2019 at 9:38 AM Lars Francke 
> > wrote:
> >
> > > This is very much not thought through to the end. One question raised
> for
> > > example is whether projects would even want to become a TLP.
> > > The mission states: "We do this by providing services and support for
> > many
> > > like-minded software project communities consisting of individuals who
> > > choose to participate in ASF activities."
> > > I don't see anything in there requiring anyone to "join" (I remember
> the
> > > recent discussions about that). If you sign up to Github you're not all
> > of
> > > a sudden a "Github project" but still benefit from its services.
> > >
> > > We could do something similar.
> >
> > Do I understand correctly that you're proposing a sort of "indefinite
> > incubation" for projects which want to benefit from our infra but don't
> > want to follow one or more of the principles we have deemed important to
> > producing open source software?
> >
> ...
> I don't see Lars suggesting allowing such projects. There would still be a
> Proposal, and retirement is still an option.


Actually, I think that he quite literally did suggest what he called
github++ where projects would be free to make releases based on whatever
rules that they chose and to not all themselves apache projects for as long
as they like.

I am with Myrle. That isn't what we want. There has to be some ooomph
toward becoming an Apache project.

Re: overzealous bureaucracy (was: [VOTE] Zipkin leave incubator, return back to OpenZipkin)

[Greg Stein]

On Thu, Jun 20, 2019 at 3:23 AM Myrle Krantz  wrote:

> On Thu, Jun 20, 2019 at 9:38 AM Lars Francke 
> wrote:
>
> > This is very much not thought through to the end. One question raised for
> > example is whether projects would even want to become a TLP.
> > The mission states: "We do this by providing services and support for
> many
> > like-minded software project communities consisting of individuals who
> > choose to participate in ASF activities."
> > I don't see anything in there requiring anyone to "join" (I remember the
> > recent discussions about that). If you sign up to Github you're not all
> of
> > a sudden a "Github project" but still benefit from its services.
> >
> > We could do something similar.
>
> Do I understand correctly that you're proposing a sort of "indefinite
> incubation" for projects which want to benefit from our infra but don't
> want to follow one or more of the principles we have deemed important to
> producing open source software?
>

We have forcibly retired projects before. That option would still be
available in this model. The community "should" be moving towards
Apache-style governance and TLP-style releases. Lack of movement would be
an indicator to consider retirement. Just like we've always done.


> I don't want to do that.  If your project is in the incubator, it should be
> with at least the intention of finding out if the ASF is a good fit for
> your community. That answer could be "no".  And it could take a long time
> to figure that out.  That's OK.  But our volunteer time is a limited
> resource.  We don't need to spend it on projects which don't actually want
> to be part of the ASF.
>

I don't see Lars suggesting allowing such projects. There would still be a
Proposal, and retirement is still an option.

Cheers,
-g

Re: overzealous bureaucracy (was: [VOTE] Zipkin leave incubator, return back to OpenZipkin)

[Bertrand Delacretaz]

Hi,

On Thu, Jun 20, 2019 at 9:38 AM Lars Francke  wrote:
> ...Projects wishing to join the ASF as a TLP would then at some point need to
> abide by the rules (some of which probably also don't make sense but that's
> a different discussion) but until then Mentors could just provide hints...

Note that this was one of the reasons for creating the Maturity Model
[1], as described in its "overview" section.

Projects that may want to move to the ASF later can start by following
those principles, or at least the ones that apply outside of the ASF,
making their move easier if the time comes.

But I'm not sure if the ASF itself needs to be involved in that.
Individuals who want to help such projects can do that independently.

-Bertrand

[1] https://community.apache.org/apache-way/apache-project-maturity-model.html

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

Re: overzealous bureaucracy (was: [VOTE] Zipkin leave incubator, return back to OpenZipkin)

[Myrle Krantz]

On Thu, Jun 20, 2019 at 9:38 AM Lars Francke  wrote:

> This is very much not thought through to the end. One question raised for
> example is whether projects would even want to become a TLP.
> The mission states: "We do this by providing services and support for many
> like-minded software project communities consisting of individuals who
> choose to participate in ASF activities."
> I don't see anything in there requiring anyone to "join" (I remember the
> recent discussions about that). If you sign up to Github you're not all of
> a sudden a "Github project" but still benefit from its services.
>
> We could do something similar.
>

Do I understand correctly that you're proposing a sort of "indefinite
incubation" for projects which want to benefit from our infra but don't
want to follow one or more of the principles we have deemed important to
producing open source software?

I don't want to do that.  If your project is in the incubator, it should be
with at least the intention of finding out if the ASF is a good fit for
your community. That answer could be "no".  And it could take a long time
to figure that out.  That's OK.  But our volunteer time is a limited
resource.  We don't need to spend it on projects which don't actually want
to be part of the ASF.

Best Regards,
Myrle

[DISCUSS] Podlings are part the Incubator Community

[Martijn Dashorst]

 The future's not set. There's no fate but what we make for ourselves.
– John Connor

I wish to posit an opinion that is antithetical to the criticisms
floating around the Incubator. I know that I have not been involved
with the incubator for the last few years and read from the sidelines
the criticisms of the incubator. This post was written in the
aftermath of the Corinthia blow up, and has been in my drafts folder
ever since. I guess now is as good a moment to send it.

This is not a criticism of folks arguing for fewer rules, sanely
enforcing those rules and making those rules learnable items (hi
Greg!). This is a criticism of folks arguing that the Incubator is the
Enemy of All Good Things™, and all faults with the incubating process
lies with the incubator and the people working to make incubation
happen.

One of the oft cited criticisms is that mentors are 'second guessed'
by the 'peanut gallery' with drive-by comments at critical moments in
incubation. I think that this is a symptom rather than a cause: that
the 'peanut gallery' issue is caused by a Podling not interacting
(enough) with the IPMC community as a whole and vice versa!

Mentors are often invested in a community because they have guided
them. Not all mentors are good release vetters (how many have been
release managers?)–I've learnt a great deal from Sebb, nor are they
required to be: they should help the podlings find help throughout the
Foundation. Mentors are good for direct interactions and hands on
guidance. If your mentor is really good at building releases, then
that is great, if they have no experience with that, that is great
too, but then you need help from outside your mentors.

The larger IPMC can provide valuable checks and balances upon
important moments in a podlings journey towards TLP. These important
moments are in my opinion:

 - getting adopted by the IPMC,
 - shipping the first release and
 - graduating from the incubator.

These are the IPMC hurdles the podling has to jump over. They are
important. Yes you will find different opinions, quoted scripture and
what not. The way you handle those is as much informative about your
readiness to graduate, as is whether you checked all the t's and
dotted all the i's.

Also, it just occurred to me that podlings and many folks around here
don't seem to think that podlings are part of the incubator community.
Which is a sad realization, because as a podling you can have a great
influence on your future and the ease of graduating by engaging in the
incubator community. There's a metric ton of experience hanging around
at general@. Keeping your head down inside your dev@ list and only
looking outside when you have to ship your release or think you are
ready to graduate just doesn't cut it.

Engage with the incubator, ask for help when starting your first
Apache release, not just from your mentors, but also on general@.

Also, upon graduation it is beneficial for your project to keep
looking outside your community for opportunities to work with other
projects. This starts inside the incubator, and remains part of
graduated life. When you don't reach out, your community has a high
chance of not gaining new project members.

So instead of incubating in an antagonistic manner--let's keep those
IPMC fanatics as far away from us as possible--try to engage the
incubator as a community. Instead of fighting head on, ask why someone
has a concern. Instead of complaining, acknowledge that you have
learned something, say "we will fix it in the next release", create a
ticket, and fix it in the next release. Don't forget to mention in the
next release that you actually fixed the issue.

Becoming an Apache project is hard work.

My anecdotal evidence is the incubation of Wicket. We were very wary
of becoming an Apache project because of the things we heard about the
incubation process. We stayed in the incubator far to long (though
ultimately we had a swift incubation period), but not due to the IPMC:
we were to blame ourselves naval gazing in our own dev@ list instead
of working towards graduation. Once we realized our mistake,
graduation was a mere couple of months away. Also, we tried to engage
the incubator community and listen to what advice was given to other
podlings, asking for clarification when we didn't understand.

After graduation you'll have to report to the board, and (one of you)
will need to subscribe to the board@ mailing list. If you keep your
head down and only do the bare minimum, you are doing our (including
your!) community a disservice. There's a lot to learn from
disseminating what's happening at the board level, even in discussions
that don't directly affect your project: it might be that in a couple
of weeks the discussion *will* affect your project.

So interacting with the IPMC will invariably train you for life beyond
the incubator. Make the best effort and you will thrive once
graduated.

Martijn Dashorst

Re: overzealous bureaucracy (was: [VOTE] Zipkin leave incubator, return back to OpenZipkin)

[Lars Francke]

This was also discussed on the ASF slack during which I suggested (this is
not fully thought through) to change the Incubator model to focus on its
core tenets of providing services to projects wanting to join the ASF.
For this cause, the projects itself don't need to be ASF projects (not even
Apache Foo but just Foo). They don't have to use the ASF infrastructure but
they can if they want but probably under a different domain/name.

This is like Github++, you can still use everything there (or Gitlab or
whatever) but you also get the community, people to help you out, mailing
lists, etc.
But you wouldn't need to do any voting on releases, no reports for the
board, no NOTICE or DISCLAIMER files etc.

Projects wishing to join the ASF as a TLP would then at some point need to
abide by the rules (some of which probably also don't make sense but that's
a different discussion) but until then Mentors could just provide hints
instead of -1 or strongly worded mails. "Hey, I see you're doing releases
like this, if you'd like to join as a TLP you need a vote on releases and
it works like this, wanna try next time?"

This is very much not thought through to the end. One question raised for
example is whether projects would even want to become a TLP.
The mission states: "We do this by providing services and support for many
like-minded software project communities consisting of individuals who
choose to participate in ASF activities."
I don't see anything in there requiring anyone to "join" (I remember the
recent discussions about that). If you sign up to Github you're not all of
a sudden a "Github project" but still benefit from its services.

We could do something similar.

On Thu, Jun 20, 2019 at 3:48 AM Olivier Lamy  wrote:

> Good effort Bertrand that's definitely some discussions we should have and
> ease incubation!
> To be honest I'm mentoring some projects but sometimes I'm out of
> motivation due to the huge number of nitpicking tasks/requests.
> I perfectly understand people reactions when they try to go trough the
> incubation process.. (disclaimer it's an email from the peanut gallery)
>
> So yes let's make Apache incubation great again..
>
>
>
>
> On Thu, 20 Jun 2019 at 03:28, Bertrand Delacretaz <
> bdelacre...@codeconsult.ch> wrote:
>
> > On Wed, Jun 19, 2019 at 7:14 PM Ted Dunning 
> wrote:
> > > ...This vote is *confirming* that
> > > nobody has objections (of any form) to Zipkin leaving and control of
> the
> > > git repos being transferred...
> >
> > I agree and this means that in this case a [LAZY] vote would have been
> > sufficient.
> >
> > -Bertrand
> >
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> >
>
> --
> Olivier Lamy
> http://twitter.com/olamy | http://linkedin.com/in/olamy
>