Setting up DataSketches (name search in progress)

[Kenneth Knowles]

Hi all,

I have added DataSketches to podlings.xml with help from Dave Fisher [1].
The name search is underway, credit to Lee Rhodes [2].

Next steps as I understand them are to set up:

   - podling status page
   - DNS
   - LDAP
   - web site
   - mailing lists
   - git repo

I am not confident on which of these is very easy to rename versus which
are best to leave until after name search. By default, leaving them all
until after name search.

Kenn

[1] http://svn.apache.org/viewvc?view=revision=1856700
[2] https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-168

[VOTE] Release Apache Druid (incubating) 0.14.0 [RC3]

[Jonathan Wei]

Hi IPMC,

The Apache Druid community has voted on and approved a proposal to release
Apache Druid (incubating) 0.14.0 (rc3).

We now kindly request the Incubator PMC members review and vote on this
incubator release.

Project description: Apache Druid (incubating) is a high performance
analytics data store for event-driven data.

The community voting thread can be found here:
https://www.mail-archive.com/dev@druid.apache.org/msg01924.html

The release notes are available here:
https://github.com/apache/incubator-druid/issues/7126

The release candidate has been tagged in GitHub as
druid-0.14.0-incubating-rc3 (f169ada), available here:
https://github.com/apache/incubator-druid/releases/tag/druid-0.14.0-incubating-rc3

The artifacts to be voted on are located here:
https://dist.apache.org/repos/dist/dev/incubator/druid/0.14.0-incubating-rc3/

A staged Maven repository is available for review at:
https://repository.apache.org/content/repositories/orgapachedruid-1003/

Release artifacts are signed with the key [1AC4483E]:
https://people.apache.org/keys/committer/jonwei.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.14.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,
Jon

[jira] [Commented] (INCUBATOR-231) Cleanup Git-generated Incubator website

[Dave Fisher (JIRA)]

[ 
https://issues.apache.org/jira/browse/INCUBATOR-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808168#comment-16808168
 ] 

Dave Fisher commented on INCUBATOR-231:
---

Bertrand I had to follow your plan. There is now a reserve folder in the 
asf-site branch.

