RE: Re: [DISCUSS] Graduate Apache DataLab (Incubating) as a Top Level Project

[Mark Thomas]

On 2023/02/28 01:38:02 Justin Mclean wrote:

> 5. I've reviewed the name discussion [1] and logo [2] (links are added).  
> In my opinion, the logo demonstrates the podling name: DataLab (logo) & Data Lab (podling name). 
> I was wondering if you could explain why our logo doesn't reflect the podling name in your opinion? 
> Perhaps, you mean something else. It would be great if you could clarify it. 


The name approved is “Apache DataLab” not “DataLab” and there some discussion why 
“DataLab” may not be suitable as it s too generic and many other products use that 
name. Also given recent discussions about the use of the Apache name (which you may 
not be aware of) I wonder if branding the project branding strongly as "Apache 
DataLab” is a good idea?


Speaking as VP, Brand Management...

While the name search issue quoted "Apache Data Lab", it is not a 
mandatory requirement that the project always refers to itself with the 
"Apache" prefix.


I also don't view "Data Lab" vs "DataLab" as an issue but I do strongly 
recommend that the podling picks one form and sticks to it. From this 
thread I am assuming it has picked "DataLab".


I have no concerns regarding the logo.

Given the generic nature of the name "DataLab", the podling may find it 
needs to use the full project name more often than most ASF projects but 
I am happy to leave that to the project's discretion.


Mark
VP, Brand Management
ASF

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

RE: Re: [VOTE] Graduate Apache NuttX to TLP

[Mark Thomas]

I have reviewed the current trademark status and I am happy to proceed 
on the basis that the transfer will be started after graduation.


Mark

Mark Thomas
VP, Brand Management

On 2022/11/07 13:13:03 Willem Jiang wrote:

Sorry, I need to change my vote to -1.
I just discovered a brand issue we need to address before graduation.
It looks like the trademark of Nuttx[1] is still not transferred to ASF.
We need the trademark VP approval before starting the vote.
[1] https://nuttx.apache.org/docs/latest/introduction/trademarks.html


Willem Jiang

Twitter: willemjiang
Weibo: 姜宁willem

