nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Oleg Zhurakousky <ozhurakou...@hortonworks.com>
Subject Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0
Date Wed, 01 Jun 2016 12:37:16 GMT
Yes, it's on my list for 1.0

Oleg

> On Jun 1, 2016, at 08:33, Joe Witt <joe.witt@gmail.com> wrote:
> 
> I had an off-list conversation with OlegZ about this recently and he
> said he planned on trying to tackle this for 1.x timing.  Oleg - you
> have any updates you can share on the JIRA?
> 
> It is definitely an important item for those that want to do effective
> CM which is diff friendly.  Is just a step of many we should take to
> make the whole dev/ops lifecycle for a flow as good as possible.
> 
>> On Wed, Jun 1, 2016 at 8:28 AM, Edgardo Vega <edgardo.vega@gmail.com> wrote:
>> What ever happened to the following from the 6-12 month roadmap that was
>> posted a while ago?
>> 
>> Deterministic Template Export
>>    https://issues.apache.org/jira/browse/NIFI-826
>> 
>>> On Tue, May 31, 2016 at 10:07 PM, Joe Witt <joe.witt@gmail.com> wrote:
>>> 
>>> I'll take release manager duties for 0.7.0 unless someone else with
>>> committer status really wants to give it a go.
>>> 
>>> Right now there are 43 tickets assigned to it.  I'll go through and
>>> punt ones on there that seem stalled or deferrable.  Of course, if
>>> there are any that are particularly important to something you might
>>> need please do comment to that effect.  As we close down on number of
>>> 0.7 tickets I'll kick off the proceedings.
>>> 
>>> https://issues.apache.org/jira/browse/NIFI/fixforversion/12335078
>>> 
>>> Thanks
>>> Joe
>>> 
>>> On Tue, May 31, 2016 at 10:00 PM, Ryan H <rhendrickson.work@gmail.com>
>>> wrote:
>>>> Also looking forward to using the TransformJSON processor:
>>> https://github.com/apache/nifi/blob/master/nifi-nar-bundles/nifi-standard-bundle/nifi-standard-processors/src/main/java/org/apache/nifi/processors/standard/TransformJSON.java
>>>> 
>>>> Nice choice with JOLT there.
>>>> 
>>>> We're doing a custom one for jolt transformers for that now.
>>>> 
>>>> Ryan
>>>> 
>>>> On Fri, May 27, 2016 at 11:21 AM, Ryan H <rhendrickson.work@gmail.com>
>>>> wrote:
>>>> 
>>>>> I'm looking forward to 0.7.. Plenty of awesome features, like SSL with
>>> the
>>>>> AMQP processors (https://issues.apache.org/jira/browse/NIFI-1521)
>>>>> 
>>>>> Thanks!
>>>>> 
>>>>>> On Thu, May 26, 2016 at 7:52 AM, Joe Witt <joe.witt@gmail.com>
wrote:
>>>>>> 
>>>>>> Ok just to wrap up this thread. Will push a couple efforts
>>>>>> 1) Will start pulling together an 0.7 release
>>>>>> 2) Will update the roadmap slide to put in tentative timing/major
>>>>>> elements in the roadmap on the wiki page
>>>>>> 
>>>>>> And as for whether 0.7 ends up being the last release of the 0.x
line
>>>>>> will just depend on 1.0 release timing and community interest in
doing
>>>>>> an 0.8.  We don't have to decide that now.
>>>>>> 
>>>>>> Thanks
>>>>>> Joe
>>>>>> 
>>>>>> On Tue, May 17, 2016 at 7:12 PM, Andy LoPresto <alopresto@apache.org>
>>>>>> wrote:
>>>>>>> I think Mike’s read on the published guidelines is correct,
but I
>>> agree
>>>>>> with
>>>>>>> Joe that if we release 0.7 two weeks before 1.0, feature development
>>>>>> that is
>>>>>>> merged after 0.7 does not need to be backported. Maybe this is
>>>>>> something we
>>>>>>> should clarify on the wiki once we reach a consensus.
>>>>>>> 
>>>>>>> 
>>>>>>> Andy LoPresto
>>>>>>> alopresto@apache.org
>>>>>>> alopresto.apache@gmail.com
>>>>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D
EF69
>>>>>>> 
>>>>>>> On May 17, 2016, at 3:43 PM, Joe Witt <joe.witt@gmail.com>
wrote:
>>>>>>> 
>>>>>>> Mike
>>>>>>> 
>>>>>>> I agree with the letter of the reading so this thread is to discuss
>>>>>>> the spirit of it and how to best apply it to our situation and
>>>>>>> community now.  Whether it is 'just before' or 'just after' or
'same
>>>>>>> time' I think it is within the intent.  I just want us to be
clear
>>>>>>> what it is.  It is extra work to ensure each PR is applied to
both
>>>>>>> lines and extra work increases contributor and reviewer burden
so we
>>>>>>> should be mindful of that as it is a dragging force.  We also
need to
>>>>>>> keep in mind that with 1.x we have Java 8 as a minimum and so
there
>>>>>>> are cases which will not apply to both and we don't want folks
to
>>>>>>> avoid using Java 8 features just so it can apply to both.
>>>>>>> 
>>>>>>> My preference is that we have 0.7 as the last planned feature
release
>>>>>>> in 0.x and with that in mind we need to choose to have it be
a bit
>>>>>>> before, a bit after, or at the same time as the 1.x release.
 I
