Re: [VOTE] Graudate Apache Weex (Incubating) as a Top Level Project

[Jan Piotrowski]

> A quick search showed that there is also some branding/trademark issues with 
> these pages:
> [...]

How can third party web sites be a "branding/trademark issue" for an
Apache project?

Am Fr., 25. Okt. 2019 um 19:16 Uhr schrieb Justin Mclean
:
>
> Hi,
>
> >   - There are 11 PPMC members, 8 committers (excluding PPMC members) [2],
> >   and 192 Github contributors [3]
>
> How many PMC members and committer have been added since starting graduation?
>
> Having 200 odd contributors and only 8 committers seems like it could be an 
> issue to me.
>
> Name wise these may be issues:
> https://play.google.com/store/apps/details?id=mx.weex.ss=en_US
> https://apkpure.com/weex-wallet/mx.weex.appwallet
> https://apps.apple.com/us/app/weex/id1036040019
> http://weex.mx
>
> A quick search showed that there is also some branding/trademark issues with 
> these pages:
> https://github.com/weexteam
> https://developer.alibabacloud.com/opensource/project/weex
> https://www.npmjs.com/package/weex-ui
> https://cocoapods.org/pods/WeexSDK
> https://bintray.com/alibabaweex/maven/weex_sdk/view
> https://natjs.com/#/
> https://github.com/natjs/nat
> https://github.com/tralves/weex-todo-list
> http://dotwe.org/
> (and others!)
>
> Until we have seen the actual proposal there may be other issues. For 
> instance we would need to know the makeup of the new PMC.
>
> Thanks,
> Justin
> -
> To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> For additional commands, e-mail: general-h...@incubator.apache.org
>

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

Re: [Vote] Release Apache Weex (Incubating) 0.28.0-RC1

[Jan Piotrowski]

+1 looks good to me

Am Mo., 21. Okt. 2019 um 21:52 Uhr schrieb Dave Fisher :
>
> +1 (binding)
>
> Incubating in name
> Signature and Checksum are correct
> LICENSE is good
> NOTICE is good
> DISCLAIMER is good
> Rat check passes. Consider adding exclusions for the two sets of files that 
> are in the LICENSE file and shown as on-standard in the Rat check output.
>
> Build did fail when it got to Android, but then I did not install an Android 
> environment.
>
> Regards,
> Dave
>
> > On Oct 17, 2019, at 5:46 AM, YorkShen  wrote:
> >
> > Forget to send prvious email from Apache email account, sorry for that. But
> > let‘s continue voting.
> >
> > Best Regards,
> > YorkShen
> >
> > 申远
> >
> >
> > 申远  于2019年10月17日周四 下午8:33写道：
> >
> >> Hi, folks
> >>
> >> The Apache Weex community has voted and approved the proposal to release
> >> Apache Weex (Incubating) version 0.28.0-RC1, we now kindly request the
> >> Incubator PMC members to review and vote on this incubator release.
> >>
> >>   - Vote thread:
> >>   
> >> https://lists.apache.org/thread.html/3b56f8ceb75981487de107c90995de27ebfa9ff9acfb0e16ca07cc55@%3Cdev.weex.apache.org%3E
> >>   - Vote result thread:
> >>   
> >> https://lists.apache.org/thread.html/7df08b9020fc11c0cb01b15faea16207cb791314ef993ab73a9b2721@%3Cdev.weex.apache.org%3
> >>   
> >> 
> >>   - Git tag for this Release:
> >>   https://github.com/apache/incubator-weex/releases/tag/0.28.0-RC1
> >>   - The source tarball could be found at :
> >>   
> >> https://dist.apache.org/repos/dist/dev/incubator/weex/0.28.0/RC1/apache-weex-incubating-0.28.0-RC1-src.tar.gz
> >>   - The signature of the source tarball could be found at :
> >>   
> >> https://dist.apache.org/repos/dist/dev/incubator/weex/0.28.0/RC1/apache-weex-incubating-0.28.0-RC1-src.tar.gz.asc
> >>   - The SHA-512 checksum of the source tarball could be found at :
> >>   
> >> https://dist.apache.org/repos/dist/dev/incubator/weex/0.28.0/RC1/apache-weex-incubating-0.28.0-RC1-src.tar.gz.sha512
> >>   - The source tarball is signed with
> >>   Key:D7E6B58FFA293FB1AC9E7B624FD8BC09C7E9DB81, which could be found in the
> >>   key file:
> >>   https://dist.apache.org/repos/dist/release/incubator/weex/KEYS
> >>   - ChangeLog about this version:
> >>   https://github.com/apache/incubator-weex/blob/release/0.28/CHANGELOG.md
> >>
> >>
> >> One can build the binary from source according to
> >> https://github.com/apache/incubator-weex/blob/release/0.28/HOW-TO-BUILD.md
> >> with build environment installed.
> >>
> >> *FYI: I only test the build scripts on Mac environment, it should also
> >> work in Linux/Unit platform according to my understanding. But you may get
> >> problems if you try to build Weex from source on a windows platform.*
> >>
> >> This vote will remain open for at least 72 hours, until we get enough
> >> votes. Please vote on releasing this RC.
> >>
> >>   -  +1 approve
> >>   -  +0 no opinion
> >>   -  -1 disapprove (and reason why)
> >>
> >>
> >> Best Regards,
> >> YorkShen
> >>
> >> 申远
> >>
>
>
> -
> 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: New disclaimer text