On Mon, Nov 7, 2022 at 9:03 PM Willem Jiang  wrote:
>
> +1 （binding）
>
> Willem Jiang
>
> Twitter: willemjiang
> Weibo: 姜宁willem
>
> On Sat, Nov 5, 2022 at 12:07 AM Nathan Hartman  
wrote:
> >
> > Dear Apache Incubator Community,
> >
> > I would like to call a VOTE to graduate Apache NuttX from the
> > Incubator to the status of Top-Level-Project (TLP).
> >
> > The NuttX PPMC has held a community vote to graduate [1] and the vote
> > passed [2]. Following a community discussion [3] to draft our
> > resolution (see below) and secure a volunteer for Vice President of
> > Apache NuttX, and the gentle nudges we've been getting from our
> > mentors and the Incubator community to take this important step,
> >
> > I am pleased to call this VOTE:
> >
> > [ ] +1 Yes, Apache NuttX (Incubating) is ready to graduate from the
> > Apache Incubator to the status of Top Level Project.
> >
> > [ ] +0 No opinion.
> >
> > [ ] -1 No, Apache NuttX (Incubating) is NOT ready to graduate (please
> > state reason(s)).
> >
> > This vote will remain open for at least 72 hours.
> >
> > Some project highlights since incubation:
> > * Incubating for over 1000 days (since 2019-12-09)
> > * Website migrated to nuttx.apache.org
> > * Shipped 9 releases under the ASF Incubator
> > * Merged 8000 PRs across incubator-nuttx and incubator-nuttx-apps
> > * More than 1000 stars on GitHub
> > * More than 500 forks on GitHub
> > * More than 250 subscribers to d...@nuttx.apache.org
> > * In Top 10 Apache projects of 2021 by number of commits [4]
> > * 5 mentors
> > * 18 PPMC members
> > * 26 committers
> > * 75 ICLAs
> > * 2 CCLAs
> > * 21 SGAs
> > * 2 release managers
> > * 3 NuttX online workshops
> > * And much, much more
> >
> > Resolution:
> >
> > [[[
> >
> > Establish the Apache NuttX Project
> >
> > WHEREAS, the Board of Directors deems it to be in the best interests of
> > the Foundation and consistent with the Foundation's purpose to
> > establish a Project Management Committee charged with the creation and
> > maintenance of open-source software, for distribution at no charge to
> > the public, related to a mature, real-time embedded operating system
> > (RTOS).
> >
> > NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> > (PMC), to be known as the "Apache NuttX Project", be and hereby is
> > established pursuant to Bylaws of the Foundation; and be it further
> >
> > RESOLVED, that the Apache NuttX Project be and hereby is responsible
> > for the creation and maintenance of software related to a mature, real-
> > time embedded operating system (RTOS); and be it further
> >
> > RESOLVED, that the office of "Vice President, Apache NuttX" be and
> > hereby is created, the person holding such office to serve at the
> > direction of the Board of Directors as the chair of the Apache NuttX
> > Project, and to have primary responsibility for management of the
> > projects within the scope of responsibility of the Apache NuttX
> > Project; and be it further
> >
> > RESOLVED, that the persons listed immediately below be and hereby are
> > appointed to serve as the initial members of the Apache NuttX Project:
> >
> >  * Abdelatif Guettouche   
> >  * Alan Carvalho de Assis 
> >  * Alin Jerpelea  
> >  * Anthony Merlino
> >  * Brennan Ashton 
> >  * David Sidrane  
> >  * Duo Zhang  
> >  * Flavio Paiva Junqueira 
> >  * Gregory Nutt   
> >  * Gustavo Henrique Nihei 
> >  * Junping Du 
> >  * Justin Mclean  
> >  * Lup Yuen Lee   
> >  * Masayuki Ishikawa  
> >  * Mohammad Asif Siddiqui 
> >  * Nathan Hartman 
> >  * Sara Monteiro  
> >  * Xiang Xiao 
> >
> > NOW, THEREFORE, BE IT FURTHER RESOLVED, that Alin Jerpelea be
> > appoi

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

[Mark Thomas]

Hi,

Can someone explain to me what branding issues on the Presto website 
have to do with the graduation of Apache Pinot?


Separately, I will note that this page:

https://prestodb.io/docs/current/connector.html

referenced earlier in this thread still has a large number of issues. 
Specifically, the first and most prominent (they may or may not be the 
same) occurrence of an ASF project name should appear in full. 
Therefore, I'd expect to see "Apache Accumulo", "Apache Cassandra" etc.


Since it appears that there are folks from Presto on this thread, I'm 
going to assume that this is sufficient to make Presto aware that these 
issues need to be fixed.


Thanks,

Mark
VP, Brand Management


On 17/06/2021 23:41, Mayank Shrivastava wrote:

Hello


Thank you Justin, Felix & Dave for your help and support with the 
graduation process.



We have fixed the Apache Pinot branding issue in Presto [1]. We have 
also fixed the footer of the main page [6] to say “Integrations” for 
Presto/ThirdEye/Superset, and not “Components” as previously stated.



The ThirdEye project was discussed [2] and moved out of the Apache Pinot 
project [3], and is no longer part of the Apache Pinot project.



We added disclaimers in the footer for pages referring to Presto and 
Thirdeye in Pinot docs page [4][5].



The ThirdEye documentation at [6] is owned by the ThirdEye project. We 
have also notified the ThirdEye team to fix their documentation about 
installing ThirdEye from Apache Pinot, the “Edit on Github” link broken, 
and fix any branding/trademark issues referring to Apache Pinot.




[1] Presto branding issue PR 

[2] Discussion to move ThirdEye of Apache Pinot 



[3] Thread for actual move of ThirdEye from Apache Pinot 



[4] ThirdEye page disclaimer in footer. 



[5] Presto page disclaimer in footer. 



[6] Apache Pinot Main Page 

On Wed, Jun 16, 2021 at 7:28 PM Felix Cheung > wrote:


On Wed, Jun 16, 2021 at 5:39 PM Dave Fisher mailto:w...@apache.org>> wrote:

 > Adding trademarks@
 >
 > See https://prestodb.io/docs/current/connector.html

 >

This is a great point but to be clear, that https://prestodb.io/

> is the Presto
project in
the Presto Foundation, and not the Apache Pinot project.



 > There are 11 Apache products with trademark issues.
 >
 > This issue is extensive enough that a coordinated response is
required.
 > these can take long enough that this issue should not delay
graduation.
 >
 > >
 > > The Presto documentation looks to have a few branding issue
that need to
 > be corrected [3]. Is the PPMC aware of this and doing something
about it? I
 > can see some other branding issues with the presto webpage [4][5]
(and
 > other pages) and Apache projects with Pinot and Hive, Hadoop,
Cassandra,
 > Spark, Kafka and Druid. There might be others.
 >
 > Regards,
 > Dave
 >
 > >
 > > Thanks,
 > > Justin
 > >
 > > 1.
 >

https://lists.apache.org/thread.html/rb2bc93448636e3238f72654426ecce232b46c73ed1447b9c47a1d49e%40%3Cgeneral.incubator.apache.org%3E


 > > 2. https://github.com/apache/incubator-pinot/issues/6785

 > > 3. https://prestodb.io/docs/current/connector/pinot.html

 > > 4. https://prestodb.io 
 > > 5. https://prestodb.io/faq.html 
 > > 6. https://docs.pinot.apache.org/integrations/thirdeye

 > > 7.
https://github.com/apache/incubator-pinot/tree/master/thirdeye

 > >
 > >
 > >
-
 > > To unsubscribe, e-mail:
general-unsubscr...@incubator.apache.org

 > > For additional commands, e-mail:
general-h...@incubator.apache.org

 >

[jira] [Updated] (INCUBATOR-245) Slider - Auditing Capability

[Mark Thomas (Jira)]

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

Mark Thomas updated INCUBATOR-245:
--
Attachment: (was: 2021_01_10_07_45_25.mp4)

> Slider - Auditing Capability
> 
>
> Key: INCUBATOR-245
> URL: https://issues.apache.org/jira/browse/INCUBATOR-245
> Project: Incubator
>  Issue Type: Task
>Reporter: Krishnadevan Purushothaman
>Priority: Critical
>
> As far as I understand, Slider outputs only logs for debugging use as details 
> of executing containers, and etc.
> Can we believe Slider doesn't have any logs for auditing of Slider itself? 
> (i.e. when & who used Slider for what application, etc.)



--
This message was sent by Atlassian Jira
(v8.3.4#803005)

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

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

[Mark Thomas]

+1 (binding)

Mark


On 01/05/2019 02:44, Huxing Zhang wrote:
> Hi All,
> 
> After discussion in the Apache Dubbo community on the dev mailing
> list[1], choosing PMC chair[2], forming the PMC members[3], completing
> the maturity model[4], discussing the resolution proposal[5], and
> voting for the graduation[6], the Dubbo community has presented the
> draft resolution for discussion[7] to the incubator community. In the
> discussion, the Dubbo community has cleared the branding issues for
> 3rd party Github group[8].
> 
> Apache Dubbo entered incubator in February 2018. During incubation,
> there has been:
> - 11 releases with 7 different release managers.
> - 6 new PPMC members. (17 in total, excluding mentors). The PPMC
> members varies from Alibaba, Jingdong, Youzan, Weidian, Netease,
> Meituan-Dianping, Qunar. [9]
> - 15 new committers. The committers varies from Alibaba, Weidian,
> Jingdong, Qunar, Youzan, Netease, Meituan-Dianping, Rongguan,
> Handuyishe, Didi, NetsUnion, Caocaokeji, Huawei, GomeFinance,
> Asiainfo-sec, iFlytek, Keep and etc. [9]
> - 192 contributors grown from 70+ for the incubator-dubbo repository.
> - 1401 issues and 1168 pull requests closed.
> - 140+ companies using Dubbo in production.
> - 393 subscriber for the dev@ mailing list
> - 5209 emails sent by 261 people, divided into 2160 topics
> 
> Now the Dubbo community are bringing the attached draft resolution up
> for a formal IPMC VOTE.
> 
> Please take a minute to vote on whether or not Apache Dubbo should
> graduate to a Top Level Project by responding with one of the following:
> 
> [ ] +1 Apache Dubbo should graduate.
> [ ] +0 No opinion
> [ ] -1 Apache Dubbo should not graduate (please provide the reason)
> 
> The VOTE is open for a minimum of 72 hours.
> 
> -
> Establish the Apache Dubbo Project
> 
> WHEREAS, the Board of Directors deems it to be in the best interests of
> the Foundation and consistent with the Foundation's purpose to establish
> a Project Management Committee charged with the creation and maintenance
> of open-source software, for distribution at no charge to the public,
> related to a high-performance, lightweight, java based RPC framework.
> 
> NOW, THEREFORE, BE IT RESOLVED, that a Project Management Committee
> (PMC), to be known as the "Apache Dubbo Project", be and hereby is
> established pursuant to Bylaws of the Foundation; and be it further
> 
> RESOLVED, that the Apache Dubbo Project be and hereby is responsible for
> the creation and maintenance of software related to a high-performance,
> lightweight, java based RPC framework; and be it further
> 
> RESOLVED, that the office of "Vice President, Apache Dubbo" be and
> hereby is created, the person holding such office to serve at the
> direction of the Board of Directors as the chair of the Apache Dubbo
> Project, and to have primary responsibility for management of the
> projects within the scope of responsibility of the Apache Dubbo Project;
> and be it further
> 
> RESOLVED, that the persons listed immediately below be and hereby are
> appointed to serve as the initial members of the Apache Dubbo Project:
> 
>  * Huxing Zhang   
>  * Ian Luo
>  * Jun Liu
>  * Justin Mclean  
>  * Kimm King  
>  * Liang Zhang
>  * Liujie Qin 
>  * Mercy Ma   
>  * Minxuan Zhuang 
>  * Shang Zonghai  
>  * Von Gosling
>  * Xin Wang   
>  * Yong Zhu   
>  * Yuhang Xiu 
>  * YunKun Huang   
> 
> NOW, THEREFORE, BE IT FURTHER RESOLVED, that Ian Luo be appointed to the
> office of Vice President, Apache Dubbo, to serve in accordance with and
> subject to the direction of the Board of Directors and the Bylaws of the
> Foundation until death, resignation, retirement, removal or
> disqualification, or until a successor is appointed; and be it further
> 
> RESOLVED, that the Apache Dubbo Project be and hereby is tasked with the
> migration and rationalization of the Apache Incubator Dubbo podling; and
> be it further
> 
> RESOLVED, that all responsibilities pertaining to the Apache Incubator
> Dubbo podling encumbered upon the Apache Incubator PMC are hereafter
> discharged.
> -
> 
> [1] 
> https://lists.apache.org/thread.html/767da61f249789f09665a52a241e3b352d168fec051ee7dd1dd7c20b@%3Cdev.dubbo.apache.org%3E
> [2] 
> https://lists.apache.org/thread.html/537a7a88ab19ffee31c0b642ff6239372aa063985846febe2ad11d91@%3Cdev.dubbo.apache.org%3E
> [3] 
> https://lists.apache.org/thread.html/b7218b3b441f7a96e1d339e1eeea60e8bba9b06295e73b56659524c0@%3Cdev.dubbo.apache.org%3E
> [4] 
> https://github.com/apache/incubator-dubbo/wiki/Apache-Maturity-Model-Assessment-for-Dubbo
> [5] 
> https://lists.apache.org/thread.html/2b9fb2c565656308dcce5281c5352da41d5aabc56020af084c6888d3@%3Cdev.dubbo.apache.org%3E
> [6] 
> https://lists.apache.org/thread.html/cb00b308011770f4cf2e4eac4ab0ddec397fe83e4ee92d246a450d73@%3Cdev.dubbo.apache.org%3E
> [7] 
> 

Re: [VOTE]: Release Apache Dubbo (Incubating) 2.7.1 [RC1]

[Mark Thomas]

On 22/03/2019 09:09, Ian Luo wrote:

> Please vote accordingly:
> [X] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason

- GPG signatures are correct
- SAH512 hashes are correct
- Builds successfully from src distro

Comment only (no action required):
- Tag includes Maven wrapper and .gitignore whereas src distro does not

Mark

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

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

[Mark Thomas]

On 19/03/2019 05:42, Antoine Toulme wrote:

All, the results are in, from VP Legal:


Nitpick. VP, Brand Management rather than VP, Legal.

Mark


I am happy to approve the name in isolation. Specifically, the community must 
refrain from linking the project to any Star Wars references. The view of the 
community is that the community is likely to find that difficult. It was 
therefore agreed to look for a different name.


We need to pick another name.


On Mar 4, 2019, at 2:32 PM, Dave Fisher  wrote:

Hi -


On Mar 4, 2019, at 2:10 PM, Antoine Toulme  wrote:




On Mar 4, 2019, at 2:00 PM, Dave Fisher  wrote:

Hi -

I went to look at the Trademark name search and something is either messed up 
or autocorrected.

PODLINGNAMESEARCH-165 
Establish whether 
"Apache Obiwarn" is a Suitable Name

Isn’t the name supposed to be Obiwan and not Obiwarn?

No, the name is Obiwarn. With a r.


Well, my bad eye sight had my brain auto-correcting to what I expected to see. 
Then Daniel wrote what he did.

OK. Let’s look into Obiwarn and deal with Apple autocorrecting it to Obiwan … 
more Jedi mind tricks.

Regards,
Dave



Please look into it. Sorry, color me confused.

Regards,
Dave


On Mar 4, 2019, at 12:20 PM, Jim Jagielski  wrote:

Thx. We'll wait for the decision.


On Mar 4, 2019, at 2:05 AM, Antoine Toulme  wrote:

The ticket is now open: 
https://issues.apache.org/jira/browse/PODLINGNAMESEARCH-165

Cheers,

Antoine


On Mar 1, 2019, at 3:24 PM, Antoine Toulme  wrote:

Perfect, thank you.


On Mar 1, 2019, at 3:17 PM, Daniel Shahaf  wrote:

Antoine Toulme wrote on Fri, Mar 01, 2019 at 15:09:39 -0800:

I am happy to mention that you mentioned this term on list.


Thanks.


What language should I use?


The public part of PNS tickets should be factual, so I'd say:
.
"In the _Star Wars_ universe there exists a character named Obi-Wan Kenobi"
.
with a link to Wikipedia for good measure.

Cheers,

Daniel


On Mar 1, 2019, at 3:06 PM, Daniel Shahaf  wrote:

Antoine Toulme wrote on Fri, Mar 01, 2019 at 09:10:08 -0800:

I’ll open a pooling name search ticket for Obiwarn and will test the waters 
over there.


When you create a PNS ticket, please note on it the existence of
.


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




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




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




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






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




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




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



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

Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.6 [RC2]

[Mark Thomas]

On 06/03/2019 08:24, Huxing Zhang wrote:
> Hi,
> 
> On Wed, Mar 6, 2019 at 4:50 AM Mark Thomas  wrote:
>>
>> On 04/03/2019 11:34, Minxuan Zhuang wrote:
>>> Hello Incubator Community,
>>>
>>> The Apache Dubbo community has voted on and approved a proposal to release
>>> Apache Dubbo (Incubating) version 2.6.6.
>>>
>>> We now kindly request the Incubator PMC members review and vote on this
>>> incubator release.
>>>
>>> Apache Dubbo™ (incubating) is a high-performance, java based, open source
>>> RPC framework. Dubbo offers three key functionalities, which include
>>> interface based remote call, fault tolerance & load balancing, and
>>> automatic service registration & discovery.
>>>
>>> Dubbo community vote and result thread:
>>> https://lists.apache.org/thread.html/c1cff6eb1ec9ce2877a38a16145cf41a6ab3f2a6989a0f276da2226a@%3Cdev.dubbo.apache.org%3E
>>>
>>> The release candidates (RC2):
>>> https://dist.apache.org/repos/dist/dev/incubator/dubbo/2.6.6
>>>
>>> Git tag for the release (RC2):
>>> https://github.com/apache/incubator-dubbo/tree/dubbo-2.6.6
>>>
>>> Hash for the release tag:
>>> ba7f6f38c36675268ba64f21e97d02bda7a731dc
>>>
>>> Release Notes:
>>> https://github.com/apache/incubator-dubbo/blob/dubbo-2.6.6/CHANGES.md
>>>
>>> The artifacts have been signed with Key : DA2108479B0C1E71, which can be
>>> found in the keys file:
>>> https://dist.apache.org/repos/dist/dev/incubator/dubbo/KEYS
>>>
>>> The vote will be open for at least 72 hours or until necessary number of
>>> votes are reached.
>>>
>>> Please vote accordingly:
>>
>> Comments (no action required)
>> - The source archive does not contain the Maven wrapper.
>> - The source archive does not include the .gitignore file
>> - Hashes match
>> - Signatures are valid
>> - Build from source archive completes without error
>>
>> Trivial (fix in next release if project thinks it is an issue)
>> - The source archive name has a suffix "-source-release". Generally
>>   projects just use "-src".
>> - The binary archive names has a suffix "-bin-release." Generally
>>   projects just use "-bin"
>> - The naming convention does not seem consistent. I'd expect bin/src or
>>   binary/source not bin/source.
> 
> +1 to keep it consistent.
> 
>>
>> Major (must fix before release)
>> - The KEYS files contains the short fingerprints. It is trivial to forge
>>   these. All keys must be listed with the full fingerprint (40 chars).
> 
> I did see a short fingerprint is used in the release vote mail, do you
> mean that the full fignerprint should be used instead?
> I checked the KEYS[1] file, all the fingerprints are 40 chars.
> 
> [1] https://dist.apache.org/repos/dist/dev/incubator/dubbo/KEYS

Nope. I mis-read the key file. Sorry. There is no issue here. Consider
my +1 unconditional.

Mark


>>
>>
>>
>> Provided that the major issue listed above is addressed:
>>
>>> [X] +1 approve
>>> [ ] +0 no opinion
>>> [ ] -1 disapprove with the reason
>>
>> Mark
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
> 
> 


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

Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.6 [RC2]

[Mark Thomas]

On 04/03/2019 11:34, Minxuan Zhuang wrote:
> Hello Incubator Community,
> 
> The Apache Dubbo community has voted on and approved a proposal to release
> Apache Dubbo (Incubating) version 2.6.6.
> 
> We now kindly request the Incubator PMC members review and vote on this
> incubator release.
> 
> Apache Dubbo™ (incubating) is a high-performance, java based, open source
> RPC framework. Dubbo offers three key functionalities, which include
> interface based remote call, fault tolerance & load balancing, and
> automatic service registration & discovery.
> 
> Dubbo community vote and result thread:
> https://lists.apache.org/thread.html/c1cff6eb1ec9ce2877a38a16145cf41a6ab3f2a6989a0f276da2226a@%3Cdev.dubbo.apache.org%3E
> 
> The release candidates (RC2):
> https://dist.apache.org/repos/dist/dev/incubator/dubbo/2.6.6
> 
> Git tag for the release (RC2):
> https://github.com/apache/incubator-dubbo/tree/dubbo-2.6.6
> 
> Hash for the release tag:
> ba7f6f38c36675268ba64f21e97d02bda7a731dc
> 
> Release Notes:
> https://github.com/apache/incubator-dubbo/blob/dubbo-2.6.6/CHANGES.md
> 
> The artifacts have been signed with Key : DA2108479B0C1E71, which can be
> found in the keys file:
> https://dist.apache.org/repos/dist/dev/incubator/dubbo/KEYS
> 
> The vote will be open for at least 72 hours or until necessary number of
> votes are reached.
> 
> Please vote accordingly:

Comments (no action required)
- The source archive does not contain the Maven wrapper.
- The source archive does not include the .gitignore file
- Hashes match
- Signatures are valid
- Build from source archive completes without error

Trivial (fix in next release if project thinks it is an issue)
- The source archive name has a suffix "-source-release". Generally
  projects just use "-src".
- The binary archive names has a suffix "-bin-release." Generally
  projects just use "-bin"
- The naming convention does not seem consistent. I'd expect bin/src or
  binary/source not bin/source.

Major (must fix before release)
- The KEYS files contains the short fingerprints. It is trivial to forge
  these. All keys must be listed with the full fingerprint (40 chars).



Provided that the major issue listed above is addressed:

> [X] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason

Mark


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

Re: Withdraw from Incubator or TLP status?

[Mark Thomas]

On 05/03/2019 14:09, Bertrand Delacretaz wrote:
> Hi,
> 
> On Tue, Mar 5, 2019 at 7:27 AM Justin Mclean  wrote:
>> ...An Apache project can be retired to the Attic. [1] After this development 
>> could possibly occur elsewhere,
>> but there may be naming and trademark issues to consider
> 
> That's what happened in 2010 to http://ibatis.apache.org/ which was
> forked to mybatis.org - note the name change, required as the IBatis
> trademark belonged to the ASF.
> 
> Nobody can prevent someone from forking an Apache project elsewhere,
> but the trademarks of TLPs belong to the ASF, so that we can keep the
> project alive if someone else wants to work on it.
> 
> In the case of IBatis, the Apache project moved to the Attic about the
> same time, http://attic.apache.org/projects/ibatis.html - but Attic
> projects can be restarted, so in general it makes sense for us to keep
> the name.

Generally, yes. But. There is the option to allow the community to
continue to use the trademark (obviously without the preceding
"Apache"). Each request gets looked at on a case by case basis.

Mark

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

Re: Starting at the incubator and releases

[Mark Thomas]

On 25/02/2019 19:22, Dave Fisher wrote:




To me the main Incubator problem is most podlings do not have three fully 
engaged mentors.


+1


52 or 53 Incubating podlings may be too many.


+1


The Incubator may be too lenient in (a) allowing podlings in with minimal 
mentors


+1

The tricky part in all of this is that it isn't the podlings fault if 
the mentors don't engage.


We need more engaged mentors per podling. The obvious solutions to that 
are recruit more mentors (where from?) or accept fewer podlings (seems 
unfair to prospective podlings).


I think the IMPC has some tough decisions ahead.

Mark

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

Re: Binary jars in the source release which are only for testing

[Mark Thomas]

On 25/02/2019 14:15, Roman Shaposhnik wrote:
> On Mon, Feb 25, 2019 at 11:35 AM Mark Thomas  wrote:
>>
>> On 23/02/2019 06:18, Willem Jiang wrote:
>>> Hi,
>>>
>>> I just have a question about the Binary jars in the source release.
>>> According the Apache release policy, I cannot find any rule about the
>>> binary jars cannot be in the source release[1]. If we just have jars
>>> for testing purposes and those jar won't be a part of convenience
>>> binary release, I think it doesn't break the rule below:
>>>
>>> "In all such cases, the binary/bytecode package must have the same
>>> version number as the source release and may only add binary/bytecode
>>> files that are the result of compiling that version of the source code
>>> release.".
>>>
>>> Is it OK to ship those test binary jars in the source release kit?
>>
>> It depends ;)
>>
>> Generally, source releases should contain exactly that - source code. So
>> the aim should always be to not include compiled code - like JARs - in a
>> source release.
>>
>> That said, I have always been a little more relaxed about test code.
>> Sometimes you need to use class files and/or JARs in your testing. The
>> minimum - in my view - is that:
>> - it MUST be possible to produce a fully working binary from the source
>>   distribution
> 
> Big +1 to the above.
> 
>> - the source for any compiled files included in the source MUST be
>>   provided alongside the compiled files
> 
> Is this really a MUST in all situations? Sometimes a JAR file truly is a test
> artifact (like for negative testcases for example) and it may not even be
> possible to "compile it" -- its purpose in fact, may be to test something like
> a classloader for tripping up on "incorrect" JARs, etc.
> 
> Or did I misunderstand your MUST?

The view I was trying (and failing) to convey is that we don't want any
binary "magic" files in the release. The "source" may be the source as
in the input to a compiler. It might be a more complex recipe. Either
way it needs to carry sufficient information to enable other community
members to understand how the binary file was created and what they
would need to do if they wanted/needed to re-create the binary file at
some point in the future.

HTH,

Mark

> 
> Thanks,
> Roman.
> 
>> Ideally, class files, JAR files etc. would be constructed as required
>> when the tests are run. However, there are cases when it makes sense to
>> include the binary - e.g. the file needs to be compiled with a very
>> specific version of the compiler because it is testing something that
>> depends on a specific behaviour of that compiler version. It is arguably
>> better for users to provide the compiled file rather than requiring them
>> to obtain the specific compiler version required.
>>
>> For the record, Apache Tomcat has a small number of JAR and class files
>> in its source distribution. All related to testing and the source is
>> there for all of them. We could probably generate some of those at build
>> time. But, given the very small number of files concerned and the
>> complexity it adds to the build process, it isn't an itch any of the
>> community has felt the need to scratch. Yet.
>>
>> I also recall an instance - I think in Apache Commons BCEL - where we
>> needed to test with a faulty class file. From memory, we shipped the
>> class file in the source along with instructions on how to recreate it.
>> I don't recall exactly why but creating it at build time was problematic.
>>
>> In summary, I think you are fine as long as you meet the MUSTs I listed
>> above. Whether the project should look to generate those files at
>> build/testing time depends on circumstances. In most cases I would
>> expect them to be generated during building/testing but there can be
>> valid reasons for not doing so.
>>
>> Mark
>>
>>
>>
>>
>>>
>>> [1]http://www.apache.org/legal/release-policy.html#what
>>>
>>> Willem Jiang
>>>
>>> Twitter: willemjiang
>>> Weibo: 姜宁willem
>>>
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>>
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


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

Re: Binary jars in the source release which are only for testing

[Mark Thomas]

On 23/02/2019 06:18, Willem Jiang wrote:
> Hi,
> 
> I just have a question about the Binary jars in the source release.
> According the Apache release policy, I cannot find any rule about the
> binary jars cannot be in the source release[1]. If we just have jars
> for testing purposes and those jar won't be a part of convenience
> binary release, I think it doesn't break the rule below:
> 
> "In all such cases, the binary/bytecode package must have the same
> version number as the source release and may only add binary/bytecode
> files that are the result of compiling that version of the source code
> release.".
> 
> Is it OK to ship those test binary jars in the source release kit?

It depends ;)

Generally, source releases should contain exactly that - source code. So
the aim should always be to not include compiled code - like JARs - in a
source release.

That said, I have always been a little more relaxed about test code.
Sometimes you need to use class files and/or JARs in your testing. The
minimum - in my view - is that:
- it MUST be possible to produce a fully working binary from the source
  distribution
- the source for any compiled files included in the source MUST be
  provided alongside the compiled files

Ideally, class files, JAR files etc. would be constructed as required
when the tests are run. However, there are cases when it makes sense to
include the binary - e.g. the file needs to be compiled with a very
specific version of the compiler because it is testing something that
depends on a specific behaviour of that compiler version. It is arguably
better for users to provide the compiled file rather than requiring them
to obtain the specific compiler version required.

For the record, Apache Tomcat has a small number of JAR and class files
in its source distribution. All related to testing and the source is
there for all of them. We could probably generate some of those at build
time. But, given the very small number of files concerned and the
complexity it adds to the build process, it isn't an itch any of the
community has felt the need to scratch. Yet.

I also recall an instance - I think in Apache Commons BCEL - where we
needed to test with a faulty class file. From memory, we shipped the
class file in the source along with instructions on how to recreate it.
I don't recall exactly why but creating it at build time was problematic.

In summary, I think you are fine as long as you meet the MUSTs I listed
above. Whether the project should look to generate those files at
build/testing time depends on circumstances. In most cases I would
expect them to be generated during building/testing but there can be
valid reasons for not doing so.

Mark




> 
> [1]http://www.apache.org/legal/release-policy.html#what
> 
> Willem Jiang
> 
> Twitter: willemjiang
> Weibo: 姜宁willem
> 
> -
> 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: Fwd: [DISCUSS] can we use weex.io as the short domain namefortheapache project

[Mark Thomas]

All,

ASF policy states that:

"Apache projects must host official website content on an apache.org domain"

That said, if there are issues with access speeds from some locations 
I'd strongly urge affected projects to engage with our infrastructure 
team to find a solution. Maybe we can set up a www/TLP mirror in China. 
I have no idea how practical that is or if a better solution is 
available. The infrastructure folks are the ones to talk to.


Mark



On 18/02/2019 13:02, 申远 wrote:
Actually, with the tool provided by https://ping.chinaz.com/, there is 
huge difference of network speed between https://weex.apache.org/ and 
https://weex.io/ , though their content is totally the same.


The average speed for https://weex.io/ is *65ms* from 142 different IP 
address, while it is *271ms* for https://weex.apache.org/


But if using another domain is against the rule of Apache, I think I can 
live with it and redirect https://weex.io/ to https://weex.apache.org/


Best Regards,
YorkShen

申远


吴晟 Sheng Wu mailto:wu.sh...@foxmail.com>> 于 
2019年2月18日周一 下午5:16写道：


 > weex.apache.org  is fast too from my
network environment now.


The Chinese network status is strange, we all know. :) Right?

 > We had received several complaint years ago from Chinese users that
weex.apache.org  is slow, so we launched
weex-project.io  with the same
content of weex.apache.org . If this is
against rules, I think we can make
it redirect to weex.apache.org , not sure
whether we would receive complaint
again.

In my mind, redirect is better. You could try, and listen to the
community.


If really need some another, I suggest you to talk with Brand
Management Committee.[1]


Maybe publish an website, but don't use `weex` in name and say
clearly, this is not Apache Weex official documents,
just documents maintained by volunteers. This is not so cool, I know.


[1] https://www.apache.org/foundation/marks/#whoweare


--
Sheng Wu
Apache SkyWalking, ShardingSphere, Zipkin
Twitter, wusheng1108







-- Original --
From:  "申远"mailto:shenyua...@gmail.com>>;
Date:  Mon, Feb 18, 2019 05:07 PM
To:  "general"mailto:general@incubator.apache.org>>;

Subject:  Re: Fwd: [DISCUSS] can we use weex.io  as
the short domain namefortheapache project



weex.apache.org  is fast too from my network
environment now.

We had received several complaint years ago from Chinese users that
weex.apache.org  is slow, so we launched
weex-project.io  with the same
content of weex.apache.org . If this is
against rules, I think we can make
it redirect to weex.apache.org , not sure
whether we would receive complaint
again.

Best Regards,
YorkShen

申远


吴晟 Sheng Wu mailto:wu.sh...@foxmail.com>>
于2019年2月18日周一 下午4:56写道：

 > Hi
 >
 >
 > I don't know why it is slow, I just tried, very quickly.
 >
 >
 >
 >
 > --
 > Sheng Wu
 > Apache SkyWalking, ShardingSphere, Zipkin
 > Twitter, wusheng1108
 >
 >
 >
 >
 >
 >
 >
 > -- Original --
 > From:  "申远"mailto:shenyua...@gmail.com>>;
 > Date:  Mon, Feb 18, 2019 04:33 PM
 > To:  "general"mailto:general@incubator.apache.org>>;
 >
 > Subject:  Re: Fwd: [DISCUSS] can we use weex.io 
as the short domain name
 > fortheapache project
 >
 >
 >
 > >
 > > 3. I don't think ASF websites are facing GFW issue.
 >
 > ASF website is quite slow when accessing from China, I am not
sure whether
 > this is a GFW issue or simply the server is on another continent
without a
 > CDN.
 >
 > We received complains about weex.apache.org
 from China mainland years ago,
 > so we deploy website to weex-project.io 
for fast access in China, as many
 > of our users are from China and there is CDN for weex-project.io
 .  If
 > there is a solution for this issue, please let me know.
 >
 > Best Regards,
 > YorkShen
 >
 > 申远
 >
 >
 > 吴晟 Sheng Wu mailto:wu.sh...@foxmail.com>> 于2019年2月18日周一 下午3:52写道：
 >
 > > Hi YorkShen
 > >
 > >
 > > From my understanding, weex project, including branding and
logo, should
 > > be donated to ASF(at least before Graduation).
 > > The basic policy is, weex.apache.org 
should be the only official website
 > > for the project.
 > > And project's website should 

Fwd: Release Apache Dubbo OPS(Incubating) 0.1[RC3]

[Mark Thomas]

 Forwarded Message 
Subject: Re: Release Apache Dubbo OPS(Incubating) 0.1[RC3]
Date: Wed, 6 Feb 2019 10:10:10 +
From: Mark Thomas 
Reply-To: d...@dubbo.apache.org
To: d...@dubbo.apache.org

On 03/02/2019 03:52, Minxuan Zhuang wrote:



> Please vote accordingly:
> 
> [X] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason

Mark


Notes (no action required):
Signatures and hashes match.
The Maven wrapper is present in the repository but not the source release.
The .gitignore files have been excluded from the source release.
Various npm warnings during the build process
"mvn verify" completed successfully when run from the unpacked source
distribution

Minor issues (consider fixing for next release):
sha512 hashes are missing * that indicates that the hashed files are
binaries

There appear to be some unnecessary .gitkeep files in the repository

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

Re: Draft incubator report

[Mark Thomas]

On 05/02/2019 10:23, Justin Mclean wrote:
> Hi,
> 
>> We need a formulation which enables pre-release QA by non-coding
>> contributors.  I've given my attempt at formulating it.  Please give your
>> take on how to accomplish this.
> 
> As long as these are not available to the general public all is fine. [1]

s/available/advertised/

The pre-release artifacts are nearly always available to the general
public (i.e. they can download them if they wish). What matters is that
they are not advertised to the general public.

To put it another way:

Linking to snapshots on the public download page - not allowed.
Linking to snapshots on a page targeted at developers - allowed.

Mark

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

Re: [VOTE] Graduate Apache Unomi to TLP

[Mark Thomas]

On 22/01/2019 00:37, Greg Stein wrote:
> On Mon, Jan 21, 2019 at 3:21 PM Dave Fisher  wrote:
> 
>>  -0 (binding) - This podling has never completed a suitable podling name
>> search. It seems that people no longer consider that relevant as it is not
>> in the Maturity model and I’m not sure why. It could be because that is
>> ComDev and not the IPMC.
>>
> 
> The "Maturity Model" (MM) is just a thing developed by ComDev peeps. It has
> no bearing within the Foundation, other than as a lens for individuals to
> view projects. That lens is not part of the Incubator, or any other PMC.
> 
> Personally, I do not view the "podling name search" (PNS) as a gate. That
> is another imposition, from outside the Incubator, that has crept into the
> "Must Be Performed(tm)" guidelines for graduation. The Board is the
> ultimate arbiter of whether a podling can graduate, and a name search is
> informative for them, rather than gating for us [on the IPMC]. If a podling
> wants to be called "Apache Acme", and "gee, there are a lot of Acme
> products out there", then that is on the community. Not something for the
> Incubator to demand they change; just something for them to deal with. A
> community problem, rather than one for the Incubator or the Foundation
> itself.

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

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

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

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

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

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

Mark

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

Re: Official releases vs unreleased code

[Mark Thomas]

On 07/01/2019 12:05, Geertjan Wielenga wrote:
> So, just to be clear what this means in the context of Apache NetBeans.
> 
> Here's two different scenarios that relate to this:
> 
> 1. CoolBeans (coolbeans.xyz) is a distribution of Apache NetBeans, with the
> difference that it includes the 'enterprise' cluster (i.e., Jakarta/Java EE
> features) of Apache NetBeans, which we have not yet released. We are
> working to release this as part of our upcoming release and have several
> licensing issues remaining. However, since CoolBeans is not distributed by
> Apache, CoolBeans is not constrained by Apache's licensing concerns.
> 
> Reading Justin's e-mail, I interpret him to state that it is not allowed to
> promote releases to the wider community that contain not released code,
> i.e., on the Apache NetBeans webpage, we cannot promote CoolBeans, on
> Apache NetBeans Twitter, we cannot promote CoolBeans, on the Apache
> NetBeans mailing lists, we cannot promote CoolBeans.
> 
> Is this interpretation correct?

I would suggest reading "promote" in this context as "advertise as an
official ASF release" rather than "make people aware it exists".

Scenario 1 is a different issue. Coolbeans is a non-ASF product. That
makes it more of a branding / community issue than one of release policy.

Generally, projects don't promote down stream releases. Doing so creates
a risk of the ASF being viewed as biased (in favour of the organisation
producing the downstream release) rather than independent.

That said, if the community views it is in the best interest of the
community to promote Coolbeans then the community can do so. The
expectation is that the community would be equally happy to promote any
similar downstream project. If there are criteria about what the
community is and is not willing to promote then those criteria should be
(publicly) documented up front.


> 2. Even though we have not released the 'enterprise' cluster, we do have
> plugins from before we were an Apache project for Java/Jakarta EE features.
> These are available from a plugin portal and are built from the the same
> code as is found in the Apache NetBeans GitHub, though created from before
> that code was at Apache.
> 
> Can we promote these plugins?

Again, as non-ASF releases "make people aware they exist" is fine (same
caveats as above) but "advertise them as official ASF releases" then no.


Generally, I would only expect to see official ASF releases on:
- announcement e-mails from the project
- project main download page
- etc.

HTH,

Mark

> 
> Thanks,
> 
> Gj
> 
> 
> 
> 
> 
> On Sun, Jan 6, 2019 at 12:21 AM Justin Mclean 
> wrote:
> 
>> Hi,
>>
>> Over the last few months I’ve run into 1/2 dozen podlings who are making
>> and promoting releases to the wider community that contain unreleased code,
>> and I’m a little surprised that they were unaware that this is not allowed.
>> This also has come up in feedback received from the exit questionnaire.
>>
>> In the release policy [3] it clearly states:
>> "Projects MUST direct outsiders towards official releases rather than raw
>> source repositories, nightly builds, snapshots, release candidates, or any
>> other similar packages.”
>>
>> This has been discussed many times but these two legal JIRAs [1][2] spell
>> it out quite clearly. And while these tickets refer to docker the same
>> applies to any distribution mechanism.
>>
>> In short “It is appropriate to distribute official releases through
>> downstream channels, but inappropriate to distribute unreleased materials
>> through them.”
>>
>> So if your projects is using docker, PiPY, GitHub releases, npm or any
>> other ways of distribution please make sure that the wider community is
>> only pointed at official release and the best way to do this is not to
>> publish unreleased code on those platforms. Ask yourself is someone outside
>> of the project likely to use this and if the answer is yes then reconsider
>> how you are using that distribution channel and make sure it only contains
>> official releases.
>>
>> Thanks,
>> Justin
>>
>> 1. https://issues.apache.org/jira/browse/LEGAL-270
>> 2. https://issues.apache.org/jira/browse/LEGAL-427
>> 3. http://www.apache.org/legal/release-policy.html#publication
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
> 


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

Re: [VOTE] Graduate Apache Airflow to TLP

[Mark Thomas]

Sorry to be the bringer of bad news but there is a resolution to 
terminate a project on this month's board agenda so you'll be (if 
nothing else changes) the 199th active project.


Mark

On 06/12/2018 07:33, Bolke de Bruin wrote:

Oh nice :-) something for the press release I guess 

