I think having it for one version as a release preview is a good approach that 
way we can get feedback also earlier on what we may want to add in which 
priority. Nothing better than user feedback which we only get after release 

Sent from my iPhone

> On 6 Jul 2017, at 18:06, Daniel Kulp <[email protected]> wrote:
> 
> 
>> On Jul 6, 2017, at 1:00 PM, Michael André Pearce 
>> <[email protected]> wrote:
>> 
>> My view on 2 is that currently there is no capability having anything is 
>> better than none.
>> 
>> Any extra features can be added over time by those willing to contribute. 
>> 
>> Indeed there are some bits I'd like to add but having something is better 
>> than nothing and certainly can now start the ball rolling.
> 
> Well, yes and no.    Once "released", you kind of have to build off of what’s 
> there and continue to support that way of doing things.   If what’s there 
> doesn’t make any sense and needs to be completely re-organized or something, 
> that could be difficult if we have to continue supporting the current layout. 
>   Kind of like a backwards compatibility thing.    I’d like a few folks to 
> make sure that what’s there makes some sense going forward and adding the 
> stuff that is missing can be done by extending what’s there in a way that 
> makes sense.    That said, for the first release, if we kind of release note 
> the console as a “technology preview, subject to change” or similar, I’d be 
> less concerned. 
> 
> Dan
> 
> 
> 
>> 
>> Sent from my iPhone
>> 
>>> On 6 Jul 2017, at 17:21, Daniel Kulp <[email protected]> wrote:
>>> 
>>> 
>>>> On Jul 6, 2017, at 10:15 AM, Clebert Suconic <[email protected]> 
>>>> wrote:
>>>> 
>>>> It seems that this is almost ready.. if we fix logging it could be 
>>>> merged...
>>>> 
>>>> 
>>>> It would be awesome if we could have the next release with this
>>>> already... even if we delay another week.
>>>> 
>>>> 
>>>> @Dan: WDYT?
>>> 
>>> Well, there are basically 4 “types” of things that need to be taken care of:
>>> 
>>> 1) Branding/skinning/packaging : this is what my lists have been 
>>> concentrating on.  Things are certainly looking better there.   I just did 
>>> a build and things look much better.  I’m “slightly” concerned about the 
>>> downgrade from 1.5.2 to 1.5.0 which I’m assuming is due to the flight 
>>> recorder stuff.   Certainly OK for now, but longer term I think we’d like a 
>>> better option so that we can get whatever security fixes are needed in 
>>> future versions.    There are some additional options to trim the war even 
>>> further such as an overlay config of:
>>> 
>>>        <overlays>
>>>            <overlay>
>>>                <groupId>io.hawt</groupId>
>>>                <artifactId>hawtio-web</artifactId>
>>>                <excludes>
>>>                    <exclude>bower_components/**/*</exclude>
>>>                    <exclude>app/site/**/*</exclude>
>>>                    <exclude>app/core/**/*</exclude>
>>>                </excludes>
>>>            </overlay>
>>>        </overlays>
>>> 
>>> 2) Actual capabilities :  I haven’t looked at this at all.   Art had a list 
>>> of things he expected to be able to manage based on the capabilities of the 
>>> 5.x console.   I’m not sure if his list is completely covered by the new 
>>> plugin or not as I haven’t looked at this aspect.
>>> 
>>> 
>>> 3) Integration : there are gaps here related to logging, security, 
>>> user/roles, etc… For testing, we’re currently bypassing all of this.
>>> 
>>> 4) Legal : There are MAJOR updates needed for the License/Notice files.   
>>> It’s a shame that the hawt.io folks aren’t doing this properly and meeting 
>>> the legal requirements of the licenses of everything they are including.  
>>> Just means we’re going to have to do it.   This is the big thing as I have 
>>> no idea how long this will take.   For every file in the war (and every 
>>> file within the jars within the war), we need to check it’s license status 
>>> and figure out what needs to be added to the license and notice files.   
>>> That’s not trivial.    With the above excludes, large chunks of things go 
>>> away (the bootstrap/docs for example are CC-BY which has notice 
>>> requirements) so there is less work to do, but there are still a bunch of 
>>> things in there.
>>> 
>>> 
>>> Because 4 is a big “unknown” and I have no idea on 2, I really wouldn’t 
>>> hold up the current releases for it.    In addition, since this is a “big 
>>> change”, I’d certainly want to make sure the rest of the community that 
>>> hasn’t looked at it gets a good chance to do so prior to a release.   Gut 
>>> feeling is that this is much more than a “3-4 day delay”.  
>>> 
>>> 
>>> -- 
>>> Daniel Kulp
>>> [email protected] - http://dankulp.com/blog
>>> Talend Community Coder - http://coders.talend.com
>>> 
> 
> -- 
> Daniel Kulp
> [email protected] - http://dankulp.com/blog
> Talend Community Coder - http://coders.talend.com
> 

Reply via email to