[Jan Piotrowski]

> I think the question to be asked is does that add barries more than having to 
> have 100% compliant releases?

Is this a current requirement that is written down somewhere and
generally practiced?

Am Fr., 12. Juli 2019 um 09:49 Uhr schrieb Justin Mclean
:
>
> Hi,
>
> > Adding an additional disclaimer that we may have known issues adds 
> > additional barriers to adoption and community growth.
>
> I think the question to be asked is does that add barries more than having to 
> have 100% compliant releases? I think the answer may depend on the podling. 
> Have does that work out for 50 odd podlings?
>
> > Here’s one way for the ASF Incubator: Apache’s key marketing point is the 
> > Apache Way. Break down critical processes, determine key performance 
> > indicators against those processes, and centrally track metrics (license 
> > compliance, community participation, release compliance, notice, keys, 
> > whatever, whatever).
>
> I really like the idea, would you be willing to work on it further?
>
> Some things to consider. I don’t know it we have enough volunteer time to 
> implement something along those line or if we could come out with clear 
> metrics to suit all podlings. However in some ways this work has already been 
> done with the maturity model. There are issues this this as well a) not all 
> IPMC members or podlings think it should be used so so it's optional. b) 
> we’ve had podlings fill it in and ask to graduate that were clearly not ready 
> to graduate.
>
> >  The additional disclaimer communicates that Apache has little trust in its 
> > podlings, at large.
>
> About 1 in 5 podling releases put up fro IPMC have serious issues and have 
> previously have attracted -1 votes by IPMC members. If we allow those to be 
> released then I think we need to add something to the the disclaimer, we just 
> need to work out a balance.
>
> > -1. These are connected issues: Mentors are IMPCs "tip of the spear" for 
> > managing compliance risk and for adding value to podlings. I have so much 
> > respect for Justin and other IPMC regulars who tirelessly volunteer and 
> > monitor general@, dig into minor releases to test builds and check 
> > compliance. It’s heroic, but heroes are a sign of struggling operations in 
> > orgs, and heroes burn out.
>
> I’ve yet to see any proposal that deals with the issue of how it would get 
> around that only PMC members votes are binding. I don’t see voting in all 
> PPMC member as PMC member working (we get complaints that he IPMC is already 
> too large) and I don’t think the board would allow a TLP to ignore that 
> particular bylaw. I’m open to suggestions.
>
> > Their valuable time is better spent institutionalizing knowledge and 
> > skills: making mentors' jobs easier with templates, documentations, 
> > infrastructure projects.
>
> We do quite a bit of that as well.
>
> > IMHO: the thing the needs to be discussed in a different thread is how the 
> > Incubator supports and incentivizes engaged mentors. Speaking from 
> > experience: engaged mentors are magical gifts from above. Losing mentors 
> > during critical junctures is terrifying because there is so much to learn 
> > and its hard to find documentation and examples for how to do things right.
>
> If you have engaged mentors then that should be no issue, the last checkbox 
> before graduation is that you don’t need mentors anymore and can wrk out 
> things for yourself that are in line with how other ASF projects operate and 
> the Apache Way. If you feel like that then perhaps your mentors haven’t 
> completed their job.
>
> Thanks for your thoughts,
> 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: New disclaimer text

[Jan Piotrowski]