Op do 6 dec. 2018 04:20 schreef Justin Mclean 
HI,

If you do graduate (and no project retires) you'll become the 200th active
project at the ASF :-)

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






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

Re: [PROPOSAL] Changing requirements for IPMC

[Mark Thomas]

On 30/11/2018 06:04, Makoto Yui wrote:
> Justin,
> 
> I think it's a great idea. Podling project leads know the up-to-date
> ASF incubation process very well.

Apache projects (and podlings) don't have project leads.

> It helps finding active mentors.
> 
> As a release manager and PPMC of an incubator project, requiring more
> active mentor(s),
> I would be glad to give help the following podling projects.
> 
>> - has been involved in an incubating project from start to finish
> 
> BTW, is this (made a TLP project from incubator) a requirement?
> Or, on-going incubating project PPMC membe or committers can join to IPMC?
> 
> Thanks,
> Makoto
> 2018年11月25日(日) 8:07 Justin Mclean :
>>
>> Hi,
>>
>> So with some with some minor modification looks like this is all good. I’ll 
>> get a draft of the changes to go on our web site.
>>
>> If there’s anyone else who is not a member and think they have the 
>> experience to be an IPMC member please send to request to our private email 
>> list.
>>
>> Thanks,
>> Justin
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


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

Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.5 [RC1]

