<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2018-05-16 23:25 GMT+02:00 Walter Bender <span dir="ltr"><<a href="mailto:walter.bender@gmail.com" target="_blank">walter.bender@gmail.com</a>></span>:</div><div class="gmail_quote"><br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><span></span><div class="gmail_quote"><div>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. </div></div></div></blockquote><div><br></div><div>Yes, it's true.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><br clear="all"><div>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?</div><div><br></div></div></blockquote><div><br></div><div>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.<br></div><div> </div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>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.</div><div><br></div></div></blockquote><div><br></div><div>I'm not familiar enough with licenses compatibilities to have a clear opinion. I'm agree to hear advices on it.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>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?</div><div><br></div></div></blockquote><div><br></div><div>Sure. Why not.</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div></div><div>3A. What is the process by which I can lobby to get Music Blocks included?</div><div><br></div></div></blockquote><div><br></div><div>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.<br></div><div>My concerns about it is:</div><div>- 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 ?<br></div><div>- 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.<br></div><div>- 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 ?</div><div><br></div><div>Best regards.</div><div><br></div><div>      Lionel.</div><br></div></div></div>