What is the requirement for this disclaimer text change?
Is this coming from Legal? Or is this Incubator policy?
Has this been decided on already or is this text suggestion to be used
for a decision?

J

Am Mi., 10. Juli 2019 um 15:50 Uhr schrieb Matt Sicker :
>
> Since this is sort of a post-release set of info, I think it’d make sense
> to have either a page specific to each version, or at least a section per
> version all on a single page (similar to a security issues page might be or
> a change log in general).
>
> On Tue, Jul 9, 2019 at 21:24, Justin Mclean 
> wrote:
>
> > Hi,
> >
> > The issue with having a detached disclaimer is that it can change and get
> > out of sync with what was actually in a released version.
> >
> > However one possible compromise would be to list known issues in the
> > disclaimer and list any other issues found by the IPMC in the release
> > announcements and on the release page next to the download links. The
> > DISCLAIMER in version control can also be updated and always reflect the
> > current set of released issues are. What do other people think about this?
> >
> > Thanks,
> > Justin
> > -
> > To unsubscribe, e-mail: general-unsubscr...@incubator.apache.org
> > For additional commands, e-mail: general-h...@incubator.apache.org
> >
> > --
> Matt Sicker 

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

Re: FOSSA.com: a new service to monitor licenses on Github repos

[Jan Piotrowski]

> See it in action here:
> https://app.fossa.com/projects/git%2Bgithub.com%2Fmistercrunch%2Fsuperset/refs/branch/master/396a655de13ced6e25f4e793b0eb281bf4f4cd79/issues/licensing?status=resolved

Endless loading spinners for me unfortunately.

J

Am Di., 9. Juli 2019 um 08:30 Uhr schrieb Maxime Beauchemin
:
>
> Hi all,
>
> [this is not a promotional email in any way, I'm not affiliated with the
> service/company discussed here]
>
> I just discovered fossa.com, self described as "Realtime license and
> vulnerability management
> for open source dependencies".
>
> For context, Apache Superset has a dependency tree rich of 700+ deps (crazy
> right?), at that scale license management is huge burden at best, or worse:
> a legal risk for the ASF.
>
> Oh btw I tried searching the ASF mailing lists for existing threads on this
> topic but failed miserably, apologies if this has been discussed already.
>
> I couldn't set up the FOSSA service on the projects repo I'm PMC on as I
> don't have the required Github rights, but I set it up against my fork and
> it's all you could ever hope for in terms of license-related automation.
> See it in action here:
> https://app.fossa.com/projects/git%2Bgithub.com%2Fmistercrunch%2Fsuperset/refs/branch/master/396a655de13ced6e25f4e793b0eb281bf4f4cd79/issues/licensing?status=resolved
>
> It seems like we may want to set this up against most if not all ASF
> projects. As the ASF is in the line of fire for legal troubles around
> licensing, it seems like automation/prevention would be strategic,
> especially in a world where micro packages and frequent releases are
> trending. Without using a service like this one, bumping a release, or even
> just allowing an open version range can result in integrating
> non-permissive licenses in a bundle, in ways that could take months to
> catch, if ever.
>
> For the record I opened a ticket with ASF infra to set it up on
> `apache/incubator-superset`:
> https://issues.apache.org/jira/browse/INFRA-18719 I'm hoping this goes
> smoothly, and that Apache Infra is ok granting the required perms to FOSSA.
>
> I wanted to bring the attention to this as this seems like something very
> useful for most projects.
>
> Thoughts?
>
> Max

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

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

[Jan Piotrowski]

+1

I trust Justin's judgement here, and I'm sure you'll work out any
issues with further releases.

-J