[Mark Thomas]

On 19/11/2018 08:34, victory wrote:
> Hello all,
> 
> This is a call for vote to release Apache Dubbo (Incubating) version 2.6.5.
> 
> The Apache Dubbo community has voted on and approved a proposal to release
> Apache Dubbo (Incubating) version 2.6.5.
> 
> We now kindly request the Incubator PMC members review and vote on this
> incubator release.
> 
> Apache Dubbo™ (incubating) is a high-performance, java based, open source
> RPC framework. Dubbo offers three key functionalities, which include
> interface based remote call, fault tolerance & load balancing, and
> automatic service registration & discovery.
> 
> Dubbo community vote and result thread:
> https://lists.apache.org/thread.html/32ec5794c3ec32ad580489836458a4039fd0b3f48f884537c99e28d7@%3Cdev.dubbo.apache.org%3E
> 
> A minor issue also can be found in the above thread.
> 
> The release candidates (RC1):
> https://dist.apache.org/repos/dist/dev/incubator/dubbo/2.6.5
> 
> Git tag for the release (RC1):
> https://github.com/apache/incubator-dubbo/tree/dubbo-2.6.5
> 
> Hash for the release tag:
> 38e0f15be33a5edb35b45d2c5d7c6be753bdd888
> 
> Release Notes:
> https://github.com/apache/incubator-dubbo/blob/dubbo-2.6.5/CHANGES.md
> 
> The artifacts have been signed with Key : A3A1CA7A5D4A3981, which can be
> found in the keys file:
> https://dist.apache.org/repos/dist/dev/incubator/dubbo/KEYS
> 
> Look at here for how to verify this release candidate:
> https://github.com/apache/incubator-dubbo-website/blob/asf-site/blog/en-us/prepare-an-apache-release.md#prepare-apache-release
> 
> The vote will be open for at least 72 hours or until necessary number of
> votes are reached.
> 
> Please vote accordingly:
> [X] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason

I'm seeing a lot of "com.alibaba..." in the build logs and very little
"org.apache...". I thought the packaging renaming was completed some
time ago. Am I missing something?

Builds from tag without errors.

Hashes match.

Signatures are good.
(Key is not in web of trust)

Source distribution matches git tag with the expected exception of the
Maven wrapper files.

Mark

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

Re: [VOTE] Retire ODF Toolkit

[Mark Thomas]

On 16/11/2018 19:54, Dave Fisher wrote:



> [X] +1 - Retire ODF Toolkit.
> [ ] -1 - Do not retire ODF Toolkit. I intend to become a Mentor and try to 
> make the community happen.

Mark

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

Re: How to review so-called "binary releases"?

[Mark Thomas]

On 13/11/2018 20:49, Roman Shaposhnik wrote:
> Personally, given the amount of binary releases that are distributed off of
> our very own infrastructure (and I'm not even counting our namespace
> on things like Docker hub -- I'm just talking about the INFRA we run) I don't
> think that the argument "binary releases are NOT endorsed by ASF" will
> fly very far.
> 
> I think the best defense for us is to, perhaps, position them as UGC, but
> given the practices around existing PMC I don't think that would be easy to
> do.
> 
> So the question really boils down to -- how much of a liability this could
> potentially be for us?

Applying the usual test of "What issues have we seen in the last 20
years?" I can't think of any that have been specific to a binary release.

Of the issues I can recall with releases since I have been involved at
the ASF (and I'm sketchy on the details because issues are few and far
between and I haven't gone looking in the archives):

1. Dependencies with inappropriate licenses. Perhaps more likely with
binary releases because they tend to ship with more dependencies but I
don't recall this ever being more than "Whoops. Tell the users. Do a new
release to fix it. Be more careful in future. Carry on." for either
binary or source releases.

2. Copyright infringement. The only instance I can recall of this was a)
related to a source release and b) invalid because the accusing party
had actually originally copied "their" source from us and removed our
license headers. If anything, I think issue is less likely with a binary
release.

3. Download traffic. Some binaries are large and much more likely to
cause infrastructure issues if the mirror network is not used correctly.
Infra has monitoring in place to a) identify issues and b) stop them
causing outages.

So overall, the liability looks to be well within what we are already
managing. I don't see anything that concerns me. Unless I have missed
something.

Mark

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

Re: Approaching Apache's 200th top level project and more than 300 projects have gone through the incubator

[Mark Thomas]

On 02/11/2018 22:48, Justin Mclean wrote:
> Hi,
> 
> It looks like the next project to graduate after Griffin will be the ASF’s 
> 200th top level project!

Assuming no other projects get moved to the attic and there are a couple
heading in that direction ;)

Mark

> 
> We’ll also recently passed the 300th project to go through the incubator. [1]
> 
> Thanks,
> Justin
> 
> 1. https://whimsy.apache.org/roster/
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


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

Re: [VOTE] Release Apache Dubbo (Incubating) 2.6.4 [RC1]

[Mark Thomas]

+1 binding

The sha512 hash is missing the '*' marker to indicate that this is a
binary file. Minor issue but one that was present on the previous
release and should have been fixed by now.

I also see the minor issue with the work directory structure. Not a show
stopper.

Builds successfully from source distribution.

Mark


On 25/09/18 03:04, Jerrick Zhu wrote:
> Hello all,
> 
> This is a call for vote to release Apache Dubbo (Incubating) version 2.6.4.
> 
> The Apache Dubbo community has voted on and approved a proposal to release
> Apache Dubbo (Incubating) version 2.6.4.
> 
> We now kindly request the Incubator PMC members review and vote on this
> incubator release.
> 
> Apache Dubbo™ (incubating) is a high-performance, java based, open source
> RPC framework. Dubbo offers three key functionalities, which include
> interface based remote call, fault tolerance & load balancing, and
> automatic service registration & discovery.
> 
> Dubbo community vote and result thread:
> https://lists.apache.org/thread.html/8d5c39eece6288beed2e22ca976350728c571d2a9cef1c9a9e56a409@%3Cdev.dubbo.apache.org%3E
> A minor issue also can be found in the above thread.
> 
> The release candidates (RC1):
> https://dist.apache.org/repos/dist/dev/incubator/dubbo/2.6.4
> 
> Git tag for the release (RC1):
> https://github.com/apache/incubator-dubbo/tree/dubbo-2.6.4
> 
> Hash for the release tag:
> 88037747a3b69d3225c73f6fbcda36ebd8435887
> 
> Release Notes:
> *https://github.com/apache/incubator-dubbo/blob/dubbo-2.6.4/CHANGES.md
> *
> 
> The artifacts have been signed with Key : 7955FB6D1DD21CF7, which can be
> found in the keys file:
> https://dist.apache.org/repos/dist/dev/incubator/dubbo/KEYS
> 
> Look at here for how to verify this release candidate:
> https://github.com/apache/incubator-dubbo-website/blob/asf-site/blog/en-us/prepare-an-apache-release.md#prepare-apache-release
> 
> The vote will be open for at least 72 hours or until necessary number of
> votes are reached.
> 
> Please vote accordingly:
> [ ] +1 approve
> [ ] +0 no opinion
> [ ] -1 disapprove with the reason
> 
> Best regards,
> Jerrick
> 


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

Re: Auto-cleaning up Stale PRs

[Mark Thomas]

On 12/09/18 19:16, Sid Anand wrote:
> A stale PR is defined by a policy -- for example, 60 days without any
> movement on the PR.

Automatically closing such issues is not going to do anything to aid
community building and is likely to actively damage such efforts.

> Stale PRs would be bad experiences in general for community members, but
> after no movement for 60 days, this is just about cleaning up PRs that are
> not getting feedback from the committers or PR submitters.

That is the wrong solution the problem.

If reporters of issues are not responding to questions and there is
genuinely nothing the community can do to progress the issue without
their input then closing the issue is fair enough. But that should very
much be the exception rather than the rule. In projects I am involved in
I probably do that a handful of times a year. However, even in a good
chunk of those cases, the main reason for the lack of response from the
OP is that the community did not respond to the original report for an
excessively long time.

If the committers are not responding to issues in a timely manner then
the solution is to start looking for more committers.

Reporting an issue is often the first interaction someone new to the
community has with the project. It should be treated as an opportunity
to attract new members to the community and to grow the project.

Mark


> 
> -s
> 
> On Wed, Sep 12, 2018 at 10:58 AM Dave Fisher  wrote:
> 
>> Hi -
>>
>> I was pointing out a potential community problem which is what we are
>> about here in the Incubator.
>>
>> On Sep 12, 2018, at 10:27 AM, Sid Anand  wrote:
>>
>> A stale PR has not activity for some length of time.
>> https://github.com/probot/stale
>>
>> The policy file example shown on that link it pretty easy to follow, so
>> I'll avoid pasting a wall of text into this email.
>>
>> This seems like a pretty valuable and much-needed piece of management-y
>> software. Unfortunately, I was informed Apache Infra could not grant write
>> perms to this GitHub plugin. I'd like to understand how we decide which
>> plugins on GitHub get whitelisted?
>>
>>
>> The Incubator does not make these decisions. The Apache Infrastructure
>> team makes these.
>>
>> You can contact Infra - https://www.apache.org/dev/infra-contact
>>
>> Regards,
>> Dave
>>
>>
>> -s
>>
>> On Wed, Sep 12, 2018 at 7:39 AM Dave Fisher  wrote:
>>
>> Hi -
>>
>> What if the stale PR is from a new community member who is trying to make
>> a contribution? Those should be handled by a committer with direct
>> discussion.
>>
>> Regards,
>> Dave
>>
>> Sent from my iPhone
>>
>> On Sep 11, 2018, at 7:40 PM, Hagay Lupesko  wrote:
>>
>> Im also interested in this PR policy automation.
>>
>> For Apache MXNet, there is no automation that I am aware of that handles
>> that. And it can be super helpful in handling stale PRs...
>>
>> Hagay
>>
>> On Tue, Sep 11, 2018, 12:07 Sid Anand  wrote:
>>
>> Hi Folks!
>> I wanted a policy-driven approach to automatically label, comment, and
>> close inactive/stale PRs. Probot does this, but need some write perms to
>> GitHub.
>>
>> https://github.com/probot/stale
>>
>> I just learned this is not possible per
>> https://issues.apache.org/jira/browse/INFRA-17005
>>
>> How are other projects solving this problem? And why is probot not on
>>
>> say
>>
>> an approved list of GitHub integrations?
>>
>> -s
>>
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
>>
>>
> 


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

Re: [VOTE] Release Apache Dubbo (Incubating) 2.6.3 [RC5]

[Mark Thomas]

On 03/09/18 03:32, Jun Liu wrote:



> Please vote accordingly:
> [X] +1 approve 
> [ ] +0 no opinion 
> [ ] -1 disapprove with the reason

Notes:
==

Hash and signature match.

Source zip matches Git tag (apart from expected differences of
.gitignore and Maven wrapper)

Builds and all tests except one pass.


Issues from previous RC still present in this RC:
=

The sha512 hashes are missing the '*' marker that indicates they are
hashes for binary files rather than text files. Trivial issue. New RC
not required.


New issues
==

Tests seem to expect 127.0.0.2 to be a valid IP. If this is the case,
consider documenting the requirements to run the tests somewhere obvious
in the source tree. Trivial issue. New RC not required.

I see the following test failures:
  Oracle Java 8 update 181
  Ubuntu 18.04.1 LTS (fully patched)
  Maven 3.5.4

This fails consistently for me:
---
Test set: com.alibaba.dubbo.config.AbstractInterfaceConfigTest
---
Tests run: 38, Failures: 1, Errors: 0, Skipped: 0, Time elapsed: 0.119
sec <<< FAILURE! - in com.alibaba.dubbo.config.AbstractInterfaceConfigTest
checkApplication1(com.alibaba.dubbo.config.AbstractInterfaceConfigTest)
Time elapsed: 0.006 sec  <<< FAILURE!
junit.framework.ComparisonFailure: expected:<10[0]> but was:<10[]>
at
com.alibaba.dubbo.config.AbstractInterfaceConfigTest.checkApplication1(AbstractInterfaceConfigTest.java:90)

I note that this test has been observed to fail for other community
members in earlier RCs.

I can recreate this failure on the command line but not in an IDE.

Whether this failure is significant enough to halt the release is
something for those more knowledgeable about Dubbo than I to decide.


Mark

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

Re: Graduation Resolutions Should Not Include Project Bylaws Clause

[Mark Thomas]

On 03/09/18 05:53, P. Taylor Goetz wrote:
> 
> 
>> On Sep 3, 2018, at 12:10 AM, Greg Stein  wrote:
>>
>> Personally, I'd prefer that the concept of project bylaws disappear. Move
>> to "community guides". A *guide* rather than a *ruleset*. The Board has
>> kinda gone quiet on the discussion, but hopefully it will pick it back up,
>> to provide some guidance here.
> 
> ++1
> 
> All projects need is sane (in ASF terms) developer guidelines.

Exactly.

Repeating some points I made on board@

There is a lot of good content in project bylaws.

Some project bylaws duplicate content that exists at the foundation
level. I think that sort of duplication is unhelpful as, over
time, the duplicates tend to diverge.

I would prefer to see the project level content as community guidelines.
Codifying them as bylaws makes them harder to change and reduces
flexibility.

For example, some project level bylaws appear require a 72 hour voting
period for a release. That might not be in the best interest of the
project if a security release needs to be made in a hurry. I have seen
release votes that have lasted just a few hours when a security fix
needed to be made quickly.

