nifi-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Joe Witt <joe.w...@gmail.com>
Subject Re: [DISCUSS] Apache NiFi 0.7.0 and 1.0.0
Date Wed, 01 Jun 2016 12:33:40 GMT
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