To formally close this, I note the vote passes with: * 6 binding +1s * 0 non-binding +1s * no 0 or -1 votes Vote thread link: http://mail-archives.apache.org/mod_mbox/brooklyn-dev/201807.mbox/%3C5dc7ad59-795e-fa7a-af32-918848229b32%40CloudsoftCorp.com%3E Binding +1s: Thomas Bouron Mark McKenna Aled Sage Richard Downer Geoff Macartney Alex Heneveld Best, Alex On 26/07/2018 10:32, Alex Heneveld wrote:
Hi Brooklyners- I also give a +1 (binding). With 72h elapsed I declare the VOTE closed and passed.The [IP-CLEARANCE] also passed as folks will see. I will incorporate the new code now. I will do this as a PR for visibility and call out the IP-CLEARANCE process links in that PR, unless anyone thinks a different approach is more suitable (e.g. pushing directly?).Best regards Alex On 23/07/2018 14:22, Geoff Macartney wrote:+1 (binding) Excited to see this go into BrooklynOn Mon, 23 Jul 2018 at 14:13 Richard Downer <rich...@apache.org> wrote: * 5 binding +1s* 0 non-binding +1s * no 0 or -1 votes Vote thread link: https://mail-archives.apache.org/mod_mbox/incubator-brooklyn-dev/201509.mbox/%3C55E9C778.80907%40CloudsoftCorp.com%3E Binding +1s: Richard Downer Alex Heneveld Hadrian Zbarcea (IPMC) Aled Sage Sam Corbett+1 (binding) Having seen this UI in action I'd be very happy for it to land intoBrooklyn. It's a much more modern-looking, aesthetically-pleasing UI with much more extensibility, but at it's core the UI works very similar to the old one, so there's very little learning curve for a user moving from theold UI to the new. Richard. On Mon, 23 Jul 2018 at 10:07, Alex Heneveld < alex.henev...@cloudsoftcorp.com> wrote:http://svn.apache.org/viewvc/incubator/public/trunk/content/ip-clearance/brooklyn-ui-angular.xml?view=markupHi Brooklyners-This is a vote on whether to accept the brooklyn-ui-angular contributionat [1] once IP clearance is completed.For background, as previously discussed a new UI based on Angular/JS has been offered to the Apache Brooklyn project. The formal grant has beencompleted and is on file -- thank you Cloudsoft and Fujitsu -- and iscurrently going through IP Clearance (see prior email to this list) andbarring obstacles we may have that clearance after 72 hours. The vote to accept can occur in parallel with the clearance so that is what we are doing.We propose for the code to be added iniitially to a `new/` subdirectoryin the `brooklyn-ui` repo, once IP clearance is completed and if this vote is successful. We will then create a set of PRs to replace the contents at the root with the contents under `new/` and make changes elsewhere as needed for the project to build, run, and be documentedcleanly. It is proposed that those PRs be reviewed in the usual way (nofurther votes) unless anyone thinks otherwise. This vote will run for 72 hours. Best Alex [1] https://issues.apache.org/jira/browse/INCUBATOR-214 On 20/07/2018 16:14, Alex Heneveld wrote:Hi All- The codebase for the UI is staged for review here: https://github.com/ahgittin/brooklyn-ui/tree/new-ui-for-review/new We have created the ip-clearance record [1] to track steps and the legal grant is in process (as per [2]). We will call for an [IP CLEARANCE] at general@incubator once those are completed, and then wewill look for a vote here. If you have any comments on the code or onthe process in the meantime please let me know. Best Alex [1]https://incubator.apache.org/ip-clearance/ip-clearance-template.html#form-filling[2]On 28/05/2018 12:46, Alex Heneveld wrote:Dear Brooklyners, Our users at Fujitsu, UShareSoft, and Cloudsoft have generously sponsored the contribution of a new UI for Apache Brooklyn. This is based on the previously-proprietary Cloudsoft AMP UI, for those of you familiar with that. The proposed newly contributed UI has all the functionality of the existing UI including an inspector, groovy console, and online REST docs. It is much more recent (angular, webpack), modular, easy to develop against, and lovely to look at, and so would be a great contribution based solely on that. But even better, it provides a lot of new features: * A visual blueprint composer: drag-and-drop elements from the catalog onto a canvas, with a bi-directional YAML editor * More live activity update: a kilt view for activities, tailing output from SSH commands * A bundle-oriented catalog: with search, bundle- or type- view, delete bundles * An extensible, skinnable, and reusable modular architecture: embed angular directives and components from this project in others, build a branded version of the UI, and/or add your own modules (e.g. to accompany specific blueprints) The last point in particular I think will be very valuable: it will allow people to use Brooklyn in many more good ways! There are plans to make the Composer embeddable and able to work with other input libraries (think e.g. of pointing it at a Docker repo or an image catalog), and with widgets for configuring items, all ultimately generating Brooklyn blueprints.Note that this is proposed to replace the existing UI, and as we havealready deprecated the non-OSGi build, it is proposed to make this compatible only with the OSGi build. It is also worth pointing out that the main authors on this UI are already Brooklyn contributors, so there is enough experience among active project members to maintain, explain, and extend this. Assuming this proposal finds favour, we will open a repo for review purposes (but it will not be a merged via PR, with the actual contribution to come via the IP clearance process [1]), followed by associated PRs in other projects so that everything works seamlessly (which as minor changes to existing code is more suited to PRs than the IP clearance process). Specifically we will:* Ensure it builds and runs with the new UI in place of the old (notebelow on the Karaf switch) * Ensure all tests are passing (esp UI tests)* Ensure there are effective dev/test pathways and that documentationis updated (in particular for testing the UI and with the UI; this should be much simpler as the new UI can run separately, point at a REST endpoint, and can do incremental updates for UI code changes made while running!) * Ensure we have IP clearance, license, and are duly diligent in theapproval (as this is a large contribution we recognise this will needspecial attention) Are there any objections at this point, or any suggestions for other tasks we should do to ensure its smooth integration? Note that this is purely advisory at this stage but we would very much appreciate early sight of any potential obstacles. Once the above list is complete we will commence the IP clearance process including formal vote. Best, Alex [1]https://incubator.apache.org/ip-clearance/ip-clearance-template.html
