Hi Alex. Great news, I'm super excited to see this land! I don't think the PR approach makes sense in this context, the code is completely different from the current code base, there isn't much benefit or doing a PR and see the differences between the two.
I would push directly IMO. Best. On Thu, 26 Jul 2018 at 10:32 Alex Heneveld <alex.henev...@cloudsoftcorp.com> 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 Brooklyn > > > > > > On Mon, 23 Jul 2018 at 14:13 Richard Downer <rich...@apache.org> wrote: > > > >> +1 (binding) > >> > >> Having seen this UI in action I'd be very happy for it to land into > >> Brooklyn. 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 > the > >> old UI to the new. > >> > >> Richard. > >> > >> > >> On Mon, 23 Jul 2018 at 10:07, Alex Heneveld < > >> alex.henev...@cloudsoftcorp.com> > >> wrote: > >> > >>> Hi Brooklyners- > >>> > >>> This is a vote on whether to accept the brooklyn-ui-angular > contribution > >>> at [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 been > >>> completed and is on file -- thank you Cloudsoft and Fujitsu -- and is > >>> currently going through IP Clearance (see prior email to this list) and > >>> barring 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/` subdirectory > >>> in 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 documented > >>> cleanly. It is proposed that those PRs be reviewed in the usual way > (no > >>> further 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 we > >>>> will look for a vote here. If you have any comments on the code or on > >>>> the process in the meantime please let me know. > >>>> > >>>> Best > >>>> Alex > >>>> > >>>> [1] > >>>> > >> > http://svn.apache.org/viewvc/incubator/public/trunk/content/ip-clearance/brooklyn-ui-angular.xml?view=markup > >>>> [2] > >>>> > >> > https://incubator.apache.org/ip-clearance/ip-clearance-template.html#form-filling > >>>> > >>>> 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 have > >>>>> already 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 (note > >>>>> below on the Karaf switch) > >>>>> > >>>>> * Ensure all tests are passing (esp UI tests) > >>>>> > >>>>> * Ensure there are effective dev/test pathways and that documentation > >>>>> is 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 the > >>>>> approval (as this is a large contribution we recognise this will need > >>>>> special 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 > >>> > > -- Thomas Bouron Senior Software Engineer *Cloudsoft <https://cloudsoft.io/> *| Bringing Business to the Cloud GitHub: https://github.com/tbouron Twitter: https://twitter.com/eltibouron Need a hand with AWS? Get a Free Consultation.