A further issue is that if a security release is made with a voting
period of less than 72 hours is that still an act of the foundation if
it violates the project's bylaws? I don't know the answer to that
question and I don't think it is a good use of anyone's time figuring it
out.

Similarly, I can think a several situations where I've used CTR on an
RTC branch because - in my judgement - doing so was in the best
interests of the project. (And as it happens none of the committers at
the time disagreed.)

It is my view that codifying a PMC's standard way of operating in bylaws
can limit the PMC's options when dealing with non-standard situations. I
think it is better for the PMC to retain the flexibility to use if they
need to.

Mark

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

Re: Poddlings length of time in the incubator

[Mark Thomas]

On 26/08/18 02:30, Justin Mclean wrote:
> Hi,
> 
>> I’ve discussed this some on the ODF toolkit dev list. Development was 
>> recently moved to Git. The Incubator needs to decide if we will turnover the 
>> domains that were donated in 2011 by IBM(?) to the only consistent 
>> developer. If that is true then we can quickly let them retire, but survive 
>> on Github.
> 
> I also saw you mentioned it in a previous incubator report for the podling. 
> What are the domain names in question? I think doing as you suggested sounds 
> like a good idea do you want to take that back to the PPMC and discuss and/or 
> vote on doing that.
> 
> Any other IPMC members think differently?

The podling PMC can make a recommendation but the decision to release a
domain name to a third party needs the approval of VP Brand Management.

We also need to find the transfer agreements (if any) for those domains
to see what the ASF agreed to at the time of donation. It is not unheard
of for such agreements to include a clause that ownership reverts to the
donor if the podling does not graduate.

Mark

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

Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.3 [RC3]

[Mark Thomas]

On 12/08/18 08:12, Jun Liu wrote:



> Please vote accordingly:
> [ ] +1 approve 
> [ ] +0 no opinion 
> [X] -1 disapprove with the reason (binding)

The sha512 hashes are missing the '*' marker that indicates they are
hashes for binary files rather than text files. Trivial issue. Can be
addressed in the next release.

I'd expect the files to be named "apache-dubbo..." not "dubbo...". Nice
to have (not all Apache projects use this naming convention). Something
to consider for the next release.

Consider including mvnw and mvnw.cmd in the source release so it is
simpler to get started with the build from a source release.

The 2.6.3 tag does not agree with the source release. This is a
significant issue and enough for me to vote against the release. A diff
shows most (all?) of the pom.xml have a version of "2.6.4-SNAPSHOT" in
the tag but "2.6.3" in the source release.

I dug into this a little. At first I thought the tag / commit in the
vote was wrong. It is. But is isn't just that. If I go back to

a8be0eaaddab198ed03b0150d4db03e2b22f023f

things are better but:
a) there are still differences
b) the tag includes multiple commits after this point


Mark

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

Re: [VOTE]: Release Apache Dubbo (Incubating) 2.6.2 [RC2]

[Mark Thomas]

Checks:

Source bundle:
- Hash and signature are correct
- Hash of tag matches the hash quoted in the release vote mail
- Contents of git tag match src bundle except for .gitignore file
- Maven build passes
- LICENSE and NOTICE look correct for source bundle
- LICENSE and NOTICE look correct for binary bundle

+1 to release



I have the following minor review comments (none of which warrant
another RC):

I strongly recommend that you include the full fingerprint of the
signing KEY in the KEYS file as well as the key ID. See [1] for an
example where some of the keys have this. A few years ago an attack was
demonstrated ([2], [3]) that show it was possible to create collisions
in the key ID. Using the full fingerprint mitigates this attack.

No concerns with the file name used. Just a comment that the usual
naming convention would be:
apache-dubbo-incubating-2.6.2-src.zip

I'd suggest including the .gitignore file in the src release.

I was a little surprised that the binary bundle was just the JARs rather
than something that a user could unpack and run via dubbo.sh /
dubbo.bat. There isn't anything wring with this, just not what I am used to.

Mark


[1] https://dist.apache.org/repos/dist/release/tomcat/tomcat-9/KEYS
[2] http://pgp.mit.edu/pks/lookup?op=get=0x10C01C5A2F6059E7
[3] http://pgp.mit.edu/pks/lookup?op=get=0xB6FB7A022F6059E7

On 29/05/18 09:47, Jun Liu wrote:
> Hello All,
> 
> This is a call for vote to release Apache Dubbo (Incubating) version 2.6.2.
> 
> The Apache Dubbo community has voted on and approved a proposal to release 
> Apache Dubbo (Incubating) version 2.6.2.
> 
> We now kindly request the Incubator PMC members review and vote on this 
> incubator release.
> 
> Apache Dubbo™ (incubating) is a high-performance, java based, open source RPC 
> framework. Dubbo offers three key functionalities, which include interface 
> based remote call, fault tolerance & load balancing, and automatic service 
> registration & discovery. 
> 
> Dubbo vote thread:
> https://lists.apache.org/thread.html/38560cb159a5c32d0cf98485c9fe791505fbc52d18d86a37713582f0@%3Cdev.dubbo.apache.org%3E
>  
> 
> 
> Dubbo vote result thread:
> https://lists.apache.org/thread.html/0b1e022a32e136ff0a9b42e7ef7da5ccc7d256d175394c2d5858f1cf@%3Cdev.dubbo.apache.org%3E
>  
> 
> 
> The release candidates:
> https://dist.apache.org/repos/dist/dev/incubator/dubbo/2.6.2 
> 
> 
> Git tag for the release:
> https://github.com/apache/incubator-dubbo/tree/dubbo-2.6.2 
>  
> 
> Hash for the release tag:
> 5eeb240337ccfbc820d4bde023d8cf643f33d735
> 
> Release Notes:
> https://github.com/apache/incubator-dubbo/blob/2.6.2-release/CHANGES.md 
> 
> 
> The artifacts have been signed with Key : 28681CB1, which can be found in the 
> keys file:
> https://dist.apache.org/repos/dist/dev/incubator/dubbo/KEYS 
> 
> 
> The vote will be open for at least 72 hours or until necessary number of 
> votes are reached.
> 
> Please vote accordingly:
> [ ] +1 approve 
> [ ] +0 no opinion 
> [ ] -1 disapprove with the reason
> 
> Thanks.
> Jun Liu,
> on behalf of The Apache Dubbo (Incubating) Team
> 


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

Re: Review mailing list membership?

[Mark Thomas]

On 18/04/18 01:47, Gian Merlino wrote:
> Thanks Taylor!
> 
> Do you know if this is something that the PPMCs are supposed to have access
> to or should we be asking you for help if we want to check again?

The best solution would be for other members of the community to
volunteer to moderate the mailing lists. While it makes sense for
mentors to do this initially, it is something that I'd expect to see
transfer to others over time.

Mark


> 
> On Tue, Apr 17, 2018 at 2:44 PM, P. Taylor Goetz  wrote:
> 
>> I sent the subscriber list for dev@druid and private@druid to
>> private@druid.
>>
>> -Taylor
>>
>>> On Apr 17, 2018, at 5:31 PM, P. Taylor Goetz  wrote:
>>>
>>> I can do it when I’m back at a computer. Basically you have to send the
>> ezlm email from an ASF machine. The easiest way is to ssh into minotaur.a.o
>> and use the mail command to send the email.
>>>
>>> Do you want just the subscription list for dev@ or private@ as well?
>>>
>>> -Taylor
>>>
 On Apr 17, 2018, at 5:18 PM, Julian Hyde  wrote:

 I’m one of your (druid codling’s) mentors and, yes, I moderate the
>> druid lists. I tried a week or so ago to list the members of druid’s lists
>> and struck out.

 In twenty minutes, I couldn’t find the solutions listed below:  whimsy
>> and dev-l...@druid.apache.org . (I
>> looked at https://mail-archives.apache.org/mod_mbox/druid-dev/ <
>> https://mail-archives.apache.org/mod_mbox/druid-dev/> for instance, and
>> emailed dev-h...@druid.apache.org .)

 So either I’m stupid or the documentation needs improvement (or both).

