falcon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Seetharam Venkatesh <venkat...@innerzeal.com>
Subject Re: [DISCUSS] falcon 0.5 release
Date Sat, 22 Mar 2014 05:20:50 GMT
Let me explain with a few examples of what I meant.

* security - does not touch the critical parts of code, can be turned off
easily with minor change to the Authentication Filter
* lineage - an independent service, can be turned off and does not touch
critical parts of code
* pipeline designer
* dashboard
* file based ingest - assuming it is independent workflow and mapping code
* etc.

However there are exceptions which we need to decide on a case-by-case
basis.
* Hive integration - this changed the critical parts of the code and I did
wait until we ran thru regression before even committing this, forget about
a release. It was far from it.
* Storm integration - may be
* etc.

Lets have an open mind, look at features on a case-by-case basis and have a
regular release cadence.

Makes sense?


On Fri, Mar 21, 2014 at 6:48 PM, Srikanth Sundarrajan
<sriksun@hotmail.com>wrote:

> I am not too sure if I understand this well enough.
>
> "We need to accommodate features that are not stable and well tested as
> part of a regular release, mark 'em as such so users are aware of whats
> stable and whats not."
>
> If new features are not well tested, but they are touching areas of code
> that are considered stable, how do we ensure there are no regressions on
> those existing features without at least testing the newly added code paths
> introduced by the new features.
>
> Am I missing something that is seemingly obvious?
>
> Regards
> Srikanth Sundarrajan
>
> ----------------------------------------
> > Date: Fri, 21 Mar 2014 14:07:24 -0700
> > Subject: Re: [DISCUSS] falcon 0.5 release
> > From: venkatesh@innerzeal.com
> > To: dev@falcon.incubator.apache.org
> >
> > My comments are below.
> >
> >
> > On Thu, Mar 20, 2014 at 3:05 PM, Srikanth Sundarrajan
> > <sriksun@hotmail.com>wrote:
> >
> >> I guess the larger question is do we want to have a multiple release
> line
> >> at different levels of maturity, if so what are the best practices here
> and
> >> how can we adopt them.
> >
> > I'm NOT talking about releases at different levels of maturity. I think
> > this is a complete disaster for users as it can be quite confusing.
> >
> > Again, to reiterate what I was saying: "We need to accommodate features
> > that are not stable and well tested as part of a regular release, mark
> 'em
> > as such so users are aware of whats stable and whats not."
> >
> > Am I clear?
> >
> >
> >> Perhaps we can study some of the projects and figure what works best for
> >> us.
> >>
> > There is no need IMO.
> >
> >
> >>
> >> There are bug fixes and new features being added simultaneously and
> there
> >> ought to be frequent releases to stable version with bug fixes to help
> >> users who use the software in production system. Similarly there may be
> >> users who are waiting on new features, but aren't concerned about the
> >> stability of the software and are largely in test deployments.
> >>
> >
> > This is exactly my point. We need to establish a regular release cadence
> so
> > users can expect a release on a set cycle with clarity in release notes
> > saying which features are stable, new and experimental, alpha, etc. A
> > feature will NOT get stable in a single release but will take at least 2
> > cycles. This is how Flume works.
> >
> > Makes sense?
> >
> >
> >>
> >> My initial thoughts: We can branch out stable line and make stable
> >> releases from this branch and release alpha-versions from trunk. But
> having
> >> more than 2 release lines is going to be quite burdensome.
> >
> > This is bad and confusing. Lets not do this.
> >
> >
> >> At some point there has got to be enough work done before the old stable
> >> line is closed and trunk is promoted as the new stable line. Assuming
> 0.5
> >> is released as alpha, before we add more features there has to be an
> effort
> >> to move 0.5 to beta quality (let us call this 0.6) and then branch out
> post
> >> 0.6 to have stable releases out of this (0.6.1). So between 0.5 and
> 0.6.1
> >> new feature releases are a burden.
> >>
> >> Since we released 0.4, we haven't done much to mature the features added
> >> there and hence the suggestion to defer 0.5.
> >
> > I humbly disagree. There has been innumerous bugs fixed since then and
> some
> > are critical.
> >
> > BTW, the larger question is also to establish a release cadence, monthly,
> > once in 2 months, quarterly, etc. We can have an exception but we now can
> > communicate to users to expect a release regularly.
> >
> >
> >> If there is push from the users needing new features added since 0.4
> >> packaged in a release, we can proceed with 0.5. But I feel that we
> ought to
> >> mature features that have already been added and have these rolling out
> in
> >> frequent releases to allow users to use these features in production
> >> deployments.
> >>
> > Hive was added in 0.4. Until we get to 0.6, Hive will not be mature and
> > must not be used in Production. Lets allow atleast 2 release cycles
> before
> > marking it as stable and we can measure it based on Merlin coverage as
> well
> > once it gets folded into apache.
> >
> >
> >>
> >> Regards
> >> Srikanth Sundarrajan
> >>
> >>> Date: Thu, 20 Mar 2014 09:57:31 -0700
> >>> Subject: Re: [DISCUSS] falcon 0.5 release
> >>> From: venkatesh@innerzeal.com
> >>> To: dev@falcon.incubator.apache.org
> >>>
> >>> HCat was not tested with dated sub partitions. Having a fix for these
> is
> >> a
> >>> good idea but there is a dependency on Oozie for this and not sure how
> >> this
> >>> plays out. The retention already has a patch and will review/commit it
> >> this
> >>> week.
> >>>
> >>> What else is open wrt stability. There will be bugs and holding off a
> >>> release calling out experimental features unstable is not a good
> thing. I
> >>> also wanted to start a discuss thread to explore ideas to see how we
> can
> >>> make adding new features a breeze and mark 'em as experimental. These
> >>> features should take couple of release cycles to bake in and will be
> >> marked
> >>> Beta/GA to be used in production.
> >>>
> >>> In that light, you could release a 0.4.1 stable version but I can go
> >> ahead
> >>> and make a 0.5 - experimental release with new features for users to
> play
> >>> with. Lineage is not fully baked. Security for a large part has been
> >> tested
> >>> but can be marked beta.
> >>>
> >>> Thoughts?
> >>>
> >>>
> >>>
> >>>
> >>> On Wed, Mar 19, 2014 at 2:30 AM, Srikanth Sundarrajan
> >>> <sriksun@hotmail.com>wrote:
> >>>
> >>>> Was seriously contemplating a 0.4.1 stability release over the next
> 3-4
> >>>> weeks as 0.4 has many bugs particularly with respect to the hcat
> >>>> replication and retention feature involving multiple partitions. Does
> it
> >>>> make sense to hold off on 0.5 till End of Apr ?
> >>>> RegardsSrikanth Sundarrajan
> >>>>
> >>>>> Date: Wed, 19 Mar 2014 07:00:53 +0100
> >>>>> From: jb@nanthrax.net
> >>>>> To: dev@falcon.incubator.apache.org
> >>>>> Subject: Re: [DISCUSS] falcon 0.5 release
> >>>>>
> >>>>> Hi Venkatesh,
> >>>>>
> >>>>> on my side, I should be able to submit new patches proposal soon
> (next
> >>>>> week max).
> >>>>>
> >>>>> So, no problem for EOM release for me.
> >>>>>
> >>>>> Thanks,
> >>>>> Regards
> >>>>> JB
> >>>>>
> >>>>> On 03/19/2014 06:58 AM, Seetharam Venkatesh wrote:
> >>>>>> Hey folks,
> >>>>>>
> >>>>>> We have made significant progress in falcon with security and
> lineage
> >>>> apart
> >>>>>> from the many bug fixes. Should we have a release by EOM?
> >>>>>>
> >>>>>
> >>>>> --
> >>>>> Jean-Baptiste Onofré
> >>>>> jbonofre@apache.org
> >>>>> http://blog.nanthrax.net
> >>>>> Talend - http://www.talend.com
> >>>>
> >>>>
> >>>
> >>>
> >>>
> >>> --
> >>> Regards,
> >>> Venkatesh
> >>>
> >>> "Perfection (in design) is achieved not when there is nothing more to
> >> add,
> >>> but rather when there is nothing more to take away."
> >>> - Antoine de Saint-Exupéry
> >>
> >
> >
> >
> > --
> > Regards,
> > Venkatesh
> >
> > "Perfection (in design) is achieved not when there is nothing more to
> add,
> > but rather when there is nothing more to take away."
> > - Antoine de Saint-Exupéry
>



-- 
Regards,
Venkatesh

"Perfection (in design) is achieved not when there is nothing more to add,
but rather when there is nothing more to take away."
- Antoine de Saint-Exupéry

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message