Am Do., 27. Juni 2019 um 06:14 Uhr schrieb Joshua Poore
:
>
> Hi Folks,
>
> Another friendly reminder: please VOTE on the ReRelease of Apache Flagon 
> UserAle.js (Incubating) 1.0.0.
>
> Our ReRelease was mandated by IPMC due to build artifacts that lacked 
> “incubating” markings.
>
> At this point we have +6 votes from our community and +2 Binding. We need one 
> more VOTE from general@ to release and 2 of our mentors are AWOL. We’re 
> entering the 10th consecutive day of this VOTE on general@ and that’s a very, 
> very long time to wait on a ReRelease.
>
> Thanks to Justin for voting.
>
> Tomorrow, we’ll be pushing v2.0.0 for a VOTE on general, as its wrapping up a 
> VOTE in community. Again we’re down two mentors. Am hoping that we’re able to 
> get feedback from IPMC a little more quickly. We have users waiting on an NPM 
> packaged version of this release.
>
> Thanks,
>
> Joshua Poore
>
>
> > On Jun 25, 2019, at 11:49 PM, Joshua Poore  wrote:
> >
> > Ah, I understand. Copyright attribution is misplaced in License file 
> > altogether—appendix gives instruction for how to add a copyright to 
> > derivative works. *palm-to-face*. Thanks and sorry for being thick!
> >
> > Josh
> >
> >> On Jun 25, 2019, at 9:10 PM, Joshua Poore  wrote:
> >>
> >> Hi Justin,
> >>
> >> Dave Meikle and I worked to make the copyrights correct prior to this 
> >> ReRelease.
> >>
> >> Our License File reads:
> >>
> >>  © Copyright 2018 The Apache Software Foundation.
> >>
> >> Our Notice Fille reads:
> >>
> >> Copyright 2019 The Apache Software Foundation
> >>
> >> We thought that was consistent with 
> >> https://www.apache.org/legal/src-headers.html 
> >> , however, both should be 
> >> dated ‘2019’ (oversight).
> >>
> >> If not, or you see something I missed, please don’t hesitate to point it 
> >> out and I’ll make sure we get it right.
> >>
> >> Thanks!
> >>
>  From: Justin Mclean   >
>  Date: June 25, 2019 at 8:11:25 PM EDT
>  To: general@incubator.apache.org 
>  Subject: Re: [VOTE] (Re)Release Apache Flagon UserALE.js (Incubating) 
>  1.0.0
>  Reply-To: general@incubator.apache.org 
>  
> 
>  HI,
> 
> > Copyrights are 2019 in V2.0.0 under vote now in dev@. Moving forward, 
> > we’ll be more careful.
> 
>  Which would still be incorrect that line should say:
>  Copyright [] [name of copyright owner]
> 
>  As it where a 3rd party put their copyright notice in their file headers.
> 
>  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
>

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

Re: How to move code and docs from GitHub to GitHub

[Jan Piotrowski]

To be honest, the first thing I would is to ask GitHub support if they
might be able help - just take the repo and move everything over to an
existing empty repo.

Best,
Jan

Am Fr., 10. Mai 2019 um 21:09 Uhr schrieb leerho :
>
> I am in the process of trying to move code from our current GitHub
> repositories to the newly assigned Apache incubator GitHub repositories.  I
> could use some advice on the best way to do this.
>
> So far, I have used the command
>
> $ > git push --all --tags --repo=g...@github.com:apache/incubator-.git
>
> This pushes code and tags from my laptop *clone* of our current repo to the
> apache repo.  But it does not transfer important *release documentation*,
> which is a feature of the GitHub repo website.
>
> Is there a way to effectively copy everything (code, tags, documentation,
> etc) directly from our current origin GitHub repo to the Apache repo?
> Without having to use my laptop clone in the middle? AND without wiping out
> the current origin GitHub repo?
>
> Otherwise, I am having to manually copy and paste all the associated
> release documentation!
>
> Any help would be appreciated!
>
> Thanks

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

Re: [DISCUSS] Graduate Apache Dubbo (incubating) as a Top Level Project

[Jan Piotrowski]

Semi OT:
Could somebody point me to Apache documentation that indicates that
such use of names of Apache projects is not ok? I might need that
information soon-ish myself, thanks.

-J

