App freezing with 0.26 sdk update
Hi Team, We have updated our app with 0.26 sdk update, post which the app is responding slower to click events. Also, the rendering is slower as compared to previous versions. Request your support in this regard. -- Regards, Vipul Gupta Senior Technical Lead 8802232975
Re: [DISCUSS] How to handle Github Issue
Issues definitely are like weeds - there are always more. Some unstructured thoughts: - Add a feature request template - Add a support template that moves questions and debugging stuff to Stack Overflow (if you have many of those) - Add some more space to type into the bug report template, currently it is very full already on start - Try to quickly respond to new issue and ask for clarification - For Apache Cordova asking for a new, plain project with reproduction was a good way to move a lot of the work from committers to users: https://github.com/apache/cordova-contribute/blob/master/create-reproduction.md - Close issues that delete the issue template and ask them to create a new one - Think about not supporting older versions (and debugging of problems in them) - Use labels to "group" or categorize issues, that way it is much easier to just leave them open if they are for areas that are not in focus right now - Use milestones to "prioritize" issues. Something that is in "far future" doesn't have to be looked at vs. something that is in "next bugfix release" for example - For another bug OSS project I am working on I created a habit for myself to start every day with triaging and tagging all the new issues that came in over night. Issues without labels are "untriaged". That way it's 30 minutes per day to keep "up to date", and then the real work can start - Maybe try to communicate clearly which issues someone from the team will tackle, and which will need someone from the community to step up and in - Maybe tag your issues by language - could help non-bi-lingual users to look for issues they will understand (Currently quite frustrating for me to open all those issues I can't even read) Good luck! Am Di., 16. Juli 2019 um 12:31 Uhr schrieb 申远 : > > As you might observe, the quantity of Weex's users is huge, and there are > around 15 to 20 new Github issues every week. It's a lot of work for me to > verify, response and fix the issues especially some of them are in low > quality. For example, it took me 3 hours to read all the new issues and > close the one without reproduce procedure and verify other issues existing. > > I am really curious about how other Apache projects handle Github Issues. > Is Github Issues like grass that you must weed every week? > > And how to encourage users to get more involved, like reading the code and > create PRs instead of simply asking questions on Github? If we could find > promising contributors or committers in our users continually, then we > shall build a more healthy community. > > I know there are many projects around Weex, like EEUI[1], EMAS[2], etc.. > And I even know there are books about how to write code using Weex. It's > totally fine if one want to create its own community or project based on > Weex, but it would be great if such projects could join the Weex community. > > [1] https://eeui.app/ > [2] https://cn.aliyun.com/solution/emas > > Best Regards, > YorkShen > > 申远
Concerned about the LGPL dependency in Webkit
Hey all, First of all: congratulations on your recent release! I wanted to circle back to this to make sure it gets resolved before the next release. First a summary of what has happened as I see it. If my summary is incorrect, please let me know: * At some point in the past Weex introduced a run-time and a compile-time dependency to Webkit. When adding the Webkit *.h to the repo, the correct license of those files was accidentally overwritten. * More recently, this mistake was discovered and a license review of Webkit as a dependency was made in which it was realized that Webkit: "As Webkit is under dual license, and it's almost impossible for us to figure out whether there is an function call chain like Weex.apiA->Webkit.BSD.apiB->Webkit.BSD.apiC->Webkit.LGPL.apiD. I'd like to know our proposed change is enough to fix the Category X dependency." ( https://lists.apache.org/thread.html/babe010a7814d4cf3d3d92588bee9dd22277b610daf83733d2622c91@%3Cgeneral.incubator.apache.org%3E ) * The question of whether Webkit could release like this was raised to the incubator and then to legal. * Despite the lack of resolution to this question, Weex was still allowed to make it's most recent release, because Weex is still in incubation. While reviewing the release, it became clear to me that Weex is including WebKit for it's JavaScriptCore. Within WebKit, JavaScriptCore is LGPL-licensed. So it is likely that your functional call chains will include LGPL-licensed code (after all that's the code you're including WebKit for). Is there an alternative implementation of JavaScriptCore that a user could use in place of the LGPL-licensed portions of WebKit? Best Regards, Myrle
[DISCUSS] How to handle Github Issue
As you might observe, the quantity of Weex's users is huge, and there are around 15 to 20 new Github issues every week. It's a lot of work for me to verify, response and fix the issues especially some of them are in low quality. For example, it took me 3 hours to read all the new issues and close the one without reproduce procedure and verify other issues existing. I am really curious about how other Apache projects handle Github Issues. Is Github Issues like grass that you must weed every week? And how to encourage users to get more involved, like reading the code and create PRs instead of simply asking questions on Github? If we could find promising contributors or committers in our users continually, then we shall build a more healthy community. I know there are many projects around Weex, like EEUI[1], EMAS[2], etc.. And I even know there are books about how to write code using Weex. It's totally fine if one want to create its own community or project based on Weex, but it would be great if such projects could join the Weex community. [1] https://eeui.app/ [2] https://cn.aliyun.com/solution/emas Best Regards, YorkShen 申远
Re: [ANNOUNCEMENT] Separate weex_sdk and weex_playground for good
Awesome, that was quick - thanks Katherine and RenminWang! I will try to check out and play with https://github.com/apache/incubator-weex-playground soon. A note: Now that playground is separate, https://github.com/apache/incubator-weex#use-weex could use some cleanup to make clear what Playground is and how it is integrated into the main repo - that is still confusing to me (Actually, https://github.com/apache/incubator-weex-playground could use an introduction paragraph what Playground is and how it uses Weex). https://weex.apache.org/tools/playground.html could also use a link to the repository. -J Am Di., 16. Juli 2019 um 05:00 Uhr schrieb 申远 : > > Also, I'd really appreciate the contribution of @Katherine and @RenminWang, > as they are the ones who actually write code here for above purpose. > > Best Regards, > YorkShen > > 申远 > > > 申远 于2019年7月16日周二 上午10:52写道： > > > As it's discussed before[1] , we have successfully separated weex_sdk[2] > > and weex_playground[3] into two git repos without losing the users' > > convenience by making weex_playground a git submodule of weex_sdk. > > > > Next, we shall decouple Webkit(Weex only uses JavaScriptCore inside > > Webkit) from the convenience binary of weex_sdk. We expect to finish the > > job in August, 2019 before next release. > > > > Finally, we will fix the package name issue of Android [4]. The time > > schedule for issue is not settled yet. > > > > The goal of the above changing is to make Weex clear in both dependencies > > and IP(package name) aspects, and we will be able to publish a Release > > without deleting files(Webkit.so) from git repo [5]. > > > > The issues above may not be a problem for a normal user of Weex, as they > > are time consuming and don't add new features or fix bugs for Weex. But if > > we consider Weex as a project that may be alive for more than ten years, > > it's sooner than later to make dependency and IP(package name) clear. I > > can't image how to fix these issues for a project with above ten-years > > history. > > > > [1] > > https://lists.apache.org/thread.html/020895785263a3f5ee4dfa6c56167c01699227d9512f19f6635ef563@%3Cdev.weex.apache.org%3E > > [2] https://github.com/apache/incubator-weex > > [3] https://github.com/apache/incubator-weex-playground > > [4] > > https://lists.apache.org/thread.html/b3c4974a208f87e21c1f12b4ba5e5308cf20f7678cedd4523b5ddf25@%3Cdev.weex.apache.org%3E > > [5] > > https://github.com/apache/incubator-weex/blob/master/scripts/generate_apache_source.sh > > > > Best Regards, > > YorkShen > > > > 申远 > >