> On Apr 17, 2018, at 11:13 AM, Gian Merlino  wrote:
>
> I didn't know it existed until now - thanks! I just tried it from my
>> apache
> email and got the response "fatal: Command allowed only to moderators
> (#5.7.1)". Maybe only our mentors are set up as moderators?
>
>> On Tue, Apr 17, 2018 at 11:08 AM, Christopher 
>> wrote:
>>
>> Have you tried the tool at
>> https://whimsy.apache.org/committers/moderationhelper.cgi ?
>>
>>> On Tue, Apr 17, 2018 at 2:06 PM Gian Merlino 
>> wrote:
>>>
>>> Hi incubators,
>>>
>>> Is there a tool somewhere to review the membership of a mailing list?
>>>
>>> We (Druid) are working on migrating our mailing lists now. As I work
>> out
>>> the logistics of doing that I am finding that it would help to know
>> how
>>> many people from the old list have subscribed to the new one, as we
>> have
>>> been encouraging people to do for about a month. If the overlap is
>> good
>>> then we know we are clear to migrate without leaving too many people
>>> behind. If the overlap is poor then we know we need to do more
>> outreach
>> to
>>> get people to subscribe to the new list.
>>>
>>> Gian
>>>
>>

>>
>>
> 


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

Re: [DISCUSS] Absent mentors

[Mark Thomas]

On 01/04/18 21:26, Dave Fisher wrote:
> 
>> On Apr 1, 2018, at 1:15 PM, Shane Curcuru > > wrote:
>>
>> Jim Jagielski wrote on 4/1/18 10:19 AM:
>>> Would it be possible to generate a short list of all current
>>> mentors for all current podlings to see how many podlings
>>> each mentor is signed up for? That would be a good metric
>>> to know.
>>
>> Presuming podlings.xml is kept updated:
>>
>>
>> https://svn.apache.org/repos/asf/incubator/public/trunk/content/podlings.xml
>>
>> That now sorts by @status first, so current podlings are on top.  That's
>> separate from whimsy cross-checks of what's listed in board reports and
>> actual signoffs.
> 
> The clutch runs periodically and
> generates 
> https://svn.apache.org/repos/asf/incubator/public/trunk/content/clutch/clutchm.ent
>  
> 
> This file has each mentor listed. There are duplicates lines when people
> have variations on their names in the date in podlings.xml. Probably
> there needs to be a fix to use username attribute and not the mentor
> value in the clutch.py program.
> 
> I can see people in the list who probably don’t even think they are a
> mentor to a podling.
> 
> Should we send a note to all mentors recorded asking if they are still
> engaged?

That seems like a sensible first step to me. I suggest asking for
explicit confirmation that they wish to continue as a mentor. That
should hopefully give us a better picture of how things currently stand.

Mark


> 
> Regards,
> Dave
> 
>>
>> -- 
>>
>> - Shane
>>  Director & Member
>>  The Apache Software Foundation
>>
>> -
>> 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: Self Serve & IPMC Members

[Mark Thomas]

On 12/03/18 18:36, Chris Lambertus wrote:
> 
> 
>> On Mar 12, 2018, at 6:23 AM, Greg Stein <gst...@gmail.com
>> <mailto:gst...@gmail.com>> wrote:
>>
>> On Mon, Mar 12, 2018 at 6:57 AM, Mark Thomas <ma...@apache.org
>> <mailto:ma...@apache.org>> wrote:
>>
>> On 09/03/18 21:47, Chris Lambertus wrote:
>> > My understanding is that any pmc-chair can create resources for any 
>> project via selfserve.a.o. It does not have to be the pmc chair of that 
>> specific project, so there should be quite a few people who can create these 
>> resources at any given time.
>>
>> >... 
>>
>> We trust ASF members. They have access to security@ and a bunch of
>> other
>> sensitive lists and they should be familiar enough with the foundation
>> standards and procedures - or at least self-aware enough to know when
>> they don't know.
>>
>>
>> There's general agreement on that, I believe. ... But, ugh, it appears
>> that our LDAP schema doesn't easily support this right now :-(
>>
>> We'll look into how to make this happen. And open a Jira tracking
>> issue for it.
> 
> 
> 
> We’ve implemented a workaround for the LDAP issue. Selfserve now allows
> Members as well as PMC chairs to create resources.

Very nice.

Thanks for the quick turn-around.

Mark

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

Re: Self Serve & IPMC Members

[Mark Thomas]

On 09/03/18 21:47, Chris Lambertus wrote:
> 
> 
>> On Mar 9, 2018, at 1:35 PM, Mark Thomas <ma...@apache.org> wrote:
>>
>> On 09/03/18 21:11, Chris Lambertus wrote:
>>> I am specifically referring to the creation of git repos with my reply,
>>> nothing else. You are correct in that the other selfserve.a.o tools for
>>> Jira, Confluence, lists, etc., are pmc-chairs, root, and secretary only.
>>> We will try and be more accurate about the karma specifics when closing
>>> issues as being “self service.”
>>>
>>> -Chris
>>
>> Is there any chance of relaxing the restrictions there a little? I'm
>> thinking either to include members of the incubator PMC or, making it a
>> little wider - ASF members?
> 
> I think it’s worth a discussion. With the existing technology, I believe 
> opening up to PMCs would also include PPMCs, and that’s where we feel the 
> greatest risk would be, as PPMC members may not be fully aware of standards 
> and procedures. My personal feeling is that adding the IPMC access to 
> selfserve is warranted, since that is where the bulk of the requests tend to 
> come from. Others in Infra may feel differently. I’d encourage some 
> discussion here pro or con, and see where we land.

I agree opening it up to all PMC and PPMC members would create too much
risk.

>> I get that this is increasing risk. I'm wondering if the benefit it
>> would give in terms of unblocking incubator mentors (and PMCs where the
>> Chair is unavailable) is worth that risk.
> 
> 
> My understanding is that any pmc-chair can create resources for any project 
> via selfserve.a.o. It does not have to be the pmc chair of that specific 
> project, so there should be quite a few people who can create these resources 
> at any given time.

Quite frequently this is the case but there are also a fair number of
instances where this is not the case for some projects. I certainly have
had to fill in for a PMC chair a few times using my infra karma. Rather
than relying on another PMC chair or officer happening to be around, or
on a mentor also being a PMC chair or officer, I'd like to see this
opened up a little.

We trust ASF members. They have access to security@ and a bunch of other
sensitive lists and they should be familiar enough with the foundation
standards and procedures - or at least self-aware enough to know when
they don't know.

Opening this up to include ASF members addresses all of the instances I
can think of:
- it would include all podling mentors since they must be ASF members
- it would include the IPMC for the same reason, allowing them to
  back-stop the mentors if required
- it would enable ASF members on PMCs to provide cover if the PMC chair
  was unavailable.

Mark

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

Re: Self Serve & IPMC Members

[Mark Thomas]

On 09/03/18 21:11, Chris Lambertus wrote:
> I am specifically referring to the creation of git repos with my reply,
> nothing else. You are correct in that the other selfserve.a.o tools for
> Jira, Confluence, lists, etc., are pmc-chairs, root, and secretary only.
> We will try and be more accurate about the karma specifics when closing
> issues as being “self service.”
> 
> -Chris

Is there any chance of relaxing the restrictions there a little? I'm
thinking either to include members of the incubator PMC or, making it a
little wider - ASF members?

I get that this is increasing risk. I'm wondering if the benefit it
would give in terms of unblocking incubator mentors (and PMCs where the
Chair is unavailable) is worth that risk.

Mark



>> On Mar 9, 2018, at 1:07 PM, John D. Ament > > wrote:
>>
>> Chris,
>>
>> As far as I know, self serve is for more than just git repos.  It also
>> supports JIRA requests, confluence, mailing lists.  Each of these are
>> also chair only and where the issue comes in.
>>
>> John
>>
>> On Fri, Mar 9, 2018 at 4:04 PM Chris Lambertus > > wrote:
>>
>>
>>> On Mar 9, 2018, at 2:47 AM, John D. Ament >> > wrote:
>>>
>>> Hi Infra
>>>
>>> Just as a heads up, there's an on going thread on
>>> general@incubator about podling setup.  One of the assumptions is
>>> that all IPMC members can use Self Serve [1] [2], however that is
>>> not the case.  I have updated the mentor guide to tell people to
>>> use the old way (JIRA tickets) if they cannot use it.
>>
>>
>> IPMC members can technically create GITBOX repos, although they
>> may not see the podling in the dropdown if they are not associated
>> (in LDAP) with the podling. PPMC members can create GITBOX repos
>> for their associated projects.
>>
>> Only pmc-chairs, root, and secretary can create GIT-WIP repos.
>>
>>
>> https://selfserve.apache.org  is
>> for creating GIT-WIP repos.
>>
>> https://gitbox.apache.org  is for
>> creating GITBOX (r/w github) repos.
>>
>>
>> The miscommunication is in the selection of git-wip vs. gitbox
>> repos. We have generally been asking that all new podlings go on
>> gitbox, but there is clearly some confusion regarding the
>> “self-serve” nomenclature and who can do what (including within
>> infra!)
>>
>>
>> We’ll try and update the documentation on the actual self-serve
>> pages to make it more indicative of the karma requirements, but I
>> hope this clears up the issue for the Incubator. If you find any
>> of the above to not be the case, please let Infra know so we can
>> sort it out.
>>
>>
>> -Chris
>> ASF Infra
>>
>>
>>
>>>
>>> Please let me know if that's an OK approach.
>>>
>>> John
>>>
>>> [1]: https://issues.apache.org/jira/browse/INFRA-16115
>>> [2]: 
>>> https://lists.apache.org/thread.html/170f57f68100e6099bdc37bc529e6250130f7570a1618ad0fc5d5ce1@%3Cgeneral.incubator.apache.org%3E
>>>
>>>
> 


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

Re: Podling setup

[Mark Thomas]

On 09/03/18 08:42, Julian Hyde wrote:
> I saw the mentor’s guide, went to selfserve as it suggested, and selfserve 
> would not let me log in. (It still won’t.) So, the line "Most of the 
> resources you will request can be done via Self Service.” is not true.
> 
> Thanks for fixing LDAP.

No problem.

I've dug into the selfserve.a.o code and I can confirm that those pages
are restricted to root, secretary and PMC chairs. Mentors are not
included so the guide needs updating (or selfserve.a.o changing).

I haven't yet dug into how Whimsy identifies mentors. That is next on my
TODO list to see if there is an easy patch that could be proposed for
selfserve.a.o

Mark

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

Re: Podling setup

[Mark Thomas]

On 09/03/18 07:47, Julian Hyde wrote:
> 
> 
>> On Mar 8, 2018, at 4:51 AM, Mark Thomas <ma...@apache.org> wrote:
>>
>> On 07/03/18 23:24, Julian Hyde wrote:
>>> I’m a mentor of a new podling, Druid. I would like to help them get set up, 
>>> e.g. create mailing lists, create git repos. I tried to use 
>>> https://selfserve.apache.org/ <https://selfserve.apache.org/> for these, 
>>> but it only allows officers (i.e. PMC chairs).
>>>
>>> How is this supposed to work? Is the podling supposed to log INFRA tickets 
>>> for everything? Am I supposed to nag the IPMC chair for everything? Or 
>>> should I reach out to friends who happen to be PMC chairs?
>>>
>>> The red tape is getting me down.
>>
>> Having to send one e-mail to ask for help is hardly red-tape.
> 
> Quite a few emails, actually. I’ve already been in conversation with John 
> Ament to get the mailing lists, and Luciano Resende made a few suggestions, 
> including using selfserve.apache.org <http://selfserve.apache.org/>.
> 
> The advice to podlings is “ask your mentors” but this mentor is finding 
> himself frustrated - no clear guidelines what to do, and when I discover 
> options I don’t have enough karma.

Have you seen the Mentor's guide? It covers most (all?) of the resource
set up stuff. According to the guide, mentors should be able to do this
sort of thing.

I took a look in Whimsy I found that the podling had not been created in
LDAP. As most of our tooling uses LDAP for authentication and
authorization I wonder if that was a factor in blocking you. I clicked
the button and created the podling in LDAP.

I noticed that the bootstrap INFRA ticket (16125) didn't mention LDAP. I
would have expected infra to have created the LDAP entry anyway but
maybe it got overlooked.

> selfserve.apache.org <http://selfserve.apache.org/> makes sense for top-level 
> projects - which, by definition, have at least one officer - but not for 
> podlings. The advice for podlings should be to email general@incubator.a.o 
> <mailto:general@incubator.a.o> for all resources. Their mentors are in most 
> cases as powerless as they are.

I think I have fixed this but even if I haven't, the other two mentors
are PMC chairs so once of them should have been able to take care of it.

>> If you provide a list of what is required - or a pointer to an existing
>> list - I'll put in the requests for you.
> 
> Thanks for the offer to help. But acting as middle-man I’m just slowing 
> things down - so I’m going to ask them to email general@incubator.a.o 
> <mailto:general@incubator.a.o> directly.

I'd ask that you try again to see if the LDAP tweak has fixed this. If
not, and the other mentors aren't around, then emailing general@ seems a
reasonable fallback to me. I'll keep my eyes open for any such emails
and try and process the requests for you if required.

Mark

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

Re: Podling setup

[Mark Thomas]

On 07/03/18 23:24, Julian Hyde wrote:
> I’m a mentor of a new podling, Druid. I would like to help them get set up, 
> e.g. create mailing lists, create git repos. I tried to use 
> https://selfserve.apache.org/  for these, but 
> it only allows officers (i.e. PMC chairs).
> 
> How is this supposed to work? Is the podling supposed to log INFRA tickets 
> for everything? Am I supposed to nag the IPMC chair for everything? Or should 
> I reach out to friends who happen to be PMC chairs?
> 
> The red tape is getting me down.

Having to send one e-mail to ask for help is hardly red-tape.

If you provide a list of what is required - or a pointer to an existing
list - I'll put in the requests for you.

Mark

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

Re: Wiki conflict for March report

[Mark Thomas]

On 07/03/18 01:55, John D. Ament wrote:
> Thanks Mark.  I went through the changes from when the conflict was
> introduced to now, I don't see anything missing.  I also privately pinged
> the culprit.

Thanks for the double check.

Mark


> 
> On Tue, Mar 6, 2018 at 7:34 PM Mark Thomas <ma...@apache.org> wrote:
> 
>> All,
>>
>> I have just spent rather longer than I would have liked cleaning up a
>> conflicted edit in this month's report.
>>
>> I have two requests.
>>
>> 1. If you have submitted your report, please check I didn't accidentally
>> remove content. I tried hard not to but the report was a mess and
>> something might have slipped through the net.
>>
>> 2. If you are editing the report please, please, please take care not to
>> create edit conflicts and if you do manage to create please clean up
>> your own mess rather than leaving it for others to do it for you.
>>
>> Mark
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
> 


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

Wiki conflict for March report

[Mark Thomas]

All,

I have just spent rather longer than I would have liked cleaning up a
conflicted edit in this month's report.

I have two requests.

1. If you have submitted your report, please check I didn't accidentally
remove content. I tried hard not to but the report was a mess and
something might have slipped through the net.

2. If you are editing the report please, please, please take care not to
create edit conflicts and if you do manage to create please clean up
your own mess rather than leaving it for others to do it for you.

Mark

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

Write access to incubator wiki

[Mark Thomas]

Hi,

Please grant 'markt' write access to the incubator wiki.

Thanks,

Mark

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

Re: Thoughts on Trademarks / Existing Domains on Podling Proposals / Reports

[Mark Thomas]

On 12/02/18 23:24, Dave Fisher wrote:
> Hi -
> 
> I think that the Incubator should adjust the proposal process when a project 
> comes in that has registered trademarks.
> 
> There are a few impacts to consider some of which may need to be private.
> 
> (1) PODLINGNAMESEARCH may not be needed.

Maybe. I'm not so sure. The view of the ASF as to what is an acceptable
name in terms of potential conflicts with other products may be
different to the entity that registered the mark. For example:

- the registering entity may have considered a narrower geographic area
  whereas the ASF tends to look globally;

- there may have been a conflict that was acceptable to the registering
  entity that would not be acceptable to the ASF.

I think we probably need to keep this.

> (2) The IPMC and trademarks@ should want to understand what will need to be 
> transferred and what the timing of the transfer(s) will be - either during 
> onboarding or at graduation. We should be clear about what happens to the 
> trademark if Incubation fails either with or without a release.

As far as I am aware the standard process is to transfer them prior to
graduation and that this is a required step before graduation. There is
normally a clause in the transfer agreement to the effect that if
graduation fails, the transfer doesn't happen.

> (3) Existing domains are also something that should be on a proposal along 
> with if these need to be continued or should be redirected. We need to be 
> clear about what happens to domains if incubation fails.

My expectation is that these would be treated the same way as
trademarks. Generally, we would redirect but of there are a lot of them
we might opt to let some lapse.

> (4) I think these items would add some additional sections to the podling 
> report.

Do you mean adding a brand section?

What about an additional section on the proposal template? Or would it
make more sense under 'Source and Intellectual Property Submission
Plan'? Maybe call out in the template that this is the place to list
trademarks, domains, etc.

Mark

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

Re: [VOTE] Accept Dubbo into the Apache Incubator

[Mark Thomas]

On 09/02/18 02:09, Huxing Zhang wrote:
> Hi All,
> 
> After some discussion on the Dubbo proposal, I'd like to start a
> vote on accepting Dubbo into the Apache Incubator.
> 
> https://lists.apache.org/thread.html/1e4a74cc5af9cd0e298dc6085d5be57da8dfd02fef1ebd33829a6084@%3Cgeneral.incubator.apache.org%3E
> 
> The ASF voting rules are described:
> 
> https://www.apache.org/foundation/voting.html
> 
> A vote for accepting a new Apache Incubator podling is a majority vote
> for which only Incubator PMC member votes are binding.
> 
> This vote will run for at least 72 hours. Please VOTE as follows
> [ ] +1 Accept Dubbo into the Apache Incubator
> [ ] +0 Abstain.
> [ ] -1 Do not accept Dubbo into the Apache Incubator because ...

+1

Mark

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

Re: New name for our incubator project

[Mark Thomas]

On 07/02/18 14:37, Joo Yeon Kim wrote:
> Hello.
> 
> We have been recently accepted as an incubator project:
> https://wiki.apache.org/incubator/CoralProposal
> 
> However, the name "Coral" has been flagged by another project,
> and we are in the process of choosing another name.
> 
> We have a few candidates and we would like to ask for some advice on
> trademarks, whether it is okay to use any of the candidates listed below:
> 1. Parrot
> 2. Hazel
> 3. Nemo
> 4. Bolt
> 
> Thank you in advance!

The process is a little more involved than that. Please see
https://incubator.apache.org/guides/names.html for details.

How far you want to go researching each option before selecting a
preference is up to you. I'd suggest doing at least some basic checks to
rule out any obvious non-unique names, select a preference and then
follow the Podling Name Search process for that name.

Kind regards,

Mark

> 
> Best regards,
> Joo Yeon Kim


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

Re: [PROPOSAL] Dubbo - proposal for Apache Incubation

[Mark Thomas]

On 03/02/18 11:44, Huxing Zhang wrote:
> Dear Apache Incubator Community,
> 
> Please accept the following proposal for presentation and discussion:
> https://wiki.apache.org/incubator/DubboProposal
> 
> Dubbo is a high-performance, lightweight, Java based RPC framework.
> Dubbo offers three key features, which includes interface based remote
> call, fault tolerance & load balancing, and automatic service
> registration & discovery.
> 
> Any feedback from the incubator community is much appreciated.

Looks good to me.

The only comment I have at this point is "Is the community sure it wants
a separate users list?". Separating users and developers can make sense
for large, well established projects. For newer projects, it can make it
harder to build the community.

I don't have a strong view on this. I will note it is trivial to create
an additional list at a later point if one is needed.

Mark

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

Re: [VOTE] Retire iota

[Mark Thomas]

On 04/02/18 22:44, Justin Mclean wrote:
> Hi,
> 
> This is a call to vote for the retirement of the Iota podling.
> 
> The podling has discussed retirement [1], has not made a single release and 
> there's been little activity on it’s mailing list [2] and repos [3] in recent 
> time.
> 
> [ ] +1 to retire
> [ ] +/- 0 to retire
> [ ] -1 don't retire because...

+1 (binding)

Mark

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

Re: question about including website source in release

[Mark Thomas]

On 18/01/18 20:43, Matthew Hayes wrote:
> Hi,
> 
> Sorry if this is already answered somewhere but I couldn't find the
> information.  The source code that generates the Apache DataFu website
> content [1] is currently included in the source code release.  However the
> source code for the website is independent from the source code and build
> files that produce the project artifacts (i.e. JAR files).  If the website
> source was removed from the release it would have no impact on building
> these artifacts.  Should Apache DataFu continue to bundle the website
> source in this way or remove it from the release?  What is standard
> practice for other projects?

Standard practice would be not to include it.

Mark

> 
> Thanks,
> Matt
> 
> 1. http://datafu.incubator.apache.org/
> 


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

Re: Leave me alone

[Mark Thomas]

FYI: I have unsubscribed this user using my infra karma.

Mark

On 30/08/17 03:11, $recordS9090 wrote:
> 
> 
> kacie karo
> 
> -
> 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: ASF hosted binaries collecting user data without an explicit opt-in

[Mark Thomas]

On 07/06/17 17:53, Roman Shaposhnik wrote:
> On Wed, Jun 7, 2017 at 8:32 AM, Sean Busbey  wrote:
>> On 2017-06-06 11:59 (-0500), Roman Shaposhnik  wrote:
>>> On Mon, Jun 5, 2017 at 8:25 PM, John D. Ament  wrote:
 While these are all great discussion points, I don't believe they're
 relevant to incubator only and probably should have remained on the
 legal-discuss list.  Ignite graduated ~2 years ago.  The incubator probably
 doesn't have an opinion about this, but it's good to know that the policy
 may change (and I do personally have an opinion on said types of software).
>>>
>>> The reason I'm bringing it on the IPMC mailing list has nothing to do
>>> with how long
>>> ago Ignite graduated and everything to do with the following two points:
>>>1. It can be very useful to the future podlings
>>>2. I honestly don't know any other forum where I can meaningfully
>>> discuss changes to release policy
>>>
>>> I'll take advice on #2, of course.
>>
>>
>> Who owns release policy? I presume it's VP Legal, which would suggest 
>> legal-discuss.
> 
> I would really be surprised if VP Legal actually *owned* it. This
> feels someplace between
> INFRA, ComDev and Legal, but it still doesn't answer the question
> who's a single throat
> to choke.

Consider yourself surprised then. V.P. Legal owns the release policy.

Mark

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

Re: Images in source code.

[Mark Thomas]

On 02/06/2017 22:20, James Bognar wrote:
> Thanks!
> 
> I haven't found a metadata editor that works yet, so I'll just add a
> LICENSE.txt file to the directory.  Hopefully that's enough.

That is more than is necessary. It might even cause confusion at some
point in the future. I would recommend against doing that. The concern
is that folks have a tendency to attempt to reverse engineer ASF policy
from what they see other projects do which leads them to assume all
sorts of things are required when they are not. That in turn can consume
effort that could have been better spent on other things.

Any file in the project's source tree is ALv2 licensed unless explicitly
called out otherwise in the LICENSE file at the root of the source tree.

Where we can add a header to a file we do, but if we can't (easily),
then we don't and that is fine.

Mark


> 
> On Fri, Jun 2, 2017 at 4:48 PM, Josh Elser  wrote:
> 
>> On 6/2/17 1:15 PM, James Bognar wrote:
>>
>>> I just added several png files to the source tree of our podling.  I
>>> created them myself.  Are there any best-practices on how to mark these as
>>> Apache licensed?
>>>
>>>
>> I'm not sure of a good way to track this. I'm not sure if png supports
>> arbitrary metadata which could be edited. Some ways I've seen used
>> elsewhere to try to better propagate license/ownership:
>>
>> * Comments on the issue-tracker issue that introduced them citing
>> origin/source (typically for images that are copied, not created)
>> * Entry in LICENSE/NOTICE (shouldn't be done unnecessarily, of course)
>> * A README in the same directory with relevant info
>>
>> If the images are of the podling's creation, I wouldn't be particularly
>> worried. The copyright notice on your source-release and LICENSE are
>> sufficient to inform downstream consumers.
>>
>> Probably not the answer you're looking for, but hope it helps :)
>>
>> - Josh
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
> 
> 


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

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

[Mark Thomas]

On 04/11/2016 13:36, Anthony Baker wrote:
> Thanks, updated with notes on RE50.

Excellent. Tx.

Mark

> 
> Anthony
> 
>> On Nov 4, 2016, at 1:43 AM, Mark Thomas <ma...@apache.org> wrote:
>>
>> On 03/11/2016 19:47, Roman Shaposhnik wrote:
>>
>>> Maturity assessment:
>>> https://cwiki.apache.org/confluence/display/GEODE/Geode+Podling+Maturity+Assessment
>>
>> I'd like to see this updated to use the latest version of the maturity
>> model.
>>
>> Mark
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
> 
> 
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
> 


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

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

[Mark Thomas]

On 03/11/2016 19:47, Roman Shaposhnik wrote:

> Maturity assessment:
>  
> https://cwiki.apache.org/confluence/display/GEODE/Geode+Podling+Maturity+Assessment

I'd like to see this updated to use the latest version of the maturity
model.

Mark


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

Re: [Proposal] Move Wiki Access Requests somewhere

[Mark Thomas]

On 05/10/2016 17:23, Stian Soiland-Reyes wrote:
> I think it's important that non-Apache folks have an easy way to edit
> their proposal as there will typically be changes suggested after they
> post it here; having the proposal editing "Apache only" would not be
> too good for newcomers although the champion would always be able to
> do it.
> 
> But +1 for a move to Confluence which has its own registration system.

That won't help. Individual users still need to be granted edit privs.
If we grant edit to any registered user, the wiki gets spammed massively.

Mark


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

Re: Ease of release process and exit criteria

[Mark Thomas]

On 20/08/2016 20:59, Mark Thomas wrote:
> 3. Identify somewhere to put all the good suggestions for, and links to
>examples of, smooth release processes and then pull all the links
>and suggestions from this thread to that place. I have a vague
>recollection of seeing such a thing previously. I'll need to do some
>digging to see it I can find it. Any hints?

I've added some content to:
http://incubator.staging.apache.org/guides/releasemanagement.html#best-practices-git-maven
http://incubator.staging.apache.org/guides/releasemanagement.html#best-practice-reproducability

Feel free to edit / enhance as necessary.

Mark


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

Re: Ease of release process and exit criteria

[Mark Thomas]

On 20/08/2016 20:59, Mark Thomas wrote:
> All,
> 
> It seems there is general consensus that this is a good idea. I'm
> therefore going to do the following.
> 
> 1. Draft some text to add to
>http://incubator.apache.org/guides/graduation.html#releases
>and bring that back to this list for discussion

The text I propose adding to the end of the first sentence in "Creating
an Apache Release" section is:

It is also important for a project to document how to create a release.
It should be possible for someone new to the project to work from the
documentation to independently create a release. (Note: Creating a
release is usually more complex than simply being able to build from
source.)

Thoughts?

Mark

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

Re: ASF Android release policy

[Mark Thomas]

On 13/09/2016 13:38, Jochen Wiedmann wrote:
> On Tue, Sep 13, 2016 at 11:30 AM, Mark Thomas <ma...@apache.org> wrote:
> 
>> Finally, Infra does also provide access to a code signing service you
>> can use to sign you apps if that is useful. Probably only if you want to
>> distribute apps outside of Google play.
> 
> More infos on that, please.

https://blogs.apache.org/infra/entry/code_signing_service_now_available

Mark


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

Re: ASF Android release policy

[Mark Thomas]

On 13/09/2016 09:49, Ian Dunlop wrote:
> Hello,
> 
> In the Taverna Incubator project we have been developing an Android mobile
> app which is almost ready for a first release. Are there any ASF procedures
> and policies for doing an Android release? Can an ASF based Android app be
> released into the Google play store (or others)?

The usual release policy applies. Making a convenience binary available
in an App store is not dissimilar to making JAR files available via
Maven Central.

The ASF has already set up the appropriate accounts to do this for the
Apple app store. A quick look around Google's site suggests a similar
process will be required.

The best way forward would be to create an Infra ticket to:
- create an ASF account with Google (managed by infra)
- add named release managers to that account so they can release apps
  on behalf of the PMC

ASF Legal will need to review the Ts associated with the account. I'd
expect infra to ask for review as required.

One immediate question is do we want this as an ASF wide account or per
PMC? At $25 per account, one per PMC isn't outrageous but my own infra
experience says that it would be better to start with a single ASF
account managed by infra. We can always create additional PMC acocunts
later if necessary.

Finally, Infra does also provide access to a code signing service you
can use to sign you apps if that is useful. Probably only if you want to
distribute apps outside of Google play.

Mark


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

Re: [discuss] Move podling rosters to LDAP

[Mark Thomas]

On 02/09/2016 17:41, Sam Ruby wrote:
> To prepare, we will need to decide who gets to modify these lists, and
> who gets notified.  I propose that members of podlings be able to modify
> the list, and the private list associated with that podling be notified
> on changes.  Alternate choices would include mentors for the podling, or
> the IPMC.  Given that notification facilitates oversight, I encourage
> this to be pushed down to the podling, but will go with whatever the
> consensus turns out to be.

(from the peanut gallery)

+1 to pushing it down to the podling. If I am reading this proposal
correctly, the worst they can do is grant an ASF committer write access
to their svn area.

> Longer term this change would lay the groundwork for more fine-grained
> access control whereever it may be desired: not just for svn, but also
> for web pages, git, and any other location that can be configured to use
> LDAP to obtain ACL information.

The key being "where it may be desired".

I'd prefer to see us moving towards coarser technical access control and
using social controls for the fine-grained aspects across the ASF.

Mark

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

Re: Ease of release process and exit criteria

[Mark Thomas]

All,

It seems there is general consensus that this is a good idea. I'm
therefore going to do the following.

1. Draft some text to add to
   http://incubator.apache.org/guides/graduation.html#releases
   and bring that back to this list for discussion

2. Start a thread on dev@community about adding an item to the project
   maturity model.

3. Identify somewhere to put all the good suggestions for, and links to
   examples of, smooth release processes and then pull all the links
   and suggestions from this thread to that place. I have a vague
   recollection of seeing such a thing previously. I'll need to do some
   digging to see it I can find it. Any hints?

Mark


On 19/08/2016 21:41, Dave Fisher wrote:
> I know of a podling like that where the release manager gave me push back 
> until I told him I could not vote +1 without build instructions I could at 
> least follow on my own local.
> 
> That was some years ago. The podling graduated. The instructions were not 
> updated. The RM left. Now there is a bind.
> 
> A requirement is a good idea, but it is no guarantee that the instructions 
> remain up to date.
> 
> Suggestions:
> 
> Is this info for the maturity model?
> Should there be special and higher standards to make binary releases 
> "official"?
> 
> Regards,
> Dave
> 
> Sent from my iPhone
> 
>> On Aug 19, 2016, at 8:41 AM, Dennis E. Hamilton <dennis.hamil...@acm.org> 
>> wrote:
>>
>> +1 to this, including the posts from Mark and Bertrand.
>>
>> I know of a project where this would have made a serious difference for 
>> graduation and subsequent sustainability.
>>
>> - Dennis
>>
>>> -Original Message-
>>> From: Shane Curcuru [mailto:a...@shanecurcuru.org]
>>> Sent: Friday, August 19, 2016 07:08
>>> To: general@incubator.apache.org
>>> Subject: Re: Ease of release process and exit criteria
>>>
>>> Bertrand Delacretaz wrote on 8/19/16 5:57 AM:
>>>> Hi Mark,
>>>>
>>>> On Fri, Aug 19, 2016 at 11:23 AM, Mark Thomas <ma...@apache.org>
>>> wrote:
>>>>> ...I'm thinking of a graduation criteria long the lines of:
>>>>> "Is the release process clearly documented to the point that someone
>>> new
>>>>> to the project could produce a release build?"...
>>>
>>> +1, this is a critical point to include.  We continue to see projects
>>> struggling with releases when early volunteers leave and no-one else
>>> really understands releases.
>>>
>>> ...snip...
>>>> How about also adding an RE50 item to
>>>> https://community.apache.org/apache-way/apache-project-maturity-
>>> model.html
>>>> about a repeatable release process? That's a discussion for
>>>> community.a.o but what's your opinion?
>>>
>>> +1, this is both important to include philosophically as well as
>>> practically.  I.e. it's an important reminder that project technical
>>> procedures need to be understandable by the *whole* community, not just
>>> the first few developers who created the project.
>>>
>>> - Shane
>>>
>>> -
>>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
>>
>> -
>> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
>> For additional commands, e-mail: general-h...@incubator.apache.org
>>
> 
> 
> -
> 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

Ease of release process and exit criteria

[Mark Thomas]

Hi,

I've noticed a pattern in some the board reports of PMCs who are
beginning to experience difficulties. In a notable number of cases a
significant part of the problem is difficulty in producing a release.
The sorts of phrases I am seeing are along the lines of releases "are
too difficult", "take too much effort" or "the person that used to do
the releases is no longer active". I've seen this in projects of all
sizes and maturity levels.

I've also experienced this in projects I have been involved in.
Fortunately, in those cases the community was able to figure out the
release process, simplify/automate it and document it, reducing the
future risk to the project.

To put some specifics on this to give an idea of what I am talking
about. The documented Windows build process for Tomcat Native is this:

http://tomcat.apache.org/native-doc/#Building/Windows

which is fine if you want to test a patch or build it form source to use
locally but is insufficient to produce a release. What the community
then produced is this:

https://cwiki.apache.org/confluence/display/TOMCAT/Building+the+Tomcat+Native+Connector+binaries+for+Windows


This got me wondering. Is protecting projects from this sort of future
problem something that could / should be addressed during incubation?
I'm thinking of a graduation criteria long the lines of:
"Is the release process clearly documented to the point that someone new
to the project could produce a release build?"

If there is general consensus on this, I'm happy to draft something to
add to http://incubator.apache.org/guides/graduation.html#releases

Thoughts?

Mark

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

Re: Code signing and WOT for releases

[Mark Thomas]

On 26/07/2016 08:19, Thorsten Schöning wrote:
> Hi all,
> 
> the docs about release management for incubating projects make clear
> that the release needs to be signed[1] and in the end associated with
> the project AND the WOT of Apache in general[2].
> 
> Is there some way to check what the owner of a PGP key for former
> releases has done to get his association to the WOT, if any? I would
> like to understand the needed process better and e.g. found the
> following:
> 
> http://pgp.surfnet.nl:11371/pks/lookup?op=vindex=on=0x2E114322
> 
> Are all those people/keys on this list someone who signed the key I
> searched for and provided association with the WOT this way?

Yes.

> Are the mentioned possibilities in [2] the only way to get such an
> association to the WOT? I usually don't visit conferences or
> keysigning parties or such.

It depends on what the signer is prepared to accept as proof of
identity. In most cases, a face to face meeting is required.

> Am I correct that releases can't be published without such an
> association to the WOT at all and BEFOREHAND?

No.

The release manager's key MUST be added to the project's KEY file
*before* signing the release.

The release manager MUST upload their key to a public key server (e.g.
pgp.mit.edu) *before* signing the release

Releases MUST be signed.

The release manager SHOULD add their key to their profile on id.apache.org

The release manager SHOULD add their key to the ASF WoT at the earliest
opportunity. If you don't visit conferences then one option is to use
[3] to find a nearby committer who might be able to sign your key.

HTH,

Mark


> Else one could sign and
> publish a release and loose the key afterwards or else and the release
> would be left without the needed association.
> 
> Thanks!
> 
> [1]: http://incubator.apache.org/guides/releasemanagement.html#signing
> [2]: http://www.apache.org/dev/openpgp.html#apache-wot-link

[3] http://community.zones.apache.org/map.html


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

Re: [VOTE] Accept

[Mark Thomas]

On 13/06/2016 21:22, james pruett wrote:
> please remove me from this list.

Done.

Given this was your second unsubscribe request for an ASF list today, I
checked all our lists for your address and our records show that this
address is not subscribed to any other ASF lists.

Kind regards,

Mark



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

Re: Fwd: [jira] [Created] (HAWQ-694) 1844-313-4857 Quickbooks payroll support usa/canada

[Mark Thomas]

On 21/04/2016 21:40, Gregory Chase wrote:
> Seems we have a JIRA user who's spamming Apache HAWQ? Is this a compromised
> account, or someone who has access that shouldn't?

It is a public Jira instance on which anyone can create an account.
Sometimes spam happens. It is the cost of an open development process.

The infra team is already on the case to clean up the spam and is
looking into what further filtering can be applied to reduce future
instances.

Mark



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

Re: Non-voted Release Candidate binary downloadable from project homepage possible?

[Mark Thomas]

On 30/12/2015 14:55, Daniel Dekany wrote:
> Hello,
> 
> We at project FreeMarker intend to issue a Release Candidate under
> https://dist.apache.org/repos/dist/dev/incubator/. Note that it's just
> "dev", not "release". There will be both source and binary RC release
> artifacts. As I understand, this so far doesn't require any voting, as
> it will be the subject of the later voting (on dev@freemaker first).
> 
> The binary artifact will be linked on the top of the FreeMarker
> homepage for testing for one month. At least this is how it was done
> prior ASF. An RC like that used to have around a 50-100 downloads
> during the RC period (plus the Maven staging repo downloads), so
> hopefully it's not a technical issue that it's a download directly
> from "repos".
> 
> Is this procedure OK in ASF? I mean, we *kind of* publish something
> that wasn't voted on, at least not on incubator general.

No.

RC's should not be visible to ordinary users. It is OK to link to them
from the developer pages (the ones that point to source repos, explain
who to provide patches etc,) but not from anywhere that is not developer
focussed.

Similarly, you can announce them on developer mailing lists but not user
mailing lists.

Mark


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

Re: Possible process improvement?

[Mark Thomas]

On 14/10/2015 21:07, Dave Birdsall wrote:



> Now, the iCLA form itself asks for the preferred apache ID. But that form
> does not ask about forwarding e-mail ID. Too, the receipt of the iCLA is
> forwarded to the podling’s private list, but not the iCLA itself.

The CLA form [1] includes e-mail address and it is not marked as
optional. What am I missing?

> Also, the committer accept template makes no mention of providing a
> forwarding e-mail address.

It should be easy to change that to make it clear that any field not
marked as optional is mandatory.

> So, the mentor has to ask. And the mentor often doesn’t have an e-mail
> address for the new person. So that request has to be relayed through the
> podling PMC private list, and someone there who knows the individual can
> ask.

Mentor's should have access to the part of svn where the CLAs are filed
so they should be able to get the e-mail address from the CLA.

Also, the invited committer will have replied to the private list from a
valid e-mail address and the mentors will be subscribed to the private
list. So they already know the e-mail address for the new committer.
Again, I feel I am missing something. I don't see where / how the
disconnect you describe is happening.

Mark

[1] http://www.apache.org/licenses/icla.pdf


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

Re: Require projects to have solid API docs

[Mark Thomas]

On 11/10/2015 16:59, Andrew Pennebaker wrote:
> In the future, could Apache Incubator require projects to maintain better
> API documentation before graduation? In particular, Kafka has rather sparse
> documentation in v0.8. The Javadocs appear to be randomly hosted on this or
> that professor webpage, and no Kafka javadoc has documentation for
> *both* Consumers
> and Producers.

No.

It is not the role of the incubator to assess the *quality* of the code
or any other release artefact.

Graduation from the incubator is based on the quality of the community.
This is because a good community can always (and usually does) turn
around bad code. Good code will never save a poor community.

If you have an issue with a project's release artefacts, open a bug
report. Better still, open a bug report and provide a patch/pull request
with a fix.

Mark

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

Re: Advice on LICENSE/NOTICE for Shaded Dependencies

[Mark Thomas]

On 09/10/2015 19:12, Stephen Mallette wrote:
> Hello all,
> 
> I feel like I'm on the verge of getting LICENSE/NOTICE right in all
> respects in The TinkerPop.  . Seems like there's one piece that's out of
> place and could use some advice as I wasn't able to map anything I'd read
> in the Apache docs on this topic to my issue.  We currently shade several
> libraries: Kryo, minlog, objenesis, and jackson, essentially re-packaging
> those binary dependencies in a jar called gremlin-shaded.jar. The
> gremlin-shaded.jar is then made part of our zip distributions.
> 
> As we didn't re-package the source code of these libs, I figured that the
> source LICENSE/NOTICE didn't need to change and that it was just the binary
> LICENSE/NOTICE that needed to change.  I assume this situation is somewhat
> similar to a project that builds an uber jar for distribution.
> 
> So that's where i'm about stuck. I took a wild stab at it and did this:
> 
> https://github.com/apache/incubator-tinkerpop/blob/5a8b61c09868e22a415c0469a2737d68acce9a4e/gremlin-console/src/main/LICENSE#L226-L228
> 
> but I have no idea if that is sufficient (or just plain wrong).  If anyone
> could offer some pointers on what needs to happen here to our binary
> LICENSE/NOTICE, that would be nice.  I'd really like to see us get a clean
> bill of health on the next LICENSE/NOTICE that goes through a release vote.

Looks good to me. The only thing I'd consider adding is what package
they were renamed to.

Mark


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

Re: apache binary distributions

[Mark Thomas]

On 22/08/2015 04:37, Niclas Hedhman wrote:
 Cool.
 I can't find info on how much it costs ASF, any pointers before embarking
 on 100+ artifact signing spree... ;-)

With my infra hat on...

The short answer is 'Don't worry about it and get signing.'

The longer answer is that if a project wants to use the signing service
then providing and paying for that service is infra's problem. As it
happens, the solution we have is such that we are confident we can
afford to sign every release of every project if necessary.

The cost to the ASF is not per artefact but per 'signing event'. A
signing event can consist of any number of artefacts.

Note that it is a signing event that gets a unique certificate and a
signing event is the smallest thing we can revoke.

Typically, it is one signing event per release but there cases where a
release needs 2 or 3 signing events. For example, Tomcat signs its
Windows installer and uninstaller. Th uninstaller is packaged in the
installer so we need one event to sign the uninstaller and then a second
to sign the installer package that contains the (now signed)
uninstaller. If Tomcat wanted to sign all the JARs we could sign them at
the same time we sign the uninstaller (with a little jigging about of
the build script) at no extra cost.

If a project thought it needed 10s of signing events per release then I
suspect there would need to be a conversation to see if that was really
the case or if the number could be reduced.

For more details see this:
http://people.apache.org/~markt/presentations/2015-04-15-Code%20Signing%20at%20the%20ASF.pdf

The exact costs are confidential but any ASF Member can look at the
quotes (we accepted the second one dated 19-08-2014) in the private
foundation repo (look under correspondence then Symantec).

I'll be at ApacheCon Core in Budapest if anyone wants to talk face to
face about this.

Mark


 
 On Fri, Aug 21, 2015 at 12:35 AM, William A Rowe Jr wr...@rowe-clan.net
 wrote:
 
 On Thu, Aug 20, 2015 at 8:09 AM, Niclas Hedhman nic...@hedhman.org
 wrote:

 On Thu, Aug 20, 2015 at 1:06 AM, William A Rowe Jr wr...@rowe-clan.net
 wrote:

 There are some special things here we do have absolute control over.
 If a
 project wants to provide the 'official' build, why not start signing
 the .jar?

 Good idea, but to be practical to users, the certificate for the signing
 needs to be part of the certificate chain of the JVM (otherwise those
 would
 be needed to be installed on every host). I don't know how willing infra
 would be to support PKI at ASF for this, otherwise many projects will be
 limited due to cost (I could be wrong by now and that there are totally
 free CAs)


 That infrastructure now exists through code signing service by Symantec.
 One PMC member (or more) gets their own unique log in, pushes the artifact
 (.jar, in this example) to the service and is returned a signed artifact
 reflecting the ASF providence.

 The interesting thing is the actual cert is unique to the object, so if it
 is discovered that it was compromised, the signature can be revoked (good
 luck having sig revocations active at boot time, but otherwise this is
 quite useful.) And because there is a history, we know who precisely
 requested each object signing.

 
 
 


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

Re: [DISCUSS] Groovy Incubation proposal

[Mark Thomas]

On 16/03/2015 09:53, Stephen Connolly wrote:
 Arg! hit send too soon.
 
 You should really check in with Hervé to confirm that Groovy was in the
 export. I am 99% confident that your issues and comments are in the XML
 dump, but you really should check with Hervé to be certain.
 
 Also you may want to ask Mark Thomas what exactly is involved in
 preparing and doing such an import. Our own timelines for Maven's switch
 may not align with the Groovy incubation timelines... (mind you we are
 all at the grace of Ben for getting our timeline for the second export
 he committed to the Maven project)

The latest test export I have does not have any Groovy data in it.

Mark


 
 On 16 March 2015 at 09:49, Stephen Connolly
 stephen.alan.conno...@gmail.com
 mailto:stephen.alan.conno...@gmail.com wrote:
 
 
 
 On 16 March 2015 at 09:19, Cédric Champeau
 cedric.champ...@gmail.com mailto:cedric.champ...@gmail.com wrote:
 
 Thanks Stephen, sounds like a good news. For us the attachments
 do not
 matter much, there are not so many. However, keeping track of
 comments is
 very important, because some issues have a lot of discussions.
 
 2015-03-16 10:08 GMT+01:00 Stephen Connolly
 stephen.alan.conno...@gmail.com
 mailto:stephen.alan.conno...@gmail.com
 :
 
  On 16 March 2015 at 08:55, Jochen Theodorou blackd...@gmx.org
 mailto:blackd...@gmx.org wrote:
 
   Am 16.03.2015 09:25, schrieb Upayavira:
  
   When Stephen Connolly says ”We @ Maven will have a full
 dump of the
   Codehaus JIRA and we have a VM set
   up to test migration…” isn’t he implying that the Groovy
 issues are
   *included* in that? I.e. there’s not so much for you to
 worry about
   here?
  
  
   Even if Stephen gets a full dump, this does not mean we will
 get the
   Groovy part out of it. Ben was so far telling us he cannot
 give it out
  like
   that, because of private and internal data in there. Instead he
  suggested a
   json export (which most likely will not contain everything)
  
 
  Well we are getting the full XML dump because that's all you
 can get via
  the XML dump, but whether we get *all* attachments or only
 those for Maven
  is a different question.
 
 
  
   So unless Stephy has this clear with his employee I stand on
 the part,
   that we don't have that.
 
 
  Clarification: Ben and I are co-workers.
 
 
  
  
   bye Jochen
  
   --
   Jochen blackdrag Theodorou - Groovy Project Tech Lead
   blog: http://blackdragsview.blogspot.com/
   german groovy discussion newsgroup: de.comp.lang.misc
   For Groovy programming sources visit http://groovy-lang.org
  
  
  
 -
   To unsubscribe, e-mail:
 general-unsubscr...@incubator.apache.org
 mailto:general-unsubscr...@incubator.apache.org
   For additional commands, e-mail:
 general-h...@incubator.apache.org
 mailto:general-h...@incubator.apache.org
  
  
 
 
 
 


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

Javadoc published through archive.apache.org

[Mark Thomas]

Incubator community,

While reviewing the ASF's public web sites for Javadoc vulnerable to
CVE-2013-1571 the ASF infrastructre team discovered the following copies
of documentation being published via archive.apache.org:

archive.apache.org/dist/incubator/sanselan/0.97/javadoc
archive.apache.org/dist/incubator/sanselan/javadoc

These have been removed from the archive. The deletions will replicate
to the public archive servers over the next 24 hours or so.

Please ensure that going forward documentation is published via
incubator.a.o and not via archive.a.o or www.a.o/dist

Mark


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

Javadoc published through archive.apache.org

[Mark Thomas]

UIMA community,

While reviewing the ASF's public web sites for Javadoc vulnerable to
CVE-2013-1571 the ASF infrastructre team discovered the following copies
of documentation being published via archive.apache.org:

archive.apache.org/dist/incubator/uima/docs

These have been removed from the archive. The deletions will replicate
to the public archive servers over the next 24 hours or so.

Please ensure that going forward documentation is published via
uima.a.o and not via archive.a.o or www.a.o/dist

Mark


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

Re: Formats of SHA/MD5 checksums

[Mark Thomas]

Roman Shaposhnik r...@apache.org wrote:

+infra

Ping! I would really like this annoyance to be resolved one way or the
other.
Could somebody more experienced with Apache web properties answer
the question?


 Question: how do we go about discouraging it then? Do we need a vote
 to modify the content of:
http://www.apache.org/dev/release-signing#md5

 Or even more basic question -- where's the source for that
 webpage?


No vote is required to change that web page. Those pages are infra owned but 
any member can change them.

Since infra owns the page, it would be polite to suggest the alternative text 
on infrastructure@. Once that is agreed, any member can apply it.

With my infra hat on, I have no objection to standardising on the md5sum format 
for MD5 checksums.

A couple of side issues:
Firstly, you removed far to much context when adding infra to the thread. I had 
to go digging through the archives to figure out what the problem was.

Secondly, votes are not the way to drive change. Discussion is.

The process is not:
- see an issue
- pick a solution
- start a vote for implementing that solution
- drive through the change

but:
- see an issue
- discuss options to fix it
- agree the way forward (consensus)
- make the change

Releases and new committers are pretty much the only time I'd expect to see 
votes in an Apache community.

Mark

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