Am Mi., 24. Apr. 2019 um 17:07 Uhr schrieb Sheng Wu :
>
> Hi,
>
> 4. We plan to rename all projects in this organization to
> > xxx-for-apache-dubbo
>
> The rename makes sense for ecosystem projects, especially for these three.
> I also used to see the traditional rename to xxx-for-apache-project
> 1. js, https://github.com/dubbo/dubbo2.js
> 2. python, https://github.com/dubbo/dubbo-client-py
> 3. php, https://github.com/dubbo/dubbo-php-framework
>
> Also, please pay attention to this[1]. This is a release repo(npm), the
> description in Chinese, I assume it related to [2]. Right?
> If yes, this release dist should be renamed. SkyWalking used to be asked
> stop in the same case.
> Because it misguides user this is Apache release, which isn't.
>
> [1] https://www.npmjs.com/package/dubbo2.js
> [2] https://github.com/dubbo/dubbo2.js
>
> Sheng Wu 吴晟
>
> Apache SkyWalking, ShardingSphere, Zipkin
> Twitter, wusheng1108
>
>
> Sheng Wu  于2019年4月24日周三 下午10:46写道：
>
> > Hi
> >
> > > 1. We will remove the organization avatar
> > > 2. We are ready to rename organization name from 'dubbo' to other name
> > > 3. Because of action 2, we will also lose the domain name
> > dubbo.github.io,
> > > but it also makes things easier, since we don't need to keep website in
> > > this group
> > > 4. We plan to rename all projects in this organization to
> > > xxx-for-apache-dubbo
> >
> > Please discuss with your community, then make the decision. I just reply
> > the Huxing's. Transfer the repos in the org(except the dubbo.github.io,
> > if the community wants), is also a good idea.
> >
> > I think both you and Huxing have been clear about my concern. I trust the
> > Dubbo community could make it right.
> >
> > Thanks.
> >
> > Sheng Wu 吴晟
> >
> > Apache SkyWalking, ShardingSphere, Zipkin
> > Twitter, wusheng1108
> >
> >
> > Ian Luo  于2019年4月24日周三 下午10:16写道：
> >
> >> >
> >> > Those two are good options. Please read my prev reply[1], which
> >> concerns me
> >> > more are
> >> > 1. Website codebase.
> >> > 2. GitHub org name and logo.
> >>
> >>
> >> Sheng, If your concerns here are confirmed to be disallowed, we will do
> >> the
> >> following things against dubbo group:
> >> 1. We will remove the organization avatar
> >> 2. We are ready to rename organization name from 'dubbo' to other name
> >> 3. Because of action 2, we will also lose the domain name dubbo.github.io
> >> ,
> >> but it also makes things easier, since we don't need to keep website in
> >> this group
> >> 4. We plan to rename all projects in this organization to
> >> xxx-for-apache-dubbo
> >>
> >> Let me know if your concerns will be completely addressed once the actions
> >> above are made. Before it, I'd like to confirm with our mentors and
> >> hopefully get back to you soon.
> >>
> >> Regards,
> >> -Ian.
> >>
> >>
> >> On Wed, Apr 24, 2019 at 7:56 PM Huxing Zhang  wrote:
> >>
> >> > Hi,
> >> >
> >> > On Wed, Apr 24, 2019 at 11:01 AM Sheng Wu 
> >> > wrote:
> >> > >
> >> > > Hi.
> >> > >
> >> > > > As Justin mentioned above, the translation is under going. We cannot
> >> > do it
> >> > > for all because we need to examine the license and make sure ICLA for
> >> > each
> >> > > projects are signed,
> >> > >
> >> > > I am not asking to move all repo related to Dubbo, which is decided by
> >> > the
> >> > > project owner or Dubbo community.
> >> > >
> >> > > > eventually we hope to move everything into Apache group except for
> >> the
> >> > > repo [1] which serves redirection dubbo.io to dubbo.apache.org.
> >> > >
> >> > > As you mentioned, which make me concern more. Especially you say
> >> > > `eventually` and `hope`. Are these optional?
> >> >
> >> > No. The redirection has been completed.
> >> > You can test with: curl -i http://dubbo.io
> >> > The only effective file is index.html, possibly CNAME.
> >> > Other files are archive for the old website before joining ASF.
> >> > To make it better understandable, I think it is better to move them to
> >> > other place (e.g. a new branch) for archive purpose.
> >> > I update the description and readme, removing the word "eventually".
> >> >
> >> > > Please read your own Incubator Proposal[1], section Initial Source,
> >> "Home
> >> > > Page: https://github.com/dubbo/dubbo.github.io;
> >> > > If the transfer has not been finished, you should wait for that before
> >> > > graduation.
> >> >
> >> > IMO, the transfer has been finished. Requests to dubbo.io has been
> >> > redirected to dubbo.apache.org.
> >> >
> >> > >
> >> > > Why not just set the `redirect` on the DNS level, and host all in
> >> > > http://dubbo.apache.org. If the two are the same. If not, which is
> >> > harder
> >> > > to understand for me.
> >> >
> >> > Because the ownership of dubbo.io did not belong to either Apache or
> >> > Alibaba when Dubbo joined ASF.
> >> >