> Cleanup Git-generated Incubator website
> ---
>
> Key: INCUBATOR-231
> URL: https://issues.apache.org/jira/browse/INCUBATOR-231
> Project: Incubator
>  Issue Type: Task
>Reporter: Bertrand Delacretaz
>Priority: Major
> Attachments: clutch-analysis.tar.gz, clutch-pages.tar.gz, 
> clutch.py.diff.txt, clutch2data.txt, clutch2data.txt, clutch2status.txt, 
> gitbox.clutch.data.txt, gitbox.svn.diff.txt
>
>
> [http://incubator.apache.org/] is generated from 
> [https://github.com/apache/incubator] but a few things (clutch, project 
> pages) are still maintained under 
> [http://svn.apache.org/repos/asf/incubator/public/trunk/]
> We should cleanup and unify for consistency, and there's a number of folders 
> in svn that are not used anymore. Everything should move to Git to avoid 
> confusion.
> Also, a lot of the projects information in the XML files found under 
> [http://svn.apache.org/repos/asf/incubator/public/trunk/content/projects/] is 
> duplicated in other places, LDAP, podlings websites etc - it would be good to 
> clean that up and simplify those pages to adapt to our current workflows, 
> while preserving history where it makes sense.
> There are also YAML files with yet more duplicated information at 
> [http://svn.apache.org/repos/asf/incubator/public/trunk/content/podlings/] , 
> not sure if that's used or useful.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

All is good - Re: Warning - Website Build Is Currently Broken

[Dave Fisher]

Hi -

Website build is now functional.

Clutch and SVN content is now once a day and regular site editing is quick.

More later.

Regards,
Dave

> On Apr 2, 2019, at 12:35 PM, Dave Fisher  wrote:
> 
> I’m working on process to split the clutch and svn analysis and the normal 
> git procedures.
> 
> I ran into a problem (Bertrand warned me …). It’s going to take several hours 
> to fix. Mostly I’ve got some errands to run and I need to clear my mind.
> 
> Regards,
> Dave
> 
>> On Apr 2, 2019, at 12:22 PM, Apache Jenkins Server 
>>  wrote:
>> 
>> The Apache Jenkins build system has built Incubator SVN Clutch Analysis - 
>> part 1 (build #10)
>> 
>> Status: Failure
>> 
>> Check console output at 
>> https://builds.apache.org/job/Incubator%20SVN%20Clutch%20Analysis%20-%20part%201/10/
>>  to view the results.
>> -
>> To unsubscribe, e-mail: cvs-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: cvs-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

Warning - Website Build Is Currently Broken

[Dave Fisher]

I’m working on process to split the clutch and svn analysis and the normal git 
procedures.

I ran into a problem (Bertrand warned me …). It’s going to take several hours 
to fix. Mostly I’ve got some errands to run and I need to clear my mind.

Regards,
Dave

> On Apr 2, 2019, at 12:22 PM, Apache Jenkins Server 
>  wrote:
> 
> The Apache Jenkins build system has built Incubator SVN Clutch Analysis - 
> part 1 (build #10)
> 
> Status: Failure
> 
> Check console output at 
> https://builds.apache.org/job/Incubator%20SVN%20Clutch%20Analysis%20-%20part%201/10/
>  to view the results.
> -
> To unsubscribe, e-mail: cvs-unsubscr...@incubator.apache.org
> For additional commands, e-mail: cvs-h...@incubator.apache.org


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

[jira] [Issue Comment Deleted] (INCUBATOR-231) Cleanup Git-generated Incubator website

[Dave Fisher (JIRA)]

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

Dave Fisher updated INCUBATOR-231:
--
Comment: was deleted

(was: {quote}I'm not sure if you can push to the master branch from a Jenkins 
build. But if not it's probably possible to push to raw clutch data to asf-site 
so it appears (unlinked) under incubator.apache.org/data and can be pulled from 
there by the main build.
{quote}
You can't and your suggestion is as bad as doing the clutch every time. I guess 
I'll talk to builds, but frankly I feel like I've wasted a lot of time. - days 
in fact.)

> Cleanup Git-generated Incubator website
> ---
>
> Key: INCUBATOR-231
> URL: https://issues.apache.org/jira/browse/INCUBATOR-231
> Project: Incubator
>  Issue Type: Task
>Reporter: Bertrand Delacretaz
>Priority: Major
> Attachments: clutch-analysis.tar.gz, clutch-pages.tar.gz, 
> clutch.py.diff.txt, clutch2data.txt, clutch2data.txt, clutch2status.txt, 
> gitbox.clutch.data.txt, gitbox.svn.diff.txt
>
>
> [http://incubator.apache.org/] is generated from 
> [https://github.com/apache/incubator] but a few things (clutch, project 
> pages) are still maintained under 
> [http://svn.apache.org/repos/asf/incubator/public/trunk/]
> We should cleanup and unify for consistency, and there's a number of folders 
> in svn that are not used anymore. Everything should move to Git to avoid 
> confusion.
> Also, a lot of the projects information in the XML files found under 
> [http://svn.apache.org/repos/asf/incubator/public/trunk/content/projects/] is 
> duplicated in other places, LDAP, podlings websites etc - it would be good to 
> clean that up and simplify those pages to adapt to our current workflows, 
> while preserving history where it makes sense.
> There are also YAML files with yet more duplicated information at 
> [http://svn.apache.org/repos/asf/incubator/public/trunk/content/podlings/] , 
> not sure if that's used or useful.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

[jira] [Commented] (INCUBATOR-231) Cleanup Git-generated Incubator website

[Dave Fisher (JIRA)]

[ 
https://issues.apache.org/jira/browse/INCUBATOR-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16808065#comment-16808065
 ] 

Dave Fisher commented on INCUBATOR-231:
---

{quote}I'm not sure if you can push to the master branch from a Jenkins build. 
But if not it's probably possible to push to raw clutch data to asf-site so it 
appears (unlinked) under incubator.apache.org/data and can be pulled from there 
by the main build.
{quote}
You can't and your suggestion is as bad as doing the clutch every time. I guess 
I'll talk to builds, but frankly I feel like I've wasted a lot of time. - days 
in fact.

> Cleanup Git-generated Incubator website
> ---
>
> Key: INCUBATOR-231
> URL: https://issues.apache.org/jira/browse/INCUBATOR-231
> Project: Incubator
>  Issue Type: Task
>Reporter: Bertrand Delacretaz
>Priority: Major
> Attachments: clutch-analysis.tar.gz, clutch-pages.tar.gz, 
> clutch.py.diff.txt, clutch2data.txt, clutch2data.txt, clutch2status.txt, 
> gitbox.clutch.data.txt, gitbox.svn.diff.txt
>
>
> [http://incubator.apache.org/] is generated from 
> [https://github.com/apache/incubator] but a few things (clutch, project 
> pages) are still maintained under 
> [http://svn.apache.org/repos/asf/incubator/public/trunk/]
> We should cleanup and unify for consistency, and there's a number of folders 
> in svn that are not used anymore. Everything should move to Git to avoid 
> confusion.
> Also, a lot of the projects information in the XML files found under 
> [http://svn.apache.org/repos/asf/incubator/public/trunk/content/projects/] is 
> duplicated in other places, LDAP, podlings websites etc - it would be good to 
> clean that up and simplify those pages to adapt to our current workflows, 
> while preserving history where it makes sense.
> There are also YAML files with yet more duplicated information at 
> [http://svn.apache.org/repos/asf/incubator/public/trunk/content/podlings/] , 
> not sure if that's used or useful.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: [ANNOUNCE] Apache Livy 0.6.0-incubating released

[sebb]

On Tue, 2 Apr 2019 at 19:28, Marcelo Vanzin  wrote:
>
> The Apache Livy team is proud to announce the release of Apache Livy
> 0.6.0-incubating.
>
> Livy is web service that exposes a REST interface for managing long
> running Apache Spark contexts in your cluster. Livy enables
> programmatic, fault-tolerant, multi-tenant submission of Spark jobs
> from web/mobile apps (no Spark client needed). So, multiple users can
> interact with your Spark cluster concurrently and reliably.
>
> Download Apache Livy 0.6.0-incubating:
> http://livy.incubator.apache.org/download/
>
> Release Notes:
> http://livy.incubator.apache.org/history/
>
> For more about Livy check our website:
> http://livy.incubator.apache.org/
>
> We would like to thank the contributors that made the release possible!

This is an incubator release, and should include the standard
incubator disclaimer.

See for example:

https://lists.apache.org/thread.html/d94b89e6c4e83f2364607b47020ca715aaa7fae1a3b97b374b93ca7f@%3Cgeneral.incubator.apache.org%3E
https://lists.apache.org/thread.html/ec3d6b90a2b0054eb2f0a2e4ba2e09a594463720e2b28e75b315c693@%3Cgeneral.incubator.apache.org%3E
https://lists.apache.org/thread.html/8993ecb33e0f73e69faabba8c1f07d3a9965a178df1698c42fc9f4b2@%3Cgeneral.incubator.apache.org%3E

Thanks.

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

Re: [ANNOUNCE] Apache Livy 0.6.0-incubating released

[Marcelo Vanzin]

(Apologies to all, this is the same announcement as previously, but
including the missing disclaimer.)

The Apache Livy team is proud to announce the release of Apache Livy
0.6.0-incubating.

Livy is web service that exposes a REST interface for managing long
running Apache Spark contexts in your cluster. Livy enables
programmatic, fault-tolerant, multi-tenant submission of Spark jobs
from web/mobile apps (no Spark client needed). So, multiple users can
interact with your Spark cluster concurrently and reliably.

Download Apache Livy 0.6.0-incubating:
http://livy.incubator.apache.org/download/

Release Notes:
http://livy.incubator.apache.org/history/

For more about Livy check our website:
http://livy.incubator.apache.org/

We would like to thank the contributors that made the release possible!

=
*Disclaimer*

Apache Livy (incubating) is an effort undergoing incubation at The
Apache Software Foundation (ASF), sponsored by the name of Apache
Incubator PMC. 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.

-- 
Marcelo

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

[ANNOUNCE] Apache Livy 0.6.0-incubating released

[Marcelo Vanzin]

The Apache Livy team is proud to announce the release of Apache Livy
0.6.0-incubating.

Livy is web service that exposes a REST interface for managing long
running Apache Spark contexts in your cluster. Livy enables
programmatic, fault-tolerant, multi-tenant submission of Spark jobs
from web/mobile apps (no Spark client needed). So, multiple users can
interact with your Spark cluster concurrently and reliably.

Download Apache Livy 0.6.0-incubating:
http://livy.incubator.apache.org/download/

Release Notes:
http://livy.incubator.apache.org/history/

For more about Livy check our website:
http://livy.incubator.apache.org/

We would like to thank the contributors that made the release possible!


-- 
Marcelo

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

Re: svn commit: r1856835 - /incubator/public/trunk/clutch2.py

[sebb]

Note that ?filename only works with action=download; that will start
an immediate download.

However that does not allow users to change the mirror except by
reloading the URL.

On Tue, 2 Apr 2019 at 18:55, Dave Fisher  wrote:
>
> Hi Sebb,
>
> I’ve another place to fix - clutch2status.py - doing so now - thanks!
>
> Regards,
> Dave
>
> > On Apr 2, 2019, at 10:18 AM, s...@apache.org wrote:
> >
> > Author: sebb
> > Date: Tue Apr  2 17:18:41 2019
> > New Revision: 1856835
> >
> > URL: http://svn.apache.org/viewvc?rev=1856835=rev
> > Log:
> > Fix download URL so it resolves to download directory (not top level)
> >
> > Modified:
> >incubator/public/trunk/clutch2.py
> >
> > Modified: incubator/public/trunk/clutch2.py
> > URL: 
> > http://svn.apache.org/viewvc/incubator/public/trunk/clutch2.py?rev=1856835=1856834=1856835=diff
> > ==
> > --- incubator/public/trunk/clutch2.py (original)
> > +++ incubator/public/trunk/clutch2.py Tue Apr  2 17:18:41 2019
> > @@ -1124,7 +1124,7 @@ for k in sorted(projectNames, key=str.lo
> > # See if they have a distribution area yet.
> > for nameDist in projects[k]['resourceNames']:
> > urlDist = 
> > "https://www.apache.org/dist/incubator/{0}/".format(nameDist)
> > -urlMirror = 
> > "https://www.apache.org/dyn/closer.lua?filename=incubator/{0}/".format(nameDist)
> > +urlMirror = 
> > "https://www.apache.org/dyn/closer.lua/incubator/{0}/".format(nameDist)
> > urlDistSVN = 
> > "https://dist.apache.org/repos/dist/release/incubator/{0}".format(nameDist)
> > if nameDist in distareas:
> > projects[k]['urlDist'] = urlMirror
> >
> >
> >
> > -
> > To unsubscribe, e-mail: cvs-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: cvs-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: svn commit: r1856835 - /incubator/public/trunk/clutch2.py

[Dave Fisher]

Hi Sebb,

I’ve another place to fix - clutch2status.py - doing so now - thanks!

Regards,
Dave

> On Apr 2, 2019, at 10:18 AM, s...@apache.org wrote:
> 
> Author: sebb
> Date: Tue Apr  2 17:18:41 2019
> New Revision: 1856835
> 
> URL: http://svn.apache.org/viewvc?rev=1856835=rev
> Log:
> Fix download URL so it resolves to download directory (not top level)
> 
> Modified:
>incubator/public/trunk/clutch2.py
> 
> Modified: incubator/public/trunk/clutch2.py
> URL: 
> http://svn.apache.org/viewvc/incubator/public/trunk/clutch2.py?rev=1856835=1856834=1856835=diff
> ==
> --- incubator/public/trunk/clutch2.py (original)
> +++ incubator/public/trunk/clutch2.py Tue Apr  2 17:18:41 2019
> @@ -1124,7 +1124,7 @@ for k in sorted(projectNames, key=str.lo
> # See if they have a distribution area yet.
> for nameDist in projects[k]['resourceNames']:
> urlDist = 
> "https://www.apache.org/dist/incubator/{0}/".format(nameDist)
> -urlMirror = 
> "https://www.apache.org/dyn/closer.lua?filename=incubator/{0}/".format(nameDist)
> +urlMirror = 
> "https://www.apache.org/dyn/closer.lua/incubator/{0}/".format(nameDist)
> urlDistSVN = 
> "https://dist.apache.org/repos/dist/release/incubator/{0}".format(nameDist)
> if nameDist in distareas:
> projects[k]['urlDist'] = urlMirror
> 
> 
> 
> -
> To unsubscribe, e-mail: cvs-unsubscr...@incubator.apache.org
> For additional commands, e-mail: cvs-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][RESULT] release Apache OpenWhisk Package Alarm, Package Cloudant, and Package Kafka 2.0.0 (incubating)

[Dave Fisher]

Hi -

I recently added a detailed clutch analysis page for each podling. It is 
helpful for these situations as it lists all the releases in a flat sorted 
manner:

https://incubator.apache.org/clutch/openwhisk.html

Similar analysis could be added for TLPs …

It also shows OpenWhisk 51 git repositories.

Regards,
Dave

> On Apr 2, 2019, at 8:35 AM, Matt Sicker  wrote:
> 
> We have a fun layout in Logging:
> https://dist.apache.org/repos/dist/release/logging/
> 
> On Tue, 2 Apr 2019 at 07:46, Bertrand Delacretaz
>  wrote:
>> 
>> Hi Dave,
>> 
>> On Tue, Apr 2, 2019 at 2:39 PM David P Grove  wrote:
>>> ...For us, using the the version as the primary organizing metric in the 
>>> dist
>>> isn't a great fit.  Is there a precedent for doing otherwise (eg, first by
>>> component, then the active branches within each component)?...
>> 
>> As an example, Sling also has many components, and we're just throwing
>> (most) everything in the top-level folder at
>> https://dist.apache.org/repos/dist/release/sling/
>> 
>> It's not fantastic if you look there, but it makes it easy to check
>> that there's only one version of a given component, and the download
>> page at https://sling.apache.org/downloads.cgi provides a more
>> convenient view.
>> 
>> -Bertrand
>> 
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>> 
> 
> 
> -- 
> Matt Sicker 
> 
> -
> 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][RESULT] release Apache OpenWhisk Package Alarm, Package Cloudant, and Package Kafka 2.0.0 (incubating)

[Matt Sicker]

We have a fun layout in Logging:
https://dist.apache.org/repos/dist/release/logging/

On Tue, 2 Apr 2019 at 07:46, Bertrand Delacretaz
 wrote:
>
> Hi Dave,
>
> On Tue, Apr 2, 2019 at 2:39 PM David P Grove  wrote:
> > ...For us, using the the version as the primary organizing metric in the 
> > dist
> > isn't a great fit.  Is there a precedent for doing otherwise (eg, first by
> > component, then the active branches within each component)?...
>
> As an example, Sling also has many components, and we're just throwing
> (most) everything in the top-level folder at
> https://dist.apache.org/repos/dist/release/sling/
>
> It's not fantastic if you look there, but it makes it easy to check
> that there's only one version of a given component, and the download
> page at https://sling.apache.org/downloads.cgi provides a more
> convenient view.
>
> -Bertrand
>
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>


-- 
Matt Sicker 

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

[jira] [Commented] (INCUBATOR-231) Cleanup Git-generated Incubator website

[Dave Fisher (JIRA)]

[ 
https://issues.apache.org/jira/browse/INCUBATOR-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807853#comment-16807853
 ] 

Dave Fisher commented on INCUBATOR-231:
---

I think that the concern is that the automatic build is triggered by changes to 
the master. So, if you changed master in the automatic build you would have an 
infinite loop.

The plan is to turn off the automatic build. Make another daily SVN/Clutch job 
where its commit changes master. Once that works the now simple automatic build 
is turned back on and tested by a manual clutch change ...

> Cleanup Git-generated Incubator website
> ---
>
> Key: INCUBATOR-231
> URL: https://issues.apache.org/jira/browse/INCUBATOR-231
> Project: Incubator
>  Issue Type: Task
>Reporter: Bertrand Delacretaz
>Priority: Major
> Attachments: clutch-analysis.tar.gz, clutch-pages.tar.gz, 
> clutch.py.diff.txt, clutch2data.txt, clutch2data.txt, clutch2status.txt, 
> gitbox.clutch.data.txt, gitbox.svn.diff.txt
>
>
> [http://incubator.apache.org/] is generated from 
> [https://github.com/apache/incubator] but a few things (clutch, project 
> pages) are still maintained under 
> [http://svn.apache.org/repos/asf/incubator/public/trunk/]
> We should cleanup and unify for consistency, and there's a number of folders 
> in svn that are not used anymore. Everything should move to Git to avoid 
> confusion.
> Also, a lot of the projects information in the XML files found under 
> [http://svn.apache.org/repos/asf/incubator/public/trunk/content/projects/] is 
> duplicated in other places, LDAP, podlings websites etc - it would be good to 
> clean that up and simplify those pages to adapt to our current workflows, 
> while preserving history where it makes sense.
> There are also YAML files with yet more duplicated information at 
> [http://svn.apache.org/repos/asf/incubator/public/trunk/content/podlings/] , 
> not sure if that's used or useful.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking IPMC to vote

[Ate Douma]

On 02/04/2019 16.53, Ate Douma wrote:



On 02/04/2019 16.41, Ross Gardler wrote:
Myrle makes a good point. As a mentor (is been a long time though) I 
tried to cast my vote after there were at least 3 views from the 
community. Once I saw the ppmc catching issues I was missing, or I was 
simply ratifying their view, it was time to graduate.


The IPMC should have nothing to do with it, other than as a backstop 
for absent mentors.


Interested IPMC members can join the community like everyone else. 
They are not some privileged group that gets special treatment.


I agree and like this!

Can we change the rules such that a PPMC release vote only needs to
be notified to the IPMC (general@), and without further ado be accepted
when at least +3 binding votes have been given on the podling dev list?
That leaves room for other interested IPMC members to participate in the
vote *there*, but won't depend on it.
Only when not enough binding IPMC votes are collected during the podling
release vote, it can either be re-started on general@, or a heads-up can
be send there requesting explicit help from other IPMC members.


Furthermore, this makes the responsibilities of mentors more explicit,
as well as possible lack of time (MIA) of mentors.

Also, if mentors are not completely sure about complicated release
matters, they can choose to vote +0, with reasons, thereby indicating 
the need for more IPMC eyes to review the release.

In case of huge/complex podlings like NetBeans that clearly was needed
and tremendously helpful.





Get Outlook for Android


From: Myrle Krantz 
Sent: Tuesday, April 2, 2019 7:31:41 AM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Mentors SHOULD vote on podling releases prior 
to asking IPMC to vote


On Tue, Apr 2, 2019 at 2:09 PM Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:


Hi,

On Tue, Apr 2, 2019 at 11:30 AM Geertjan Wielenga
 wrote:

...Maybe the PPMC and IPMC vote could run in parallel...


I think the reason for having two votes is to give an opportunity for
mentors to catch issues in the first one without bothering the IPMC.



The vote on the podling list is more (in my opinion) about giving the
members of the PPMC hands-on practice in catching issues before the 
safety

net of mentors/IPMC comes into play.  This is one reason why some mentors
sometimes chose to wait a bit before voting on releases.

Best Regards,
Myrle



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

Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking IPMC to vote

[Ate Douma]

On 02/04/2019 16.41, Ross Gardler wrote:

Myrle makes a good point. As a mentor (is been a long time though) I tried to 
cast my vote after there were at least 3 views from the community. Once I saw 
the ppmc catching issues I was missing, or I was simply ratifying their view, 
it was time to graduate.

The IPMC should have nothing to do with it, other than as a backstop for absent 
mentors.

Interested IPMC members can join the community like everyone else. They are not 
some privileged group that gets special treatment.


I agree and like this!

Can we change the rules such that a PPMC release vote only needs to
be notified to the IPMC (general@), and without further ado be accepted
when at least +3 binding votes have been given on the podling dev list?
That leaves room for other interested IPMC members to participate in the
vote *there*, but won't depend on it.
Only when not enough binding IPMC votes are collected during the podling
release vote, it can either be re-started on general@, or a heads-up can
be send there requesting explicit help from other IPMC members.



Get Outlook for Android


From: Myrle Krantz 
Sent: Tuesday, April 2, 2019 7:31:41 AM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking 
IPMC to vote

On Tue, Apr 2, 2019 at 2:09 PM Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:


Hi,

On Tue, Apr 2, 2019 at 11:30 AM Geertjan Wielenga
 wrote:

...Maybe the PPMC and IPMC vote could run in parallel...


I think the reason for having two votes is to give an opportunity for
mentors to catch issues in the first one without bothering the IPMC.



The vote on the podling list is more (in my opinion) about giving the
members of the PPMC hands-on practice in catching issues before the safety
net of mentors/IPMC comes into play.  This is one reason why some mentors
sometimes chose to wait a bit before voting on releases.

Best Regards,
Myrle



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

Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking IPMC to vote

[Ate Douma]

On 02/04/2019 13.58, Bertrand Delacretaz wrote:

Hi,

On Tue, Apr 2, 2019 at 11:30 AM Geertjan Wielenga
 wrote:

...Maybe the PPMC and IPMC vote could run in parallel...


I think the reason for having two votes is to give an opportunity for
mentors to catch issues in the first one without bothering the IPMC.


That, as well as the actual/target voting audience, including the PPMC
and the podling community, which more likely will also, and more so,
verify and validate the actual intended functionality (runtime) of
the release.
While the IPMC will be more/mostly focussed on the formal requirements
(license/notice files, dependencies, no binaries in source, etc.).

Running both votes in parallel definitely can be useful, but the
release manager then may want/need to take *both* vote results into
account in deciding the result (with +3 binding IPMC votes as a minimum
requirement).



So maybe run parallel votes from the third or fourth release on, to
keep the "noise filter" active initially.

Yes, or at least do the first release votes sequentially, and thereafter
opt for using parallel votes based on the advise from the mentors.

And it might still be recommended to do a sequential vote later on in
case of huge or major changes, for example after a big code donation
being incorporated.

Ate



This is similar to having to report monthly for the first three
months, then quarterly.

-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] Mentors SHOULD vote on podling releases prior to asking IPMC to vote

[Julian Feinauer]

I agree with the point from Myrle and Ross, I dislike the idea of parallel 
votes.
Especially in the early stages we had multiple RCs which failed in the PPMC 
Vote process.
I would not like to have them on the general@ list, as that adds a lot of noise.

Julian

Am 02.04.19, 16:41 schrieb "Ross Gardler" :

Myrle makes a good point. As a mentor (is been a long time though) I tried 
to cast my vote after there were at least 3 views from the community. Once I 
saw the ppmc catching issues I was missing, or I was simply ratifying their 
view, it was time to graduate.

The IPMC should have nothing to do with it, other than as a backstop for 
absent mentors.

Interested IPMC members can join the community like everyone else. They are 
not some privileged group that gets special treatment.

Get Outlook for Android


From: Myrle Krantz 
Sent: Tuesday, April 2, 2019 7:31:41 AM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to 
asking IPMC to vote

On Tue, Apr 2, 2019 at 2:09 PM Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> Hi,
>
> On Tue, Apr 2, 2019 at 11:30 AM Geertjan Wielenga
>  wrote:
> > ...Maybe the PPMC and IPMC vote could run in parallel...
>
> I think the reason for having two votes is to give an opportunity for
> mentors to catch issues in the first one without bothering the IPMC.
>

The vote on the podling list is more (in my opinion) about giving the
members of the PPMC hands-on practice in catching issues before the safety
net of mentors/IPMC comes into play.  This is one reason why some mentors
sometimes chose to wait a bit before voting on releases.

Best Regards,
Myrle



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

Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking IPMC to vote

[Ross Gardler]

Myrle makes a good point. As a mentor (is been a long time though) I tried to 
cast my vote after there were at least 3 views from the community. Once I saw 
the ppmc catching issues I was missing, or I was simply ratifying their view, 
it was time to graduate.

The IPMC should have nothing to do with it, other than as a backstop for absent 
mentors.

Interested IPMC members can join the community like everyone else. They are not 
some privileged group that gets special treatment.

Get Outlook for Android


From: Myrle Krantz 
Sent: Tuesday, April 2, 2019 7:31:41 AM
To: general@incubator.apache.org
Subject: Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking 
IPMC to vote

On Tue, Apr 2, 2019 at 2:09 PM Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> Hi,
>
> On Tue, Apr 2, 2019 at 11:30 AM Geertjan Wielenga
>  wrote:
> > ...Maybe the PPMC and IPMC vote could run in parallel...
>
> I think the reason for having two votes is to give an opportunity for
> mentors to catch issues in the first one without bothering the IPMC.
>

The vote on the podling list is more (in my opinion) about giving the
members of the PPMC hands-on practice in catching issues before the safety
net of mentors/IPMC comes into play.  This is one reason why some mentors
sometimes chose to wait a bit before voting on releases.

Best Regards,
Myrle

Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking IPMC to vote

[Myrle Krantz]

On Tue, Apr 2, 2019 at 2:09 PM Bertrand Delacretaz <
bdelacre...@codeconsult.ch> wrote:

> Hi,
>
> On Tue, Apr 2, 2019 at 11:30 AM Geertjan Wielenga
>  wrote:
> > ...Maybe the PPMC and IPMC vote could run in parallel...
>
> I think the reason for having two votes is to give an opportunity for
> mentors to catch issues in the first one without bothering the IPMC.
>

The vote on the podling list is more (in my opinion) about giving the
members of the PPMC hands-on practice in catching issues before the safety
net of mentors/IPMC comes into play.  This is one reason why some mentors
sometimes chose to wait a bit before voting on releases.

Best Regards,
Myrle

Re: [VOTE][RESULT] release Apache OpenWhisk Package Alarm, Package Cloudant, and Package Kafka 2.0.0 (incubating)

[Bertrand Delacretaz]

Hi Dave,

On Tue, Apr 2, 2019 at 2:39 PM David P Grove  wrote:
> ...For us, using the the version as the primary organizing metric in the dist
> isn't a great fit.  Is there a precedent for doing otherwise (eg, first by
> component, then the active branches within each component)?...

As an example, Sling also has many components, and we're just throwing
(most) everything in the top-level folder at
https://dist.apache.org/repos/dist/release/sling/

It's not fantastic if you look there, but it makes it easy to check
that there's only one version of a given component, and the download
page at https://sling.apache.org/downloads.cgi provides a more
convenient view.

-Bertrand

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

Re: [VOTE][RESULT] release Apache OpenWhisk Package Alarm, Package Cloudant, and Package Kafka 2.0.0 (incubating)

[David P Grove]

"Henk P. Penning"  wrote on 04/02/2019 07:13:11 AM:
>
>At the moment, OpenWhisk has in /dist/incubator/openwhisk/ :
>
>apache-openwhisk-0.9.0-incubating/
>apache-openwhisk-0.9.8-incubating/
>apache-openwhisk-0.10.0-incubating/
>apache-openwhisk-1.12.0-incubating/
>apache-openwhisk-2.0.0-incubating/
>
>The (legal) policy on software releases [1] says to remove
>(from /dist/) releases when development on that version
>branch ceases ; for instance
>
>  remove openwhisk-0.9.0  if you're not developping 0.X
>  remove openwhisk-0.9.8  if you're not developping 0.X
>  remove openwhisk-1.12.0 if you're not developping 1.12.1
>

We understand the policy.  OpenWhisk has about 25 sub-components that are
released using different version numbering schemes.  These dirs all contain
most recent releases of some components.

For us, using the the version as the primary organizing metric in the dist
isn't a great fit.  Is there a precedent for doing otherwise (eg, first by
component, then the active branches within each component)?  That might
better communicate how we are organizing our releases.

--dave

Re: [VOTE][RESULT] release Apache OpenWhisk Package Alarm, Package Cloudant, and Package Kafka 2.0.0 (incubating)

[Bertrand Delacretaz]

Hi,

On Tue, Apr 2, 2019 at 1:13 PM Henk P. Penning  wrote:
>...If possbile, please remove 'older' releases from
>  https://www.apache.org/dist/incubator/openwhisk/ ...

Good point Henk!

Note that older releases are archived automatically under
http://archive.apache.org/dist/incubator/openwhisk/ which should be
mentioned on download pages.

(I have suggested that for OpenWhisk at
https://github.com/apache/incubator-openwhisk-website/pull/370 )

-Bertrand

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

Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking IPMC to vote

[Bertrand Delacretaz]

Hi,

On Tue, Apr 2, 2019 at 11:30 AM Geertjan Wielenga
 wrote:
> ...Maybe the PPMC and IPMC vote could run in parallel...

I think the reason for having two votes is to give an opportunity for
mentors to catch issues in the first one without bothering the IPMC.

So maybe run parallel votes from the third or fourth release on, to
keep the "noise filter" active initially.

This is similar to having to report monthly for the first three
months, then quarterly.

-Bertrand

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

Re: [VOTE]: Release Apache OpenWhisk Client JS (incubating) 3.19.0.

[Bertrand Delacretaz]

Hi

On Tue, Mar 26, 2019 at 9:20 PM James Thomas  wrote:
> This is a call for vote to release Apache OpenWhisk Client JS (incubating)
> 3.19.0

+1 for the release of this archive, with a few minor things to fix for
the next release, see below.

SHA512(../openwhisk-client-js-3.19.0-incubating-sources.tar.gz)=
8d8fe6c548f5fe72f5c5cc2e1539416f84b18bb7d6a0075b50cafc2255bfa27ec8e60b9d6660e20372ceb667eae91474dab16d8b764b51418b7595de78cba217

Checked digests, signatures, build with "npm run test" and Apache headers.

Like another recent release most or all JavaScript source files have a
short form copyright header:

  // Licensed to the Apache Software Foundation (ASF) under one or
more contributor
  // license agreements; and to You under the Apache License, Version 2.0.

Which should only be used for minified code as per
https://www.apache.org/legal/src-headers.html

-Bertrand

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

Re: [VOTE]: Release Apache OpenWhisk Client JS (incubating) 3.19.0.

[Bertrand Delacretaz]

Hi,

On Sat, Mar 30, 2019 at 1:20 AM Justin Mclean  wrote:
> ...I notice that the project when compiled it downloads this file [1] (and 
> other places), the text
> of which is still under copyright, it’s currently unclear how to deal with 
> this.
> There is a discussion on legal-discuss about it [2] that I suggest you 
> follow...

Note that https://github.com/substack/node-wordwrap/issues/22 should
fix this upstream, updating the node-wordwrap dependency should remove
that problem.

Also, I don't think OpenWhisk is distributing that file, it's just
(currently) downloaded when building but will not be included in
OpenWhisk artifacts. I think we have many cases of build tools not
being ok for redistribution, which is fine as we do not redistribute
them.

-Bertrand

> 1. ./node_modules/nyc/node_modules/wordwrap/test/idleness.txt
> 2. 
> https://lists.apache.org/thread.html/346ea8ac79c1cdd91c6d7c6d5acb2360a1d84d3a3e8966f91d260cbf@%3Clegal-discuss.apache.org%3E

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

[jira] [Commented] (INCUBATOR-234) Incubator Cookbook

[Bertrand Delacretaz (JIRA)]

[ 
https://issues.apache.org/jira/browse/INCUBATOR-234?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807665#comment-16807665
 ] 

Bertrand Delacretaz commented on INCUBATOR-234:
---

I agree with a page specific to Incubator PMC members, maybe use a different 
name ("PMC page") to avoid confusion with "the cookbook". This should also 
allow for simplifying the guides.

Also agree about the menu changes, once we get there.

> Incubator Cookbook
> --
>
> Key: INCUBATOR-234
> URL: https://issues.apache.org/jira/browse/INCUBATOR-234
> Project: Incubator
>  Issue Type: Task
>  Components: site
>Reporter: Bertrand Delacretaz
>Priority: Major
>
> As discussed at [1] the goal is to create a single page Incubator Cookbook, 
> with all the details of the incubation process, in chronological order of the 
> incubation journey.
> This should be as concise as possible, with links to more information where 
> strictly needed, and adopt a friendly tone in the sense of clearly making the 
> Incubator a service to our podlings.
> Draft page at [http://incubator.apache.org/cookbook/ ,  
> |http://incubator.apache.org/cookbook/]source 
> [https://github.com/apache/incubator/blob/master/pages/cookbook/index.ad]
> As a next step I'll focus on getting a mostly consistent set of topics and we 
> can then share the writing work.
>  [1] 
> [https://lists.apache.org/thread.html/51fe5d659778bed5b6385c7c39bbdf688d02f1b1dbe02d595d514cbb@%3Cgeneral.incubator.apache.org%3E]
> h2. How to contribute to this effort
>  * Feedback and suggestions are welcome here.
>  * Pull requests at [https://github.com/apache/incubator] also work
>  * Discussions on the [general@incubator.a.o|mailto:general@incubator.a.o] 
> list, [https://lists.apache.org/list.html?general@incubator.apache.org]



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: [VOTE][RESULT] release Apache OpenWhisk Package Alarm, Package Cloudant, and Package Kafka 2.0.0 (incubating)

[Henk P. Penning]

On Mon, 1 Apr 2019, Dave Grove wrote:


Date: Mon, 1 Apr 2019 16:01:05 +
From: Dave Grove 
To: general@incubator.apache.org
Subject: Re: [VOTE][RESULT] release Apache OpenWhisk Package Alarm,
Package Cloudant, and Package Kafka 2.0.0 (incubating)


Hi Dave,


We will proceed with the 2.0.0 release of these three components.


  If possbile, please remove 'older' releases from

https://www.apache.org/dist/incubator/openwhisk/

  At the moment, OpenWhisk has in /dist/incubator/openwhisk/ :

  apache-openwhisk-0.9.0-incubating/
  apache-openwhisk-0.9.8-incubating/
  apache-openwhisk-0.10.0-incubating/
  apache-openwhisk-1.12.0-incubating/
  apache-openwhisk-2.0.0-incubating/

  The (legal) policy on software releases [1] says to remove
  (from /dist/) releases when development on that version
  branch ceases ; for instance

remove openwhisk-0.9.0  if you're not developping 0.X
remove openwhisk-0.9.8  if you're not developping 0.X
remove openwhisk-1.12.0 if you're not developping 1.12.1

  [1] https://www.apache.org/legal/release-policy.html#when-to-archive

  Thanks ; regards,

  Henk Penning

   _
Henk P. Penning, ICT-beta R Uithof MG-403_/ \_
Faculty of Science, Utrecht UniversityT +31 30 253 4106 / \_/ \
Leuvenlaan 4, 3584CE Utrecht, NL  F +31 30 253 4553 \_/ \_/
http://www.staff.science.uu.nl/~penni101/ M penn...@uu.nl \_/

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

[jira] [Commented] (INCUBATOR-231) Cleanup Git-generated Incubator website

[Bertrand Delacretaz (JIRA)]

[ 
https://issues.apache.org/jira/browse/INCUBATOR-231?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16807662#comment-16807662
 ] 

Bertrand Delacretaz commented on INCUBATOR-231:
---

I'm not sure if you can push to the master branch from a Jenkins build. But if 
not it's probably possible to push to raw clutch data to asf-site so it appears 
(unlinked) under incubator.apache.org/data and can be pulled from there by the 
main build.

> Cleanup Git-generated Incubator website
> ---
>
> Key: INCUBATOR-231
> URL: https://issues.apache.org/jira/browse/INCUBATOR-231
> Project: Incubator
>  Issue Type: Task
>Reporter: Bertrand Delacretaz
>Priority: Major
> Attachments: clutch-analysis.tar.gz, clutch-pages.tar.gz, 
> clutch.py.diff.txt, clutch2data.txt, clutch2data.txt, clutch2status.txt, 
> gitbox.clutch.data.txt, gitbox.svn.diff.txt
>
>
> [http://incubator.apache.org/] is generated from 
> [https://github.com/apache/incubator] but a few things (clutch, project 
> pages) are still maintained under 
> [http://svn.apache.org/repos/asf/incubator/public/trunk/]
> We should cleanup and unify for consistency, and there's a number of folders 
> in svn that are not used anymore. Everything should move to Git to avoid 
> confusion.
> Also, a lot of the projects information in the XML files found under 
> [http://svn.apache.org/repos/asf/incubator/public/trunk/content/projects/] is 
> duplicated in other places, LDAP, podlings websites etc - it would be good to 
> clean that up and simplify those pages to adapt to our current workflows, 
> while preserving history where it makes sense.
> There are also YAML files with yet more duplicated information at 
> [http://svn.apache.org/repos/asf/incubator/public/trunk/content/podlings/] , 
> not sure if that's used or useful.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

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

Re: [DISCUSS] Mentors SHOULD vote on podling releases prior to asking IPMC to vote

[Adrian Cole]

Parallel would solve our problem of delayed bookkeeping as well. good idea.

It is not so much about about the initial 72 hours, rather the pause
then another 72hrs that someone having to remember. Podlings have a
stateful experience during a release.. they have to know which are in
what stage. voting is more stateless. My goal is to have podlings and
folks who have stateful tasks to be able to complete them with no more
stages than necessary.

People will drive up quality to have less burdensome process. You'll
notice zipkin already automating things people have been emburdened by
for years [1] . If higher gates are needed for a faster process, I'm
sure we'd find a way to do that vs the alternative. No ones goal is to
do more red tape than necessary or take longer doing it I'm sure.

-A

[1] https://github.com/openzipkin-contrib/apache-release-verification

On Tue, Apr 2, 2019 at 4:30 PM Geertjan Wielenga
 wrote:
>
> Maybe the PPMC and IPMC vote could run in parallel -- a key reason why we
> in Apache NetBeans are looking forward to graduation is that we'll not need
> to go through the loop of (1) PPMC approves, (2) IPMC rejects, (3) PPMC
> needs to put together a new release and vote on it again, (4) IPMC rejects
> again (finding something else they hadn't found before), etc. That's slowed
> the releases we have done in the incubator down significantly, typically by
> at least 2 weeks -- of course, as will be pointed out, Apache NetBeans is
> very large -- but, assuming Apache wants to be a welcome place for large
> projects too, something needs to be done here (though it won't be a problem
> for Apache NetBeans anymore since we plan to graduate before our next
> release). So, if the votes were to at least run in parallel, that would
> save time, and maybe as soon as there are 3 +1s from PPMC/IPMC members,
> that should be good to go, rather than waiting another 72 hours after that,
> in situations where those votes come in quickly.
>
> Gj
>
> On Tue, Apr 2, 2019 at 11:09 AM Julian Feinauer <
> j.feina...@pragmaticminds.de> wrote:
>
> > Hi,
> >
> > I like Craigs suggestion and I'm aware of the problem with the ASF Policy
> > if we would skip the formal IPMC Vote.
> > On the other hand in PLC4X we had a discussion about a regular release
> > cycle to bring new features to the users as fast as possible and decided to
> > skip that for now, to keep the burden on the IPMC low (and we usually have
> > 3 IPMC / Mentor Votes as we have very active Mentors).
> > I agree with this decision of the PPMC but I see a problem with that, as
> > the IPMC Vote should be something to help podlings (aside from the
> > necessity by Policy) but not "negatively" impact them.
> >
> > Perhaps it helps to see the IPMC Votes more as a "take notice" in case
> > that there are already 3 +1 Votes. This means that the vote is open for
> > 72hrs formally, but IPMC members do not feel to have to go to action
> > (usually as PMC member one "should" participate in votes... although this
> > is practiced differently in the IPMC for good reasons) but CAN if they feel
> > like.
> > This would especially mean that podlings should be encouraged to formulate
> > their votes more explicit about whether there are already enough IPMC Votes
> > or not.
> >
> > Julian
> >
> >
> > Am 01.04.19, 23:51 schrieb "Justin Mclean" :
> >
> > Hi,
> >
> > I'd also like to see those mentors / IPMC members vote with more than
> > just a +1 and provide a list of what they checked. If they could use
> > something like this all the better [1].
> >
> > I wouldn’t be for removing the second step of letting the IPMC look at
> > it, reasonably often serious issues are found in that step. By skilling
> > that we risk some podlings going all the way to propose graduation while
> > having releases that don’t follow ASF policy. This is a situation I’d like
> > to avoid.
> >
> > Thanks,
> > Justin
> >
> > 1. https://wiki.apache.org/incubator/IncubatorReleaseChecklist
> > -
> > 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] Mentors SHOULD vote on podling releases prior to asking IPMC to vote

[Geertjan Wielenga]

Maybe the PPMC and IPMC vote could run in parallel -- a key reason why we
in Apache NetBeans are looking forward to graduation is that we'll not need
to go through the loop of (1) PPMC approves, (2) IPMC rejects, (3) PPMC
needs to put together a new release and vote on it again, (4) IPMC rejects
again (finding something else they hadn't found before), etc. That's slowed
the releases we have done in the incubator down significantly, typically by
at least 2 weeks -- of course, as will be pointed out, Apache NetBeans is
very large -- but, assuming Apache wants to be a welcome place for large
projects too, something needs to be done here (though it won't be a problem
for Apache NetBeans anymore since we plan to graduate before our next
release). So, if the votes were to at least run in parallel, that would
save time, and maybe as soon as there are 3 +1s from PPMC/IPMC members,
that should be good to go, rather than waiting another 72 hours after that,
in situations where those votes come in quickly.

Gj

On Tue, Apr 2, 2019 at 11:09 AM Julian Feinauer <
j.feina...@pragmaticminds.de> wrote:

> Hi,
>
> I like Craigs suggestion and I'm aware of the problem with the ASF Policy
> if we would skip the formal IPMC Vote.
> On the other hand in PLC4X we had a discussion about a regular release
> cycle to bring new features to the users as fast as possible and decided to
> skip that for now, to keep the burden on the IPMC low (and we usually have
> 3 IPMC / Mentor Votes as we have very active Mentors).
> I agree with this decision of the PPMC but I see a problem with that, as
> the IPMC Vote should be something to help podlings (aside from the
> necessity by Policy) but not "negatively" impact them.
>
> Perhaps it helps to see the IPMC Votes more as a "take notice" in case
> that there are already 3 +1 Votes. This means that the vote is open for
> 72hrs formally, but IPMC members do not feel to have to go to action
> (usually as PMC member one "should" participate in votes... although this
> is practiced differently in the IPMC for good reasons) but CAN if they feel
> like.
> This would especially mean that podlings should be encouraged to formulate
> their votes more explicit about whether there are already enough IPMC Votes
> or not.
>
> Julian
>
>
> Am 01.04.19, 23:51 schrieb "Justin Mclean" :
>
> Hi,
>
> I'd also like to see those mentors / IPMC members vote with more than
> just a +1 and provide a list of what they checked. If they could use
> something like this all the better [1].
>
> I wouldn’t be for removing the second step of letting the IPMC look at
> it, reasonably often serious issues are found in that step. By skilling
> that we risk some podlings going all the way to propose graduation while
> having releases that don’t follow ASF policy. This is a situation I’d like
> to avoid.
>
> Thanks,
> Justin
>
> 1. https://wiki.apache.org/incubator/IncubatorReleaseChecklist
> -
> 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] Mentors SHOULD vote on podling releases prior to asking IPMC to vote

[Julian Feinauer]

Hi,

I like Craigs suggestion and I'm aware of the problem with the ASF Policy if we 
would skip the formal IPMC Vote.
On the other hand in PLC4X we had a discussion about a regular release cycle to 
bring new features to the users as fast as possible and decided to skip that 
for now, to keep the burden on the IPMC low (and we usually have 3 IPMC / 
Mentor Votes as we have very active Mentors).
I agree with this decision of the PPMC but I see a problem with that, as the 
IPMC Vote should be something to help podlings (aside from the necessity by 
Policy) but not "negatively" impact them.

Perhaps it helps to see the IPMC Votes more as a "take notice" in case that 
there are already 3 +1 Votes. This means that the vote is open for 72hrs 
formally, but IPMC members do not feel to have to go to action (usually as PMC 
member one "should" participate in votes... although this is practiced 
differently in the IPMC for good reasons) but CAN if they feel like.
This would especially mean that podlings should be encouraged to formulate 
their votes more explicit about whether there are already enough IPMC Votes or 
not.

Julian


Am 01.04.19, 23:51 schrieb "Justin Mclean" :

Hi,

I'd also like to see those mentors / IPMC members vote with more than just 
a +1 and provide a list of what they checked. If they could use something like 
this all the better [1].

I wouldn’t be for removing the second step of letting the IPMC look at it, 
reasonably often serious issues are found in that step. By skilling that we 
risk some podlings going all the way to propose graduation while having 
releases that don’t follow ASF policy. This is a situation I’d like to avoid.

Thanks,
Justin

1. https://wiki.apache.org/incubator/IncubatorReleaseChecklist
-
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