>>>>>>> personally am comfortable with what I proposed for 0.7 vs 1.0
timing
>>>>>>> but I am fine if the consensus is to release the last 0.x and
1.0 at
>>>>>>> the same time.  Just hoping to avoid needing to have another
feature
>>>>>>> release on 0.x after 0.7 other than some special request that
might
>>>>>>> come up later (which is also discussed in the support doc).
>>>>>>> 
>>>>>>> I also agree the release process for 1.0 will be significant
as it
>>>>>>> will include important new features.  Definitely need folks testing
>>>>>>> out and providing feedback on the features early and often.
>>>>>>> 
>>>>>>> Thanks
>>>>>>> Joe
>>>>>>> 
>>>>>>>> On Tue, May 17, 2016 at 6:20 PM, Michael Moser <moser.mw@gmail.com>
>>>>>>> wrote:
>>>>>>> 
>>>>>>> The way I read the release support document, I don't think the
>>> feature
>>>>>>> cut-off for the 0.x branch happens when we confirm a release
date for
>>>>>> 1.0,
>>>>>>> I think it occurs once we actually release 1.0.  Maybe the cut-off
>>> can
>>>>>>> happen once we declare the first 1.0 release candidate.  I'm
sure we
>>>>>> will
>>>>>>> spend significant time doing testing and bug fixes on 1.0 release
>>>>>>> candidates.  If I recall, we spent 2 weeks on 0.6.1 release
>>> candidates.
>>>>>>> 
>>>>>>> -- Mike
>>>>>>> 
>>>>>>> 
>>>>>>> On Tue, May 17, 2016 at 6:04 PM, Joe Witt <joe.witt@gmail.com>
>>> wrote:
>>>>>>> 
>>>>>>> I believe that is right Andy.  The support guide articulates
that we
>>>>>>> could do a feature release upon request if there was some specific
>>>>>>> need a community member had but that otherwise the only releases
on
>>> an
>>>>>>> older line still supported would be focused on security/data
loss
>>> type
>>>>>>> items.
>>>>>>> 
>>>>>>> Thanks
>>>>>>> Joe
>>>>>>> 
>>>>>>> On Tue, May 17, 2016 at 4:58 PM, Andy LoPresto <alopresto@apache.org
>>>> 
>>>>>>> wrote:
>>>>>>> 
>>>>>>> This schedule seems appropriate to me. Once 0.7.0 is released
and we
>>>>>>> 
>>>>>>> confirm
>>>>>>> 
>>>>>>> the release date for 1.0, feature development is completely targeted
>>> to
>>>>>>> 
>>>>>>> 1.0,
>>>>>>> 
>>>>>>> correct? Security and data loss bug fixes would still be backported,
>>> but
>>>>>>> 
>>>>>>> new
>>>>>>> 
>>>>>>> features would not.
>>>>>>> 
>>>>>>> Andy LoPresto
>>>>>>> alopresto@apache.org
>>>>>>> alopresto.apache@gmail.com
>>>>>>> PGP Fingerprint: 70EC B3E5 98A6 5A3F D3C4  BACE 3C6E F65B 2F7D
EF69
>>>>>>> 
>>>>>>> On May 17, 2016, at 1:19 PM, Joe Witt <joe.witt@gmail.com>
wrote:
>>>>>>> 
>>>>>>> Ok - i'm good with an 0.7 release too and think it is a good
idea.  I
>>>>>>> am happy to RM the release.
>>>>>>> 
>>>>>>> I'd like to select a date at which we're happy to call the 0.x
line
>>>>>>> then feature complete which means 0.7 would be the last feature
>>>>>>> bearing 0.x release and from then on it would be bug fixes only
>>>>>>> consistent withe support model.  To do that I think we should
feel
>>>>>>> reasonably confident that the 1.x release is close.  So let's
say we
>>>>>>> did an 0.7 release early June - say first week of June.  I'd
like us
>>>>>>> to say then that 1.x is targeted to early July.
>>>>>>> 
>>>>>>> If this seems like a reasonable path I'll start filling out the
>>>>>>> tragically never updated roadmap wiki page [1] with the 0.7 target,
>>>>>>> 1.x target, and put some placeholder/tentatives for the 1.1 and
>>> beyond
>>>>>>> targets.  Will wait for additional inputs.
>>>>>>> 
>>>>>>> [1]
>>> https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=58851850
>>>>>>> 
>>>>>>> 
>>>>>>> Thanks
>>>>>>> Joe
>>>>>>> 
>>>>>>> On Tue, May 17, 2016 at 4:15 PM, Oleg Zhurakousky
>>>>>>> <ozhurakousky@hortonworks.com> wrote:
>>>>>>> 
>>>>>>> Agreed! I would like to see 0.7 within 2-3 weeks as there are
a lot
>>> of
>>>>>>> improvements and new features/components in it already, and would
>>> like
>>>>>> to
>>>>>>> give it some miles before 1.0.
>>>>>>> 
>>>>>>> Oleg
>>>>>>> 
>>>>>>> On May 17, 2016, at 4:02 PM, James Wing <jvwing@gmail.com>
wrote:
>>>>>>> 
>>>>>>> I'm definitely in favor of releasing 0.7.0, but I don't think
we
>>> need be
>>>>>>> rigid about the schedule.  If delaying 0.7.0 a few weeks (2-4?)
helps
>>>>>>> 
>>>>>>> pace
>>>>>>> 
>>>>>>> us towards a 1.0 in mid- to late-Summer, that seems reasonable
to me.
>>>>>> Do
>>>>>>> we believe that is still a likely target?
>>>>>>> 
>>>>>>> Thanks,
>>>>>>> 
>>>>>>> James
>>>>>>> 
>>>>>>> On Tue, May 17, 2016 at 7:30 AM, Joe Witt <joewitt@apache.org>
>>> wrote:
>>>>>>> 
>>>>>>> Team,
>>>>>>> 
>>>>>>> Want to start zeroing in on the details of the next releases.
 We had
