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 <[email protected]>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: [email protected] > > To: [email protected] > > > > My comments are below. > > > > > > On Thu, Mar 20, 2014 at 3:05 PM, Srikanth Sundarrajan > > <[email protected]>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: [email protected] > >>> To: [email protected] > >>> > >>> 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 > >>> <[email protected]>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: [email protected] > >>>>> To: [email protected] > >>>>> 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é > >>>>> [email protected] > >>>>> 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
