Scott,

I understand the vision. I was actually echoing what Matt said i.e. if the
contributions being made to the sub-project has any supporting changes that
*should* exist in the core-project i.e. NiFi or any other projects that use
this sub-project, they have to be checked by the committer. But you have
made it clear that it's going to be a npm module so I understand it better
now. Disregard my previous comment.

-
Sivaprasanna

On Fri, Feb 23, 2018 at 9:16 AM, Tony Kurc <tk...@apache.org> wrote:

> Is some of the thinking that projects other than nifi projects would use
> this?
>
> On Feb 22, 2018 10:00 PM, "Scott Aslan" <scottyas...@gmail.com> wrote:
>
> > Sivaprasanna,
> >
> > I am not sure I follow exactly what you are saying...
> >
> > NiFi Registry would no longer continue to host a copy of the FDS
> NgModule.
> > Instead, NiFi Registry would just add the NiFi FDS sub-project as a
> client
> > side dependency in its package.json. This would be analogous to how NiFi
> > Registry depends on Angular Material, etc. npm supports the ability to
> > download published packages which are current with the latest stable
> > release of a package. npm *also* supports the ability to develop off
> > of the *master
> > branch (or any other branch really)* of the NiFi FDS. An example of this
> > can be found in the github.io demo here
> > <https://github.com/scottyaslan/fluid-design-
> system/blob/gh-pages/package.
> > json#L45>
> > . By placing that dependency in the package.json for the NiFi Registry
> each
> > subsequent clean build would automatically download the latest master
> > branch of the NiFi FDS sub-project and developers can leverages the
> latest
> > NiFi FDS components.
> >
> > This also brings up a good point about release management. I have also
> > included a prototype of one possible implementation of automating the
> > tagging of a branch and automatically updating release version numbers
> etc.
> > leveraging grunt-bump [1]. The FDS-0.0.1-RC.0 tag [2] was created with
> the
> > described grunt task.
> >
> > [1]
> > https://github.com/scottyaslan/fluid-design-system/blob/master/Gruntfile
> .
> > js#L47
> >
> > [2] https://github.com/scottyaslan/fluid-design-
> system/tree/FDS-0.0.1-RC.0
> >
> > On Thu, Feb 22, 2018 at 12:39 PM, Sivaprasanna <
> sivaprasanna...@gmail.com>
> > wrote:
> >
> > > I agree with Matt. With clear documentation and guides, contributions
> on
> > > the sub-projects can be streamlined and be ensured that the necessary
> > > changes are already available on the core project i.e NiFi. One
> challenge
> > > is that the committer of the sub-project should have the courtesy to
> > check
> > > wether the supporting changes are made available to the core project
> and
> > > track its status but given how contributions are being handled in
> > > nifi-registry project, I don’t think it’s going to be that much of a
> > > headache.
> > >
> > > We could also add to the helper doc mentioning that if the contribution
> > is
> > > going to affect a core component, the contributor needs to add the JIRA
> > id
> > > of the core project’s supporting changes in the sub-projects’ issue
> > > description.
> > >
> > > On Thu, 22 Feb 2018 at 10:42 PM, Matt Gilman <matt.c.gil...@gmail.com>
> > > wrote:
> > >
> > > > Joe, Joe,
> > > >
> > > > Regarding the release process... I think it could be similar to how
> > folks
> > > > verified and validated the NiFi Registry release. Guidance was given
> > in a
> > > > helper guide regarding how to obtain/build a branch or PR that
> > references
> > > > the new components. For the Registry release, there was a PR for NiFi
> > > that
> > > > had the supporting changes already available.
> > > >
> > > > We may have this issue any time we release new versions that depend
> on
> > > > another (sub)project.
> > > >
> > > > Matt
> > > >
> > > > On Thu, Feb 22, 2018 at 11:39 AM, Joe Percivall <
> jperciv...@apache.org
> > >
> > > > wrote:
> > > >
> > > > > Scott,
> > > > >
> > > > > Definitely like the direction of standardizing NiFi and Registry
> > around
> > > > the
> > > > > same set of components, so the user has a common UX. Is there
> > precedent
> > > > for
> > > > > creating a new sub-project just for common components/modules to be
> > > used
> > > > by
> > > > > the top-level, and it's other sub-projects? My concerns are similar
> > to
> > > > > Joe's. Along those lines, if the core problems we're trying to
> > address
> > > is
> > > > > the release process and distribution, is there a less
> "heavy-weight"
> > > > > avenue?
> > > > >
> > > > > In the past, we've also talked about pulling out the core NiFi
> > > framework
> > > > to
> > > > > be shared between NiFi and MiNiFi-Java for similar reasons. How we
> go
> > > > about
> > > > > solving this for the UI could be used a model for the core
> framework
> > as
> > > > > well.
> > > > >
> > > > > - Joe
> > > > >
> > > > > On Thu, Feb 22, 2018 at 10:58 AM, Mike Thomsen <
> > mikerthom...@gmail.com
> > > >
> > > > > wrote:
> > > > >
> > > > > > Also, what sort of framework is the UI being standardized on?
> > > Angular?
> > > > > > React? Something else?
> > > > > >
> > > > > > On Thu, Feb 22, 2018 at 10:03 AM, Joe Witt <joe.w...@gmail.com>
> > > wrote:
> > > > > >
> > > > > > > Scott
> > > > > > >
> > > > > > > Ok so extract out the fluid design work you started with NiFi
> > > > Registry
> > > > > > > to its own codebase which can be rev'd and published to NPM
> > making
> > > it
> > > > > > > easier to consume/reuse across NiFi projects and offers better
> > > > > > > consistency.  This sounds interesting.
> > > > > > >
> > > > > > > In thinking through the additional community effort or the
> effort
> > > > > > > trade-off:
> > > > > > > How often do you anticipate we'd be doing releases (and thus
> > > > > > > validation/voting) for this?
> > > > > > > How often would those differ from when we'd want to do a NiFi
> or
> > > NiFi
> > > > > > > Registry release?
> > > > > > > How do you envision the community would be able to help
> > > vet/validate
> > > > > > > releases of these modules?
> > > > > > >
> > > > > > > Thanks
> > > > > > > Joe
> > > > > > >
> > > > > > > On Thu, Feb 22, 2018 at 8:18 AM, Scott Aslan <
> > > scottyas...@gmail.com>
> > > > > > > wrote:
> > > > > > > > NiFi Community,
> > > > > > > >
> > > > > > > > I'd like to initiate a discussion around creating a
> sub-project
> > > of
> > > > > NiFi
> > > > > > > to
> > > > > > > > encompass the Fluid Design System NgModule created during the
> > > > > > development
> > > > > > > > of the NiFi Registry. A possible name for this sub-project is
> > > > simply
> > > > > > > > "NiFi Fluid
> > > > > > > > Design System". The idea would be to create a sub-project
> that
> > > > > > > distributes
> > > > > > > > an atomic set of high quality, reuse-able, theme-able, and
> > > testable
> > > > > > UI/UX
> > > > > > > > components, fonts, and other JS modules for use across the
> > > various
> > > > > web
> > > > > > > > applications throughout the NiFi universe (uNiFiverse???).
> Both
> > > > NiFi
> > > > > > and
> > > > > > > > NiFi Registry web applications would eventually leverage this
> > > > module
> > > > > > via
> > > > > > > > npm. This approach will enable us to provide our users with a
> > > > > > consistent
> > > > > > > > experience across web applications. Creating a sub-project
> > would
> > > > also
> > > > > > > allow
> > > > > > > > the FDS code to evolve independently of NiFi/NiFi registry
> and
> > be
> > > > > > > released
> > > > > > > > on it's own timeline. In addition, it would make tracking
> > > > issues/work
> > > > > > > much
> > > > > > > > clearer through a separate JIRA.
> > > > > > > >
> > > > > > > > Please discuss and provide and thoughts or feedback.
> > > > > > > >
> > > > > > > > Thanks,
> > > > > > > >
> > > > > > > > Scotty
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > *Joe Percivall*
> > > > > linkedin.com/in/Percivall
> > > > > e: jperciv...@apache.com
> > > > >
> > > >
> > >
> >
>

Reply via email to