>>>>>>> a good set of discussions around this back in January and have
since
>>>>>>> been executing along this general path [1].
>>>>>>> 
>>>>>>> On the 0.x line the next release would be 0.7.0.  There does
appear
>>> to
>>>>>>> be a lot of useful improvements/features/fixes there now and
it is
>>>>>>> time to do a release according to our general 6-8 week approach.
>>>>>>> However, given all the effort going into 1.x I'd like to get
a sense
>>>>>>> of what the community preference is.
>>>>>>> 
>>>>>>> On the 1.0 line the release is coming into focus.  Some things
have
>>>>>>> moved into 1.x and some things look like they'd slide to the
right of
>>>>>>> 1.x as is to be expected.  For example distributed durability
(HA
>>>>>>> Data) looks like a good thing to do post 1.0 given the substantive
>>>>>>> changes present from the new HA clustering approach and multi-tenant
>>>>>>> authorization.  I'd also like to dive in and liberally apply
Apache
>>>>>>> Yetus annotations [2] to all the things so we can be really explicit
>>>>>>> about what parts we can more freely evolve going forward.  We've
been
>>>>>>> a bit awkwardly hamstrung thus far without these so they should
help
>>>>>>> greatly to better convey intent.
>>>>>>> 
>>>>>>> For those really interested in things coming in the 1.0 release
>>> please
>>>>>>> take a look through the JIRAs currently there and provide comments
on
>>>>>>> what is important to you, what you'd like to see moved out, in,
etc..
>>>>>>> [3].  At this point there are still a lot of things which will
likely
>>>>>>> need to move out to allow the release to occur in a timely fashion.
>>>>>>> 
>>>>>>> Also, keep in mind our stated release line/support model as found
>>> here
>>>>>>> 
>>>>>>> [4].
>>>>>>> 
>>>>>>> 
>>>>>>> [1]
>>> http://mail-archives.apache.org/mod_mbox/nifi-dev/201601.mbox/%3CCALJK9a4dMw9PyrrihpPwM7DH3R_4v8b%3Dr--LDhK7y5scob-0og%40mail.gmail.com%3E
>>>>>>> 
>>>>>>> 
>>>>>>> [2]
>>> https://yetus.apache.org/documentation/0.2.1/audience-annotations-apidocs/
>>>>>>> 
>>>>>>> 
>>>>>>> [3]
>>> https://issues.apache.org/jira/browse/NIFI-1887?jql=fixVersion%20%3D%201.0.0%20AND%20project%20%3D%20NIFI
>>>>>>> 
>>>>>>> 
>>>>>>> [4]
>>> https://cwiki.apache.org/confluence/display/NIFI/Git+Branching+and+Release+Line+Management
>>>>>>> 
>>>>>>> 
>>>>>>> Thanks
>>>>>>> Joe
>> 
>> 
>> 
>> --
>> Cheers,
>> 
>> Edgardo
> 

Mime
View raw message