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
> >> >> > > > >> > > > > > >
> >> >> > > > >> > > > >
> >> >> > > > >> >
> >> >> > > > >>
> >> >> > > > >
> >> >> > > >
> >> >> > >
> >> >> >
