Thanks for your feedback Robert.
What about doing Helm Chart release now from the main repo (just with a
dedicated tag and source distro) and then move forward on separate repo
after this release ?
We can “unblock” the users with an official release and then prepare the
next release.
Regards
JB
Le lun. 21 juil. 2025 à 10:54, Robert Stupp <sn...@snazy.de> a écrit :
> Hi all,
>
> regarding the consensus, let's quickly recap the options here:
>
> 1. Keep Helm chart releases with the "main" Polaris release
> 2. Separate Helm charts releases
>
> For 1) there's nothing to be done. Helm Charts releases would be
> drafted ("RC") and eventually released ("GA") as an orthogonal effort,
> but technically part of the semi-automatic release process.
> For 2) there are a couple considerations: Helm Charts won't be covered
> by the semi-automatic release process that's currently being worked
> on. A separate manual release process and guide would be needed.
>
> Another aspect is the compatibility matrix of the Helm Chart to
> Polaris. To ensure compatibility, an exhaustive CI test matrix is IMHO
> required. For option 1, it could mean that the Helm Chart version must
> be equal to the Polaris version. For option 2, the CI test matrix is
> IMHO mandatory, which in turn raises the requirement to move the
> helm-charts to either a separate Git repository or polaris-tools.
>
> I would personally prefer option 2, but that is quite some work.
>
>
> On Mon, Jul 21, 2025 at 10:43 AM Jean-Baptiste Onofré <j...@nanthrax.net>
> wrote:
> >
> > Hi Yun
> >
> > I would propose to focus on the following:
> > 1. We have a "isolated" release cycle for Helm Chart
> > 2. We do a Helm Chart release as soon as we need to fix/unblock users
> >
> > Snapshot is not a release (official one), so, not sure it actually
> > helps (or just for testing purpose).
> >
> > In order to move forward, I propose:
> > 1. Move helm chart in a separate repo
> > (https://github.com/apache/polaris-helm-chart), including the
> > corresponding GH Actions
> > 2. We prepare a new "official" release on this repo
> >
> > If we have a consensus here, I'm happy to tackle that.
> >
> > Thoughts ?
> >
> > Regards
> > JB
> >
> >
> > On Mon, Jul 21, 2025 at 4:14 AM yun zou <yunzou.colost...@gmail.com>
> wrote:
> > >
> > > Hi all,
> > >
> > > I think we are separating the discussion into two parts: the long term
> plan for Helm Chart release,
> > > and the short term plan to mitigate the use issue.
> > >
> > > For the long term, it sounds like we would like to go with a separate
> release for Helm Chart, and want to
> > > move Helm Chart to a separate repo.
> > >
> > > For a short term plan, I think we need to answer two questions first:
> > > 1) Whether we think it is important to unblock the use case as soon as
> possible?
> > > 2) If we do want to unblock the use case as soon as possible, what
> would be the approach to adopt?
> > >
> > > If there are many use cases, and there is still a long time until the
> next formal release, it is probably
> > > worth the effort to get an approach to unblock the users soon.
> > >
> > > If we do want to unblock the use case soon, we probably should start
> the process as soon as possible,
> > > either the "snapshot" approach or just do a 1.1 release. It seems that
> people do prefer to just
> > > release 1.1 with patch.
> > >
> > > Given the fact that we only receive one complaint now, maybe we can
> wait for a while to see if there are
> > > more complaints and then decide.
> > >
> > > Best Regards,
> > > Yun
> > >
> > >
> > >
> > >
> > > On Sun, Jul 20, 2025 at 9:48 AM Jean-Baptiste Onofré <j...@nanthrax.net>
> wrote:
> > >>
> > >> Hi,
> > >>
> > >> I guess you don't mean release, because a release (nightly or not) at
> > >> Apache requires a vote and approval from PPMC + IPMC members.
> > >> If you mean, nightly "snapshots" Helm chart build, it's OK.
> > >>
> > >> However, it should be clearly for testing (it's nightly/snapshot so
> > >> it's not for production). For production, as we plan independent
> > >> release cycle for Helm Chart, we should just do a "regular" release.
> > >>
> > >> Regards
> > >> JB
> > >>
> > >> On Fri, Jul 18, 2025 at 10:39 PM yun zou <yunzou.colost...@gmail.com>
> wrote:
> > >> >
> > >> > The purpose of a nightly Helm Chart release is to *quickly* unblock
> users,
> > >> > as in this issue: https://github.com/apache/polaris/issues/2030.
> > >> >
> > >> > The release process for the nightly Helm Chart would follow the
> same approach
> > >> > as the current one—the main difference is that we’d need to
> publish it to a
> > >> > separate release repository. As @Jean-Baptiste Onofré mentioned,
> we also
> > >> > need to include the source in the release, which is not done yet.
> > >> >
> > >> > Alternatively, we could opt for a formal 1.0.1 release if that's
> preferred, though
> > >> > it may take longer for users to actually be able to use it. If that
> approach is preferred
> > >> > and we agree that unblocking users quickly is important, then it
> might be best
> > >> > to start the process as soon as possible.
> > >> >
> > >> > Best Regards,
> > >> > Yun
> > >> >
> > >> > On Fri, Jul 18, 2025 at 11:29 AM Dmitri Bourlatchkov <
> di...@apache.org> wrote:
> > >> >>
> > >> >> Sorry, I'm still not clear on the technical details of nightly helm
> > >> >> releases. I imagine any official release will need a vote.
> > >> >>
> > >> >> If the intent of nightly helm releases is to allow end users to
> use them in
> > >> >> their deployment environments (not just for testing), I do not
> think it
> > >> >> would be a good idea due to lack of control of what actually goes
> into
> > >> >> those artifacts. Users who want to use the very latest helm charts
> can
> > >> >> always track `main` at the source level.
> > >> >>
> > >> >> In any case, since we obviously have some user demand for a helm
> chart fix,
> > >> >> I suppose we could do a 1.0.1 release from the old 1.0.0 release
> branch by
> > >> >> back-porting just helm chart fixes there and using the same manual
> process
> > >> >> as for 1.0.0. This will not require adding a separate source
> bundle for the
> > >> >> charts (it's part of the normal release already).
> > >> >>
> > >> >> Cheers,
> > >> >> Dmitri.
> > >> >>
> > >> >> On Fri, Jul 18, 2025 at 1:55 PM yun zou <
> yunzou.colost...@gmail.com> wrote:
> > >> >>
> > >> >> > This is based on what was mentioned in the first email
> > >> >> >
> > >> >> > > Meanwhile, we can start to release the nightly Helm Chart as a
> quick
> > >> >> > > solution for any users trying the new release with JDBC
> backend. Thoughts
> > >> >> > > and volunteers for this one?
> > >> >> >
> > >> >> > I think the proposal is to do a non-formal release for Helm
> Chart with the
> > >> >> > current master, and we will need a different place (not the same
> as the
> > >> >> > current
> > >> >> > helm chart release) to publish this Helm Chart release.
> > >> >> >
> > >> >> > Best Regards,
> > >> >> > Yun
> > >> >> >
> > >> >> >
> > >> >> >
> > >> >> > On Fri, Jul 18, 2025 at 9:03 AM Dmitri Bourlatchkov <
> di...@apache.org>
> > >> >> > wrote:
> > >> >> >
> > >> >> > > Hi Yun,
> > >> >> > >
> > >> >> > > What do you mean by a "quick nightly release" for helm charts?
> How will
> > >> >> > it
> > >> >> > > work technically?
> > >> >> > >
> > >> >> > > Thanks,
> > >> >> > > Dmitri.
> > >> >> > >
> > >> >> > > On Fri, Jul 18, 2025 at 11:54 AM yun zou <
> yunzou.colost...@gmail.com>
> > >> >> > > wrote:
> > >> >> > >
> > >> >> > > > Hi Team,
> > >> >> > > >
> > >> >> > > > I'd like to bring this thread back to the top. Aside from
> the long-term
> > >> >> > > > plan to separate
> > >> >> > > > the release, are we still considering a quick nightly
> release to
> > >> >> > unblock
> > >> >> > > > users, or are
> > >> >> > > > we ok to wait for the next scheduled release (seems the next
> scheduled
> > >> >> > > > release is around Aug 20th) ?
> > >> >> > > >
> > >> >> > > > Be
> > >> >> > > >
> > >> >> > > > On Mon, Jul 14, 2025 at 11:38 AM yun zou <
> yunzou.colost...@gmail.com>
> > >> >> > > > wrote:
> > >> >> > > >
> > >> >> > > > > If we decide to adopt an independent release cadence for
> the Helm
> > >> >> > > > > chart, it might
> > >> >> > > > > be more intuitive to host it in a separate repository.
> While this
> > >> >> > would
> > >> >> > > > > increase the
> > >> >> > > > > effort required to maintain compatibility between Helm
> chart releases
> > >> >> > > and
> > >> >> > > > > Polaris
> > >> >> > > > > releases—particularly around testing and documentation—it
> could be a
> > >> >> > > > > worthwhile
> > >> >> > > > > trade-off if we start seeing frequent divergence in
> release timelines
> > >> >> > > > > between the two
> > >> >> > > > > (whether the chart moves faster or slower). That said, if
> Polaris
> > >> >> > > > > continues to release
> > >> >> > > > > at a fast pace, the added complexity may not be necessary.
> > >> >> > > > >
> > >> >> > > > > In parallel with this discussion on separate release
> cadences for the
> > >> >> > > > Helm
> > >> >> > > > > chart, another
> > >> >> > > > > important point raised in this thread is whether we should
> consider
> > >> >> > > doing
> > >> >> > > > > nightly build
> > >> >> > > > > releases in the short term?
> > >> >> > > > > This could help address the JDBC use case mentioned here:
> > >> >> > > > > https://github.com/apache/polaris/issues/2030.
> > >> >> > > > > might be helpful in unblocking that use case and could
> support
> > >> >> > > onboarding
> > >> >> > > > > more users
> > >> >> > > > > ahead of the next official Polaris release.
> > >> >> > > > >
> > >> >> > > > > Best Regards,
> > >> >> > > > > Yun
> > >> >> > > > >
> > >> >> > > > >
> > >> >> > > > >
> > >> >> > > > >
> > >> >> > > > > On Mon, Jul 14, 2025 at 10:42 AM Dmitri Bourlatchkov <
> > >> >> > di...@apache.org
> > >> >> > > >
> > >> >> > > > > wrote:
> > >> >> > > > >
> > >> >> > > > >> I also think that the compatibility between helm charts
> and Polaris
> > >> >> > > > >> binaries will need more attention if we use a separate
> repository.
> > >> >> > > > >>
> > >> >> > > > >> However, from my POV I'd expect helm charts to get
> changes /
> > >> >> > > > contributions
> > >> >> > > > >> independently of the Polaris Server code (for all sorts of
> > >> >> > deployment
> > >> >> > > > >> choices), so having it in a separate repository is
> probably going
> > >> >> > to
> > >> >> > > > make
> > >> >> > > > >> maintenance easier (to recap: I originally supported more
> frequent /
> > >> >> > > > >> independent chart releases too).
> > >> >> > > > >>
> > >> >> > > > >> We could release Polaris Server patch releases with Helm
> changes but
> > >> >> > > > >> without server code changes, but I guess this kind of
> release
> > >> >> > process
> > >> >> > > > will
> > >> >> > > > >> be error-prone and more difficult for release managers
> (for having
> > >> >> > to
> > >> >> > > > pay
> > >> >> > > > >> close attention to what needs to be cherry-picked).
> > >> >> > > > >>
> > >> >> > > > >> +1 to apache/polaris-helm-chart
> > >> >> > > > >>
> > >> >> > > > >> Cheers,
> > >> >> > > > >> Dmitri.
> > >> >> > > > >>
> > >> >> > > > >> On Mon, Jul 14, 2025 at 8:02 AM Jean-Baptiste Onofré <
> > >> >> > j...@nanthrax.net
> > >> >> > > >
> > >> >> > > > >> wrote:
> > >> >> > > > >>
> > >> >> > > > >> > Hi
> > >> >> > > > >> >
> > >> >> > > > >> > I'm fine having a dedicated repo for helm chart, it all
> depends on
> > >> >> > > > >> > what we want to release:
> > >> >> > > > >> > 1. If we just want to release helm charts "package",
> then helm
> > >> >> > > charts
> > >> >> > > > >> > can stay in the polaris repo (as so part of the source
> > >> >> > distribution)
> > >> >> > > > >> > 2. if we want to release a complete different source
> distribution
> > >> >> > > and
> > >> >> > > > >> > package for Helm Charts, then we can have a complete
> separate
> > >> >> > > > >> > repository.
> > >> >> > > > >> >
> > >> >> > > > >> > Apache projects use both. For instance, Airflow is
> using (1),
> > >> >> > > whereas
> > >> >> > > > >> > Pulsar or Ozone are using (2).
> > >> >> > > > >> >
> > >> >> > > > >> > If we have a consensus for a separate repo, I would
> suggest
> > >> >> > > > >> > apache/polaris-helm-chart repository. I can create.
> > >> >> > > > >> >
> > >> >> > > > >> > Regards
> > >> >> > > > >> > JB
> > >> >> > > > >> >
> > >> >> > > > >> > On Mon, Jul 14, 2025 at 1:25 PM Alexandre Dutra <
> > >> >> > adu...@apache.org>
> > >> >> > > > >> wrote:
> > >> >> > > > >> > >
> > >> >> > > > >> > > Hi all,
> > >> >> > > > >> > >
> > >> >> > > > >> > > For reference and completeness, this has also been
> previously
> > >> >> > > > >> > > discussed in a much older thread:
> > >> >> > > > >> > >
> > >> >> > https://lists.apache.org/thread/428xb6dfrmm7xgr91p2dxoy8ptcyovs2
> > >> >> > > > >> > >
> > >> >> > > > >> > > So far the consensus was, as Yufei pointed out, to
> release the
> > >> >> > > Helm
> > >> >> > > > >> > > chart along with the Polaris server release (+docker
> images,
> > >> >> > > etc.) –
> > >> >> > > > >> > > mostly for the sake of simplicity.
> > >> >> > > > >> > >
> > >> >> > > > >> > > I confess I'm torn on the idea of separate releases
> and/or
> > >> >> > moving
> > >> >> > > > the
> > >> >> > > > >> > > chart to the polaris-tools repo. I fear that the
> chart could
> > >> >> > > quickly
> > >> >> > > > >> > > lag behind Polaris itself, especially when
> configuration options
> > >> >> > > > >> > > change.
> > >> >> > > > >> > >
> > >> >> > > > >> > > But if that is now the preferred option, I'm fine
> with that.
> > >> >> > > > >> > >
> > >> >> > > > >> > > Thanks,
> > >> >> > > > >> > > Alex
> > >> >> > > > >> > >
> > >> >> > > > >> > >
> > >> >> > > > >> > > On Sun, Jul 13, 2025 at 5:27 AM Yong Zheng <
> yzh...@apache.org>
> > >> >> > > > wrote:
> > >> >> > > > >> > > >
> > >> >> > > > >> > > > I also likes the idea of moving the chart to a
> different repo
> > >> >> > > > (some
> > >> >> > > > >> > obvious downsize are we will need to move some work
> around and
> > >> >> > > > duplicate
> > >> >> > > > >> > some build pipeline etc.). Also, another thing we will
> loss is the
> > >> >> > > > >> > published helm doc (assuming we still want it,
> otherwise, just ask
> > >> >> > > > >> people
> > >> >> > > > >> > to get the info from README.md from git repo). Other
> than these, I
> > >> >> > > > don't
> > >> >> > > > >> > have a concern.
> > >> >> > > > >> > > >
> > >> >> > > > >> > > > On 2025/07/12 11:21:53 Robert Stupp wrote:
> > >> >> > > > >> > > > > If the consensus is to have a different release
> cadences for
> > >> >> > > the
> > >> >> > > > >> > > > > Polars helm chart and Polaris "server", I propose
> to move
> > >> >> > the
> > >> >> > > > helm
> > >> >> > > > >> > > > > charts to polaris-tools. One difference between
> the two
> > >> >> > repos
> > >> >> > > is
> > >> >> > > > >> that
> > >> >> > > > >> > > > > the "main" repo eventually gets (semi) automatic
> releases
> > >> >> > that
> > >> >> > > > >> might
> > >> >> > > > >> > > > > get confused with rather manually driven
> helm-chart releases
> > >> >> > > (it
> > >> >> > > > >> will
> > >> >> > > > >> > > > > have to use and check against Git tags and
> potentially
> > >> >> > version
> > >> >> > > > >> > > > > branches). Therefore the polaris-tools repo
> sounds more
> > >> >> > > > >> appropriate,
> > >> >> > > > >> > > > > because there are already multiple "sub projects".
> > >> >> > > > >> > > > >
> > >> >> > > > >> > > > > Another reason to move the helm-charts to
> polaris-tools is
> > >> >> > > that
> > >> >> > > > >> the
> > >> >> > > > >> > > > > helm-charts, if released independently, become
> suitable for
> > >> >> > > > >> multiple
> > >> >> > > > >> > > > > Polaris versions, which requires tests/CI against
> multiple
> > >> >> > > > Polaris
> > >> >> > > > >> > > > > versions. Letting pretty much every change to the
> "main"
> > >> >> > > > >> repository
> > >> >> > > > >> > > > > trigger CI for a potentially big
> helm-chart/Polaris
> > >> >> > > test-matrix
> > >> >> > > > >> seems
> > >> >> > > > >> > > > > to be an unnecessary waste of CI time. In
> polaris-tools, all
> > >> >> > > CI
> > >> >> > > > >> jobs
> > >> >> > > > >> > > > > are "scoped" to a particular "root path".
> > >> >> > > > >> > > > >
> > >> >> > > > >> > > > > Different release cadences also mean to maintain a
> > >> >> > > > "compatibility
> > >> >> > > > >> > > > > matrix", not immediately, but in the (near?)
> future.
> > >> >> > > > >> > > > >
> > >> >> > > > >> > > > > Thoughts?
> > >> >> > > > >> > > > >
> > >> >> > > > >> > > > > On Sat, Jul 12, 2025 at 9:08 AM Yufei Gu <
> > >> >> > > flyrain...@gmail.com>
> > >> >> > > > >> > wrote:
> > >> >> > > > >> > > > > >
> > >> >> > > > >> > > > > > Sounds good. I think Apache Airflow did the
> exact same
> > >> >> > thing
> > >> >> > > > by
> > >> >> > > > >> > publishing
> > >> >> > > > >> > > > > > both Helm Chart source and Helm Chart binary
> package. We
> > >> >> > > still
> > >> >> > > > >> > need to
> > >> >> > > > >> > > > > > figure out a few things:
> > >> >> > > > >> > > > > > 1. What does the Helm Chart version look like?
> > >> >> > > > >> > > > > > 2. Publishing a version map between Helm Chart
> and Polaris
> > >> >> > > > >> server
> > >> >> > > > >> > as the
> > >> >> > > > >> > > > > > part of Helm Chart doc. For example, Helm Chart
> version
> > >> >> > > 1.2.0
> > >> >> > > > >> > works with
> > >> >> > > > >> > > > > > Polaris server 0.9.0, 1.0.0, and 1.1.0.
> > >> >> > > > >> > > > > > 3. What's the default docker image tag? I'd
> suggest using
> > >> >> > > the
> > >> >> > > > >> > latest
> > >> >> > > > >> > > > > > Polaris release version(e.g., 1.0.0-incubating)
> at the
> > >> >> > time
> > >> >> > > > the
> > >> >> > > > >> > Helm Chart
> > >> >> > > > >> > > > > > was published.
> > >> >> > > > >> > > > > > 4. Location would be easy to decide, we can
> continue to
> > >> >> > > > publish
> > >> >> > > > >> it
> > >> >> > > > >> > to
> > >> >> > > > >> > > > > > dist.apache.org as 1.0.0-incubating did.
> > >> >> > > > >> > > > > >
> > >> >> > > > >> > > > > > If we decide to release the Helm chart on its
> own cadence,
> > >> >> > > we
> > >> >> > > > >> > don't need a
> > >> >> > > > >> > > > > > nightly Helm Chart release at this time.
> > >> >> > > > >> > > > > >
> > >> >> > > > >> > > > > > Yufei
> > >> >> > > > >> > > > > >
> > >> >> > > > >> > > > > >
> > >> >> > > > >> > > > > > On Fri, Jul 11, 2025 at 11:32 PM Jean-Baptiste
> Onofré <
> > >> >> > > > >> > j...@nanthrax.net>
> > >> >> > > > >> > > > > > wrote:
> > >> >> > > > >> > > > > >
> > >> >> > > > >> > > > > > > Hi
> > >> >> > > > >> > > > > > >
> > >> >> > > > >> > > > > > > It's not a problem for me to release "part"
> of Polaris
> > >> >> > > like
> > >> >> > > > >> Helm
> > >> >> > > > >> > chart.
> > >> >> > > > >> > > > > > >
> > >> >> > > > >> > > > > > > However, the release has to be "ASF valid",
> meaning that
> > >> >> > > the
> > >> >> > > > >> > release
> > >> >> > > > >> > > > > > > needs to include source distribution. Today,
> we don't
> > >> >> > have
> > >> >> > > > >> source
> > >> >> > > > >> > > > > > > distribution only for Helm chart (it's global
> source
> > >> >> > > > >> distribution
> > >> >> > > > >> > > > > > > including Helm sources).
> > >> >> > > > >> > > > > > > So, I propose to include a source tar gradle
> task in
> > >> >> > Helm
> > >> >> > > > >> chart
> > >> >> > > > >> > (with
> > >> >> > > > >> > > > > > > signing and checksum). If we do that, no
> problem. I can
> > >> >> > > > take a
> > >> >> > > > >> > crack
> > >> >> > > > >> > > > > > > on this :)
> > >> >> > > > >> > > > > > >
> > >> >> > > > >> > > > > > > Regards
> > >> >> > > > >> > > > > > > JB
> > >> >> > > > >> > > > > > >
> > >> >> > > > >> > > > > > > On Sat, Jul 12, 2025 at 1:30 AM Yufei Gu <
> > >> >> > > > >> flyrain...@gmail.com>
> > >> >> > > > >> > wrote:
> > >> >> > > > >> > > > > > > >
> > >> >> > > > >> > > > > > > > Hi everyone,
> > >> >> > > > >> > > > > > > >
> > >> >> > > > >> > > > > > > > While testing the freshly-minted
> 1.0.0-incubating
> > >> >> > > release,
> > >> >> > > > >> we
> > >> >> > > > >> > noticed
> > >> >> > > > >> > > > > > > > something odd: the Polaris release has
> relational-jdbc
> > >> >> > > > >> > persistence, yet
> > >> >> > > > >> > > > > > > the
> > >> >> > > > >> > > > > > > > Helm chart only understands the legacy
> eclipselink.
> > >> >> > Here
> > >> >> > > > is
> > >> >> > > > >> > the issue:
> > >> >> > > > >> > > > > > > >
> https://github.com/apache/polaris/issues/2030.
> > >> >> > > > >> > > > > > > >
> > >> >> > > > >> > > > > > > > We previously made the decision to publish
> Helm Chart
> > >> >> > > with
> > >> >> > > > >> > Polaris src
> > >> >> > > > >> > > > > > > and
> > >> >> > > > >> > > > > > > > bin, check the ML thread:
> > >> >> > > > >> > > > > > > >
> > >> >> > > > >> >
> https://lists.apache.org/thread/d1vf7xpn6nkzp8gbh417m8qb58tkpcqz.
> > >> >> > > We
> > >> >> > > > >> may
> > >> >> > > > >> > > > > > > > revisit the approach. I think it makes more
> sense to
> > >> >> > > > release
> > >> >> > > > >> > the Helm
> > >> >> > > > >> > > > > > > chart
> > >> >> > > > >> > > > > > > > on its own cadence. Not all Polaris users
> need Helm
> > >> >> > > > charts,
> > >> >> > > > >> > plus Helm
> > >> >> > > > >> > > > > > > chart
> > >> >> > > > >> > > > > > > > tweaking happens commonly between Polaris
> server
> > >> >> > > releases.
> > >> >> > > > >> > WDYT?
> > >> >> > > > >> > > > > > > >
> > >> >> > > > >> > > > > > > > Meanwhile, we can start to release the
> nightly Helm
> > >> >> > > Chart
> > >> >> > > > >> as a
> > >> >> > > > >> > quick
> > >> >> > > > >> > > > > > > > solution for any users trying the new
> release with
> > >> >> > JDBC
> > >> >> > > > >> > backend. Thoughts
> > >> >> > > > >> > > > > > > > and volunteers for this one?
> > >> >> > > > >> > > > > > > >
> > >> >> > > > >> > > > > > > > Yufei
> > >> >> > > > >> > > > > > >
> > >> >> > > > >> > > > >
> > >> >> > > > >> >
> > >> >> > > > >>
> > >> >> > > > >
> > >> >> > > >
> > >> >> > >
> > >> >> >
>
