If we want to implement the feature flag, we need to figure out how to map
the old timezone names to the IANA names.
The timezone mappings that are in use in 3.0 are not always sensible and
sometimes they are downright misleading. This stems from the issues
surrounding the current implementation of the timezone lookup function
(TimezoneDatabase::FindTimezone()). These issues are described in detail in
IMPALA-5563.
For instance, the lookup function currently interprets "CEST" as an alias
for "Africa/Ceuta". Since "CEST" stands for "Central European Summer Time",
I imagine users would expect to get "CET" ("Central Europian Time")
timezone or the timezone of some Central European city instead (e.g.
Europe/Paris or Europe/Budapest). Note, that although all these timezones
use the same DST offset they are different timezones with different rules.
So which mapping should we use when the feature flag is set? I don't think
there is a good answer here. Whichever mapping we choose, chances are users
won't be happy with it and we would have to change it later.
In summary. instead of trying to hard-code the 3.0 mappings (including the
ambiguous/misleading ones) under a feature flag, I think it would make more
sense to provide users with a config file that contains most legacy
timezone names with some sensible mappings. Users can start with that and
then remove/add/modify timezone mappings as they see fit. I think this way
we could avoid a lot of confusion
On Wed, Jun 13, 2018 at 8:03 PM, Jim Apple <jbap...@cloudera.com.invalid>
wrote:
> Can you elaborate on the maintenance required if there were a feature flag?
>
> On Wed, Jun 13, 2018 at 9:05 AM, Attila Jeges <atti...@cloudera.com>
> wrote:
>
> > I agree with Quanlong that we can mark 3.0 as experimental and introduce
> > IMPALA-3307 in 3.1.
> >
> > Adding a feature flag to switch back and forth between the legacy
> timezone
> > names and the new timezone names is certainly possible, although I think
> > maintaining and testing the flag would be too much of a trouble.
> >
> > To help users who want to keep the old timezone names, we can create a
> > config file that contains the definitions for all the legacy names and
> link
> > it from the online documentation. Users then can download the config file
> > and add the legacy names to Impala with the --hdfs_zone_alias_conf flag.
> >
> > On Wed, Jun 13, 2018 at 6:51 AM, Quanlong Huang <huang_quanl...@126.com>
> > wrote:
> >
> > > The problem is that we've released 3.0, otherwise, we can just add it
> in
> > > 3.0 branch.
> > >
> > >
> > > From the user perspective, I agree with merging it with feature flags
> in
> > > 3.x, though I agree with "Breaking changes must bump the major
> version".
> > I
> > > believe no one in the industry has deployed impala-3.0 in production,
> so
> > > actually, if we add it in 3.1, no one is broke. We can mark that 3.0 is
> > > experimental and not recommended to use when we release 3.1. In the
> other
> > > side, if hopefully this feature has a workaround or feature flag, it
> > > shouldn't be considered as "breaking".
> > >
> > >
> > > It's too early to have a 4.x branch. I can't imagine that we maintain
> > 2.x,
> > > 3.x, 4.x and maybe 5.x (for future breaking changes) together when the
> > > majority of the community is still using 2.x branch.
> > > Quanlong
> > >
> > >
> > > At 2018-06-13 06:04:10, "Philip Zeyliger" <phi...@cloudera.com> wrote:
> > > >On Mon, Jun 11, 2018 at 2:49 PM Jim Apple <jbap...@cloudera.com>
> wrote:
> > > >
> > > >> Phil, if Jeszy's solution is possible (feature flag, off by default
> in
> > > the
> > > >> 3.x line), would that align with your preference?
> > > >>
> > > >
> > > >I'd be fine with "feature flag, 3.x." I'd also be fine with "no
> feature
> > > >flag, 3.x" and "4.x".
> > > >
> > > >-- Philip
> > > >
> > > >
> > > >> On Mon, Jun 11, 2018 at 2:29 PM, Taras Bobrovytsky <
> > taras...@apache.org
> > > >
> > > >> wrote:
> > > >>
> > > >> > I agree with Jim. It would be better to bump to 4.0 in my opinion.
> > We
> > > >> > should follow the simple rule: Breaking changes must bump the
> major
> > > >> version
> > > >> > number.
> > > >> >
> > > >> > On Mon, Jun 11, 2018 at 2:17 PM, Jeszy <jes...@gmail.com> wrote:
> > > >> >
> > > >> > > My assumption was that the workaround Phil mentioned must be
> > simple
> > > to
> > > >> > > toggle (e.g. flag). If it's not, it probably shouldn't be
> > > considered a
> > > >> > > viable workaround.
> > > >> > >
> > > >> > > On 11 June 2018 at 10:42, Jim Apple <jbap...@cloudera.com>
> wrote:
> > > >> > >
> > > >> > > > Csaba, is that possible with th change similar to how it is
> now,
> > > or
> > > >> > would
> > > >> > > > it have to be rewritten?
> > > >> > > >
> > > >> > > > On Mon, Jun 11, 2018 at 1:30 AM Jeszy <jes...@gmail.com>
> wrote:
> > > >> > > >
> > > >> > > > > I think we should include it in 3.1, with the feature
> disabled
> > > by
> > > >> > > default
> > > >> > > > > (to not break on a minor upgrade), but recommend enabling it
> > in
> > > >> docs
> > > >> > > and
> > > >> > > > > make it enabled by default in 4.0.
> > > >> > > > >
> > > >> > > > > On 11 June 2018 at 10:23, Jim Apple <jbap...@cloudera.com>
> > > wrote:
> > > >> > > > >
> > > >> > > > > > Any more thoughts? This question is for everyone in the
> > Impala
> > > >> > > > community.
> > > >> > > > > >
> > > >> > > > > > Right now the plan is to fold it into 3.1, with two to one
> > in
> > > >> favor
> > > >> > > of
> > > >> > > > > that
> > > >> > > > > > over bumping to 4.0.
> > > >> > > > > >
> > > >> > > > > > On Mon, Jun 4, 2018 at 8:48 PM Jim Apple <
> > > jbap...@cloudera.com>
> > > >> > > wrote:
> > > >> > > > > >
> > > >> > > > > > > I am more in favor of bumping to 4.0. It is a rapid
> > > escalation,
> > > >> > but
> > > >> > > > we
> > > >> > > > > > > wouldn’t be the first open source project to switch to a
> > > model
> > > >> > with
> > > >> > > > > Short
> > > >> > > > > > > major versions, as both Clang and Firefox have done so.
> > > >> > > > > > >
> > > >> > > > > > > I also feel that, both from a semver perspective and as
> a
> > > user
> > > >> of
> > > >> > > > other
> > > >> > > > > > > software, I expect breaking changes to bump the major
> > > version
> > > >> > > number.
> > > >> > > > > > >
> > > >> > > > > > > That said, this is not a hill I’m trying to die on. My
> > > focus is
> > > >> > on
> > > >> > > > the
> > > >> > > > > > > user experience, and if our users end up well informed
> of
> > > the
> > > >> > > > > breakages,
> > > >> > > > > > > then I will feel we have done our job, no matter what
> > > version
> > > >> > > number
> > > >> > > > we
> > > >> > > > > > > stamp on it.
> > > >> > > > > > >
> > > >> > > > > > > On Mon, Jun 4, 2018 at 7:57 PM Philip Zeyliger <
> > > >> > > phi...@cloudera.com>
> > > >> > > > > > > wrote:
> > > >> > > > > > >
> > > >> > > > > > >> Hi Csaba!
> > > >> > > > > > >>
> > > >> > > > > > >> I would be fine with both proposals, with a slight
> > > preference
> > > >> to
> > > >> > > B.
> > > >> > > > My
> > > >> > > > > > >> understanding is that you're going to expose a way to
> > > define
> > > >> > > > overrides
> > > >> > > > > > for
> > > >> > > > > > >> time zone definitions, so there will be pretty workable
> > > >> > > workarounds
> > > >> > > > > too.
> > > >> > > > > > >>
> > > >> > > > > > >> -- Philip
> > > >> > > > > > >>
> > > >> > > > > > >> On Mon, Jun 4, 2018 at 1:45 PM, Csaba Ringhofer <
> > > >> > > > > > csringho...@cloudera.com
> > > >> > > > > > >> >
> > > >> > > > > > >> wrote:
> > > >> > > > > > >>
> > > >> > > > > > >> > Hi Folks!
> > > >> > > > > > >> >
> > > >> > > > > > >> > We had a discussion with a few people about the
> > > versioning
> > > >> of
> > > >> > > > > Impala
> > > >> > > > > > >> after
> > > >> > > > > > >> > 3.0. The motivation was that IMPALA-3307 (which
> > replaces
> > > the
> > > >> > > > > timezone
> > > >> > > > > > >> > implementation in Impala, and contains some breaking
> > > >> changes)
> > > >> > > > missed
> > > >> > > > > > 3.0
> > > >> > > > > > >> > and we are not sure about the version in which it can
> > be
> > > >> > > released
> > > >> > > > -
> > > >> > > > > is
> > > >> > > > > > >> it
> > > >> > > > > > >> > 3.1 or 4.0?
> > > >> > > > > > >> >
> > > >> > > > > > >> > A. jumping to 4.0 would communicate clearly that the
> > > release
> > > >> > > > > contains
> > > >> > > > > > >> > braking changes - if the plan for Impala is to follow
> > > >> semantic
> > > >> > > > > > >> versioning,
> > > >> > > > > > >> > than this is the way to go
> > > >> > > > > > >> >
> > > >> > > > > > >> > B. releasing it in 3.1 would communicate that the
> > change
> > > is
> > > >> > too
> > > >> > > > > small
> > > >> > > > > > >> for a
> > > >> > > > > > >> > major version bump, and major versions are kept for
> BIG
> > > >> > changes
> > > >> > > in
> > > >> > > > > > >> Impala
> > > >> > > > > > >> >
> > > >> > > > > > >> > My personal preference is for B - if a breaking
> change
> > is
> > > >> > > > relatively
> > > >> > > > > > >> small
> > > >> > > > > > >> > and workarounds are possible + the community agrees,
> > > then it
> > > >> > > > should
> > > >> > > > > be
> > > >> > > > > > >> > possible to release it in minor a version, while
> major
> > > >> > versions
> > > >> > > > > could
> > > >> > > > > > be
> > > >> > > > > > >> > kept for changes where switching Impala version needs
> > > large
> > > >> > > effort
> > > >> > > > > on
> > > >> > > > > > >> the
> > > >> > > > > > >> > user's side (for example 2->3 jump needs new Java and
> > > Hadoop
> > > >> > > major
> > > >> > > > > > >> > version), or when a huge improvement is added to
> Impala
> > > >> which
> > > >> > > > > deserves
> > > >> > > > > > >> > extra attention. This is more of an aesthetic than a
> > > >> rational
> > > >> > > > choice
> > > >> > > > > > on
> > > >> > > > > > >> my
> > > >> > > > > > >> > side, so I am totally ok with semantic versioning
> too,
> > if
> > > >> the
> > > >> > > > > > community
> > > >> > > > > > >> > prefers it.
> > > >> > > > > > >> >
> > > >> > > > > > >>
> > > >> > > > > > >
> > > >> > > > > >
> > > >> > > > >
> > > >> > > >
> > > >> > >
> > > >> >
> > > >>
> > >
> >
>
