2018-05-16 23:25 GMT+02:00 Walter Bender <walter.ben...@gmail.com>: As a sometimes activity maintainer, my biggest issue is that I get zero > feedback from the deployments about bugs or anything else for that matter. > This is true for both Sugar and Sugarizer. >
Yes, it's true. > 1. How do I keep, for example, Turtle Blocks current within Sugarizer. > Since there are local patches being made, it is not easy for me as a > developer to keep things current. I've reached out on occasion to Michael > for help, but it seems really awkward from outside looking in to keep the > Sugarizer version up to date. Perhaps git-subtree [1] could be considered? > > As I said to James, when the maintainer for a Sugarizer activity still maintain its repo (a minority of Sugarizer activities), I'm trying to send regularly PR to ensure that Sugarizer compatibility is still there. I didn't know subtree feature. Sounds good. Not sure to fully understand how it works. BTW I'm not opposed to test it. 2. Do you have a plan for reconciling the licensing issue [2]? The issue is > marked as Wont Fix, but I don't think that is adequate. In addition, there > has been a lot of unilateral re-licensing of GPL and AGPL content to > Apache. This is not OK. We could ask the SFC for their advice as to how to > proceed. > > I'm not familiar enough with licenses compatibilities to have a clear opinion. I'm agree to hear advices on it. > 3. While I agree with many of the criteria that you and James are using > for your packaging decisions, I would think it would be in all of our > interests to discuss these decisions more broadly. There are a number of > community members with a great deal of experience in both pedagogy and > deployments whom we could learn from. Perhaps an occasional open meeting to > discuss this? > > Sure. Why not. > 3A. What is the process by which I can lobby to get Music Blocks included? > > I don't have enough music knowledge but Music Blocks look like a good replacement for the G1G1 TamTam suite. It will nice to integrate it in Sugarizer. My concerns about it is: - It was not conceived with Sugar-web in mind so it should be adapted to handle datastore and propose the minimal Sugar UI need: a stop button. BTW I guess it should be the same work done in TurtleJS ? - It's not tested on Safari and EDGE which it's a platform need for Sugarizer. There is some UI issue on EDGE for example. - Activity size is huge (68Mb), it's an important thing to consider when deploying on stores. Android for example limit applications size to 100Mb and Sugarizer size is already 60Mb (without Abecedarium sounds). May be Music Blocks size could be reduced ? Best regards. Lionel.
_______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel