Re: discuss nifi 0.4.1

[Oleg Zhurakousky]

I agree, I think we discussed it before and the Kafka upgrade doesn't belong in 
41

Sent from my iPhone

> On Dec 18, 2015, at 23:26, Sean Busbey  wrote:
> 
> with the Kafka client change backed out for 0.5.0, I'm good to go with
> 0.4.1 on the rest of the changes.
> 
>> On Fri, Dec 18, 2015 at 10:11 PM, Joe Witt  wrote:
>> Sean,
>> 
>> Yeah i don't disagree with that point.  The caveat being it was only a
>> change to that client not a change to support the new client API and
>> the behavior with existing clients old and new verified.
>> 
>> I'd prefer to stick with 0.4.1 and if you still think it is best to
>> actually just revert that commit and apply it toward 0.5.0.
>> 
>> What do you think?
>> 
>> Thanks
>> Joe
>> 
>>> On Fri, Dec 18, 2015 at 11:08 PM, Sean Busbey  wrote:
>>> Can we update to 0.5.0 instead? The kafka client change isn't
>>> something I'd expect in a patch release.
>>> 
 On Fri, Dec 18, 2015 at 9:54 PM, Joe Witt  wrote:
 ok - so master is presently on 041 and it does indeed appear to be all
 incremental friendly fixes.  So looks like we can just use the normal
 process.  As excited as I was to use cherry-pick doesn't look like it
 is needed.
 
 The bugs fixed on 041 so far are all nice cleanup items and things
 which have been problematic for quite a while.  However, there are a
 few site-to-site issues that would create some pretty annoying issues
 for users so best to eliminate them.  And big thanks to Matt Clarke
 for finding and reporting them!
 
 Gonna prep an RC.
 
 Thanks
 Joe
 
> On Thu, Dec 17, 2015 at 7:53 PM, Tony Kurc  wrote:
> I have no objection to "because we should be able to do this well!" as a
> reason.
> 
> On Thu, Dec 17, 2015 at 7:45 PM, Oleg Zhurakousky <
> ozhurakou...@hortonworks.com> wrote:
> 
>> Generally RCs are used to address that level of validation, so in the end
>> I still think it's a more of a culture one chooses. One common  example;
>> x.x.1+ = maintenance, x.1+.0 = minor features + bugs and 1+.0.0 = major
>> features.
>> 
>> In any event IMHO the ability to quickly release maintenance releases is
>> very important  as it showcases our attention to quality
>> 
>> Sent from my iPhone
>> 
>>> On Dec 17, 2015, at 19:32, Tony Kurc  wrote:
>>> 
>>> I'm not sure I understand "more validation" reasoning - won't features 
>>> at
>>> the end have very little validation?
>>> 
 On Thu, Dec 17, 2015 at 7:26 PM, Ryan Blue  wrote:
 
 Another reason to release 0.4.1 is to allow the additions that warrant
 0.5.0 to have more validation before release. With a regular release
>> cycle,
 features can go in at the beginning to have more time for catching bugs
>> in
 them. I also agree with what Sean said below.
 
 rb
 
> On 12/17/2015 04:00 PM, Sean Busbey wrote:
> 
> On Thu, Dec 17, 2015 at 5:50 PM, Tony Kurc  wrote:
> 
> s/features/buxfixes/
>> 
>> On Thu, Dec 17, 2015 at 6:50 PM, Tony Kurc  wrote:
>> 
>> Is there a reason to not just cut a 0.5.0 instead of grafting 0.5.0
>>> features onto 0.4.1?
> This is a good question.
> 
> Some downstream users might have different change processes for a
>> patch vs
> minor release, so making a 0.4.1 that fixes what we determine to be a
> substantial gap in the 0.4 line would be nice for them.
> 
> While we might be a young project now, it would be good to already 
> have
> the
> habit practiced for when we have more users in enterprise settings.
> 
> On the other hand, 0.4.0 just happened, so a release in 3 days would
> minimize the number of "stuck on 0.4.0" folks.
 
 --
 Ryan Blue
 Software Engineer
 Cloudera, Inc.
> 
> 
> 
> -- 
> Sean
> 

Re: discuss nifi 0.4.1

[Joe Witt]

Sean,

Yeah i don't disagree with that point.  The caveat being it was only a
change to that client not a change to support the new client API and
the behavior with existing clients old and new verified.

I'd prefer to stick with 0.4.1 and if you still think it is best to
actually just revert that commit and apply it toward 0.5.0.

What do you think?

Thanks
Joe

On Fri, Dec 18, 2015 at 11:08 PM, Sean Busbey  wrote:
> Can we update to 0.5.0 instead? The kafka client change isn't
> something I'd expect in a patch release.
>
> On Fri, Dec 18, 2015 at 9:54 PM, Joe Witt  wrote:
>> ok - so master is presently on 041 and it does indeed appear to be all
>> incremental friendly fixes.  So looks like we can just use the normal
>> process.  As excited as I was to use cherry-pick doesn't look like it
>> is needed.
>>
>> The bugs fixed on 041 so far are all nice cleanup items and things
>> which have been problematic for quite a while.  However, there are a
>> few site-to-site issues that would create some pretty annoying issues
>> for users so best to eliminate them.  And big thanks to Matt Clarke
>> for finding and reporting them!
>>
>> Gonna prep an RC.
>>
>> Thanks
>> Joe
>>
>> On Thu, Dec 17, 2015 at 7:53 PM, Tony Kurc  wrote:
>>> I have no objection to "because we should be able to do this well!" as a
>>> reason.
>>>
>>> On Thu, Dec 17, 2015 at 7:45 PM, Oleg Zhurakousky <
>>> ozhurakou...@hortonworks.com> wrote:
>>>
 Generally RCs are used to address that level of validation, so in the end
 I still think it's a more of a culture one chooses. One common  example;
 x.x.1+ = maintenance, x.1+.0 = minor features + bugs and 1+.0.0 = major
 features.

 In any event IMHO the ability to quickly release maintenance releases is
 very important  as it showcases our attention to quality

 Sent from my iPhone

 > On Dec 17, 2015, at 19:32, Tony Kurc  wrote:
 >
 > I'm not sure I understand "more validation" reasoning - won't features at
 > the end have very little validation?
 >
 >> On Thu, Dec 17, 2015 at 7:26 PM, Ryan Blue  wrote:
 >>
 >> Another reason to release 0.4.1 is to allow the additions that warrant
 >> 0.5.0 to have more validation before release. With a regular release
 cycle,
 >> features can go in at the beginning to have more time for catching bugs
 in
 >> them. I also agree with what Sean said below.
 >>
 >> rb
 >>
 >>> On 12/17/2015 04:00 PM, Sean Busbey wrote:
 >>>
 >>> On Thu, Dec 17, 2015 at 5:50 PM, Tony Kurc  wrote:
 >>>
 >>> s/features/buxfixes/
 
  On Thu, Dec 17, 2015 at 6:50 PM, Tony Kurc  wrote:
 
  Is there a reason to not just cut a 0.5.0 instead of grafting 0.5.0
 > features onto 0.4.1?
 >>> This is a good question.
 >>>
 >>> Some downstream users might have different change processes for a
 patch vs
 >>> minor release, so making a 0.4.1 that fixes what we determine to be a
 >>> substantial gap in the 0.4 line would be nice for them.
 >>>
 >>> While we might be a young project now, it would be good to already have
 >>> the
 >>> habit practiced for when we have more users in enterprise settings.
 >>>
 >>> On the other hand, 0.4.0 just happened, so a release in 3 days would
 >>> minimize the number of "stuck on 0.4.0" folks.
 >>
 >> --
 >> Ryan Blue
 >> Software Engineer
 >> Cloudera, Inc.
 >>

Re: discuss nifi 0.4.1

[Sean Busbey]

with the Kafka client change backed out for 0.5.0, I'm good to go with
0.4.1 on the rest of the changes.

On Fri, Dec 18, 2015 at 10:11 PM, Joe Witt  wrote:
> Sean,
>
> Yeah i don't disagree with that point.  The caveat being it was only a
> change to that client not a change to support the new client API and
> the behavior with existing clients old and new verified.
>
> I'd prefer to stick with 0.4.1 and if you still think it is best to
> actually just revert that commit and apply it toward 0.5.0.
>
> What do you think?
>
> Thanks
> Joe
>
> On Fri, Dec 18, 2015 at 11:08 PM, Sean Busbey  wrote:
>> Can we update to 0.5.0 instead? The kafka client change isn't
>> something I'd expect in a patch release.
>>
>> On Fri, Dec 18, 2015 at 9:54 PM, Joe Witt  wrote:
>>> ok - so master is presently on 041 and it does indeed appear to be all
>>> incremental friendly fixes.  So looks like we can just use the normal
>>> process.  As excited as I was to use cherry-pick doesn't look like it
>>> is needed.
>>>
>>> The bugs fixed on 041 so far are all nice cleanup items and things
>>> which have been problematic for quite a while.  However, there are a
>>> few site-to-site issues that would create some pretty annoying issues
>>> for users so best to eliminate them.  And big thanks to Matt Clarke
>>> for finding and reporting them!
>>>
>>> Gonna prep an RC.
>>>
>>> Thanks
>>> Joe
>>>
>>> On Thu, Dec 17, 2015 at 7:53 PM, Tony Kurc  wrote:
 I have no objection to "because we should be able to do this well!" as a
 reason.

 On Thu, Dec 17, 2015 at 7:45 PM, Oleg Zhurakousky <
 ozhurakou...@hortonworks.com> wrote:

> Generally RCs are used to address that level of validation, so in the end
> I still think it's a more of a culture one chooses. One common  example;
> x.x.1+ = maintenance, x.1+.0 = minor features + bugs and 1+.0.0 = major
> features.
>
> In any event IMHO the ability to quickly release maintenance releases is
> very important  as it showcases our attention to quality
>
> Sent from my iPhone
>
> > On Dec 17, 2015, at 19:32, Tony Kurc  wrote:
> >
> > I'm not sure I understand "more validation" reasoning - won't features 
> > at
> > the end have very little validation?
> >
> >> On Thu, Dec 17, 2015 at 7:26 PM, Ryan Blue  wrote:
> >>
> >> Another reason to release 0.4.1 is to allow the additions that warrant
> >> 0.5.0 to have more validation before release. With a regular release
> cycle,
> >> features can go in at the beginning to have more time for catching bugs
> in
> >> them. I also agree with what Sean said below.
> >>
> >> rb
> >>
> >>> On 12/17/2015 04:00 PM, Sean Busbey wrote:
> >>>
> >>> On Thu, Dec 17, 2015 at 5:50 PM, Tony Kurc  wrote:
> >>>
> >>> s/features/buxfixes/
> 
>  On Thu, Dec 17, 2015 at 6:50 PM, Tony Kurc  wrote:
> 
>  Is there a reason to not just cut a 0.5.0 instead of grafting 0.5.0
> > features onto 0.4.1?
> >>> This is a good question.
> >>>
> >>> Some downstream users might have different change processes for a
> patch vs
> >>> minor release, so making a 0.4.1 that fixes what we determine to be a
> >>> substantial gap in the 0.4 line would be nice for them.
> >>>
> >>> While we might be a young project now, it would be good to already 
> >>> have
> >>> the
> >>> habit practiced for when we have more users in enterprise settings.
> >>>
> >>> On the other hand, 0.4.0 just happened, so a release in 3 days would
> >>> minimize the number of "stuck on 0.4.0" folks.
> >>
> >> --
> >> Ryan Blue
> >> Software Engineer
> >> Cloudera, Inc.
> >>
>



-- 
Sean

Re: discuss nifi 0.4.1

[Joe Witt]

rgr that - will revert, save patch on ticket, plus this means someone
can get Oleg's kafka tester patch reviewed there too.

thanks

On Fri, Dec 18, 2015 at 11:26 PM, Sean Busbey  wrote:
> with the Kafka client change backed out for 0.5.0, I'm good to go with
> 0.4.1 on the rest of the changes.
>
> On Fri, Dec 18, 2015 at 10:11 PM, Joe Witt  wrote:
>> Sean,
>>
>> Yeah i don't disagree with that point.  The caveat being it was only a
>> change to that client not a change to support the new client API and
>> the behavior with existing clients old and new verified.
>>
>> I'd prefer to stick with 0.4.1 and if you still think it is best to
>> actually just revert that commit and apply it toward 0.5.0.
>>
>> What do you think?
>>
>> Thanks
>> Joe
>>
>> On Fri, Dec 18, 2015 at 11:08 PM, Sean Busbey  wrote:
>>> Can we update to 0.5.0 instead? The kafka client change isn't
>>> something I'd expect in a patch release.
>>>
>>> On Fri, Dec 18, 2015 at 9:54 PM, Joe Witt  wrote:
 ok - so master is presently on 041 and it does indeed appear to be all
 incremental friendly fixes.  So looks like we can just use the normal
 process.  As excited as I was to use cherry-pick doesn't look like it
 is needed.

 The bugs fixed on 041 so far are all nice cleanup items and things
 which have been problematic for quite a while.  However, there are a
 few site-to-site issues that would create some pretty annoying issues
 for users so best to eliminate them.  And big thanks to Matt Clarke
 for finding and reporting them!

 Gonna prep an RC.

 Thanks
 Joe

 On Thu, Dec 17, 2015 at 7:53 PM, Tony Kurc  wrote:
> I have no objection to "because we should be able to do this well!" as a
> reason.
>
> On Thu, Dec 17, 2015 at 7:45 PM, Oleg Zhurakousky <
> ozhurakou...@hortonworks.com> wrote:
>
>> Generally RCs are used to address that level of validation, so in the end
>> I still think it's a more of a culture one chooses. One common  example;
>> x.x.1+ = maintenance, x.1+.0 = minor features + bugs and 1+.0.0 = major
>> features.
>>
>> In any event IMHO the ability to quickly release maintenance releases is
>> very important  as it showcases our attention to quality
>>
>> Sent from my iPhone
>>
>> > On Dec 17, 2015, at 19:32, Tony Kurc  wrote:
>> >
>> > I'm not sure I understand "more validation" reasoning - won't features 
>> > at
>> > the end have very little validation?
>> >
>> >> On Thu, Dec 17, 2015 at 7:26 PM, Ryan Blue  wrote:
>> >>
>> >> Another reason to release 0.4.1 is to allow the additions that warrant
>> >> 0.5.0 to have more validation before release. With a regular release
>> cycle,
>> >> features can go in at the beginning to have more time for catching 
>> >> bugs
>> in
>> >> them. I also agree with what Sean said below.
>> >>
>> >> rb
>> >>
>> >>> On 12/17/2015 04:00 PM, Sean Busbey wrote:
>> >>>
>> >>> On Thu, Dec 17, 2015 at 5:50 PM, Tony Kurc  wrote:
>> >>>
>> >>> s/features/buxfixes/
>> 
>>  On Thu, Dec 17, 2015 at 6:50 PM, Tony Kurc  wrote:
>> 
>>  Is there a reason to not just cut a 0.5.0 instead of grafting 0.5.0
>> > features onto 0.4.1?
>> >>> This is a good question.
>> >>>
>> >>> Some downstream users might have different change processes for a
>> patch vs
>> >>> minor release, so making a 0.4.1 that fixes what we determine to be a
>> >>> substantial gap in the 0.4 line would be nice for them.
>> >>>
>> >>> While we might be a young project now, it would be good to already 
>> >>> have
>> >>> the
>> >>> habit practiced for when we have more users in enterprise settings.
>> >>>
>> >>> On the other hand, 0.4.0 just happened, so a release in 3 days would
>> >>> minimize the number of "stuck on 0.4.0" folks.
>> >>
>> >> --
>> >> Ryan Blue
>> >> Software Engineer
>> >> Cloudera, Inc.
>> >>
>>
>
>
>
> --
> Sean

Re: discuss nifi 0.4.1

[Joe Witt]

ok - so master is presently on 041 and it does indeed appear to be all
incremental friendly fixes.  So looks like we can just use the normal
process.  As excited as I was to use cherry-pick doesn't look like it
is needed.

The bugs fixed on 041 so far are all nice cleanup items and things
which have been problematic for quite a while.  However, there are a
few site-to-site issues that would create some pretty annoying issues
for users so best to eliminate them.  And big thanks to Matt Clarke
for finding and reporting them!

Gonna prep an RC.

Thanks
Joe

On Thu, Dec 17, 2015 at 7:53 PM, Tony Kurc  wrote:
> I have no objection to "because we should be able to do this well!" as a
> reason.
>
> On Thu, Dec 17, 2015 at 7:45 PM, Oleg Zhurakousky <
> ozhurakou...@hortonworks.com> wrote:
>
>> Generally RCs are used to address that level of validation, so in the end
>> I still think it's a more of a culture one chooses. One common  example;
>> x.x.1+ = maintenance, x.1+.0 = minor features + bugs and 1+.0.0 = major
>> features.
>>
>> In any event IMHO the ability to quickly release maintenance releases is
>> very important  as it showcases our attention to quality
>>
>> Sent from my iPhone
>>
>> > On Dec 17, 2015, at 19:32, Tony Kurc  wrote:
>> >
>> > I'm not sure I understand "more validation" reasoning - won't features at
>> > the end have very little validation?
>> >
>> >> On Thu, Dec 17, 2015 at 7:26 PM, Ryan Blue  wrote:
>> >>
>> >> Another reason to release 0.4.1 is to allow the additions that warrant
>> >> 0.5.0 to have more validation before release. With a regular release
>> cycle,
>> >> features can go in at the beginning to have more time for catching bugs
>> in
>> >> them. I also agree with what Sean said below.
>> >>
>> >> rb
>> >>
>> >>> On 12/17/2015 04:00 PM, Sean Busbey wrote:
>> >>>
>> >>> On Thu, Dec 17, 2015 at 5:50 PM, Tony Kurc  wrote:
>> >>>
>> >>> s/features/buxfixes/
>> 
>>  On Thu, Dec 17, 2015 at 6:50 PM, Tony Kurc  wrote:
>> 
>>  Is there a reason to not just cut a 0.5.0 instead of grafting 0.5.0
>> > features onto 0.4.1?
>> >>> This is a good question.
>> >>>
>> >>> Some downstream users might have different change processes for a
>> patch vs
>> >>> minor release, so making a 0.4.1 that fixes what we determine to be a
>> >>> substantial gap in the 0.4 line would be nice for them.
>> >>>
>> >>> While we might be a young project now, it would be good to already have
>> >>> the
>> >>> habit practiced for when we have more users in enterprise settings.
>> >>>
>> >>> On the other hand, 0.4.0 just happened, so a release in 3 days would
>> >>> minimize the number of "stuck on 0.4.0" folks.
>> >>
>> >> --
>> >> Ryan Blue
>> >> Software Engineer
>> >> Cloudera, Inc.
>> >>
>>

Re: discuss nifi 0.4.1

[Sean Busbey]

Can we update to 0.5.0 instead? The kafka client change isn't
something I'd expect in a patch release.

On Fri, Dec 18, 2015 at 9:54 PM, Joe Witt  wrote:
> ok - so master is presently on 041 and it does indeed appear to be all
> incremental friendly fixes.  So looks like we can just use the normal
> process.  As excited as I was to use cherry-pick doesn't look like it
> is needed.
>
> The bugs fixed on 041 so far are all nice cleanup items and things
> which have been problematic for quite a while.  However, there are a
> few site-to-site issues that would create some pretty annoying issues
> for users so best to eliminate them.  And big thanks to Matt Clarke
> for finding and reporting them!
>
> Gonna prep an RC.
>
> Thanks
> Joe
>
> On Thu, Dec 17, 2015 at 7:53 PM, Tony Kurc  wrote:
>> I have no objection to "because we should be able to do this well!" as a
>> reason.
>>
>> On Thu, Dec 17, 2015 at 7:45 PM, Oleg Zhurakousky <
>> ozhurakou...@hortonworks.com> wrote:
>>
>>> Generally RCs are used to address that level of validation, so in the end
>>> I still think it's a more of a culture one chooses. One common  example;
>>> x.x.1+ = maintenance, x.1+.0 = minor features + bugs and 1+.0.0 = major
>>> features.
>>>
>>> In any event IMHO the ability to quickly release maintenance releases is
>>> very important  as it showcases our attention to quality
>>>
>>> Sent from my iPhone
>>>
>>> > On Dec 17, 2015, at 19:32, Tony Kurc  wrote:
>>> >
>>> > I'm not sure I understand "more validation" reasoning - won't features at
>>> > the end have very little validation?
>>> >
>>> >> On Thu, Dec 17, 2015 at 7:26 PM, Ryan Blue  wrote:
>>> >>
>>> >> Another reason to release 0.4.1 is to allow the additions that warrant
>>> >> 0.5.0 to have more validation before release. With a regular release
>>> cycle,
>>> >> features can go in at the beginning to have more time for catching bugs
>>> in
>>> >> them. I also agree with what Sean said below.
>>> >>
>>> >> rb
>>> >>
>>> >>> On 12/17/2015 04:00 PM, Sean Busbey wrote:
>>> >>>
>>> >>> On Thu, Dec 17, 2015 at 5:50 PM, Tony Kurc  wrote:
>>> >>>
>>> >>> s/features/buxfixes/
>>> 
>>>  On Thu, Dec 17, 2015 at 6:50 PM, Tony Kurc  wrote:
>>> 
>>>  Is there a reason to not just cut a 0.5.0 instead of grafting 0.5.0
>>> > features onto 0.4.1?
>>> >>> This is a good question.
>>> >>>
>>> >>> Some downstream users might have different change processes for a
>>> patch vs
>>> >>> minor release, so making a 0.4.1 that fixes what we determine to be a
>>> >>> substantial gap in the 0.4 line would be nice for them.
>>> >>>
>>> >>> While we might be a young project now, it would be good to already have
>>> >>> the
>>> >>> habit practiced for when we have more users in enterprise settings.
>>> >>>
>>> >>> On the other hand, 0.4.0 just happened, so a release in 3 days would
>>> >>> minimize the number of "stuck on 0.4.0" folks.
>>> >>
>>> >> --
>>> >> Ryan Blue
>>> >> Software Engineer
>>> >> Cloudera, Inc.
>>> >>
>>>

Re: discuss nifi 0.4.1

[Sean Busbey]

Sounds reasonable to me. branching off of the last release tag and then
cherry picking a conservative subset of fixes for a patch release has
worked well for me on another project.

It's implied in your email, but just to confirm, you're only suggesting
grabbing *some* of the currently-in-0.5.0 issues right? specifically just
those that you added a 0.4.1 fixversion to?


On Thu, Dec 17, 2015 at 2:29 PM, Joe Witt  wrote:

> team,
>
> matt clarke just discovered an interesting case that appears to expose
> a defect in site-to-site.  The details of it are still being worked
> out as you can see in NIFI-1301.  And this issue has been around for a
> very long time but it still feels like something worth addressing in
> an incremental/bug release (0.4.1).
>
> I looked at already addressed bugs on 050 and added the to fix
> versions of 041 as well.  What I am wondering here is a bit of a
> proper usage and thinking with Git.  Would it make sense to branch off
> master right where 0.4.1-SNAPSHOT started, then cherry pick the
> commits into this new branch, and just release that branch never
> needing then to merge that back to master since these fixes are all
> already on master anyway?
>
>
> https://issues.apache.org/jira/browse/NIFI-1301?jql=project%20%3D%20NIFI%20AND%20fixVersion%20%3D%200.4.1%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>
> Thanks
> Joe
>



-- 
Sean

Re: discuss nifi 0.4.1

[Matt Gilman]

Are there some commits on master that we don't want included in 0.4.1? If
not, wouldn't we just follow our normal release process?

Matt

On Thu, Dec 17, 2015 at 6:15 PM, Ryan Blue  wrote:

> Branching from master at the start of 0.4.1-SNAPSHOT and cherry-picking
> makes sense to me.
>
> rb
>
>
> On 12/17/2015 12:29 PM, Joe Witt wrote:
>
>> team,
>>
>> matt clarke just discovered an interesting case that appears to expose
>> a defect in site-to-site.  The details of it are still being worked
>> out as you can see in NIFI-1301.  And this issue has been around for a
>> very long time but it still feels like something worth addressing in
>> an incremental/bug release (0.4.1).
>>
>> I looked at already addressed bugs on 050 and added the to fix
>> versions of 041 as well.  What I am wondering here is a bit of a
>> proper usage and thinking with Git.  Would it make sense to branch off
>> master right where 0.4.1-SNAPSHOT started, then cherry pick the
>> commits into this new branch, and just release that branch never
>> needing then to merge that back to master since these fixes are all
>> already on master anyway?
>>
>>
>> https://issues.apache.org/jira/browse/NIFI-1301?jql=project%20%3D%20NIFI%20AND%20fixVersion%20%3D%200.4.1%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>>
>> Thanks
>> Joe
>>
>>
>
> --
> Ryan Blue
> Software Engineer
> Cloudera, Inc.
>

Re: discuss nifi 0.4.1

[Sean Busbey]

I wouldn't want to see the kafka client upgrade in a patch release.

On Thu, Dec 17, 2015 at 5:37 PM, Joe Witt  wrote:

> OK thanks for confirming proper git fu.
>
> Yeah I was meaning to just grab bugs.  The master branch already has stuff
> that seems to warrant a minor bump (maybe) so wanted to understand a bug
> only route.
>
> Matt understand your point on dependent commits.  Will check that out.
>
> Thanks
> Joe
> On Dec 17, 2015 6:32 PM, "Matt Gilman"  wrote:
>
> > I see, that does appear to be the case. What your suggesting sounds good.
> > Though we should review the tickets that addressed UI bugs/improvements.
> I
> > realize you probably specifically just chose the JIRAs that addressed
> bugs.
> > I'd want to make sure that the tickets included don't have a dependency
> on
> > the tickets excluded. For instance, merge conflicts because a commit in
> an
> > included ticket is based off the code base after a commit in an excluded
> > ticket.
> >
> > Matt
> >
> > On Thu, Dec 17, 2015 at 6:17 PM, Matt Gilman 
> > wrote:
> >
> > > Are there some commits on master that we don't want included in 0.4.1?
> If
> > > not, wouldn't we just follow our normal release process?
> > >
> > > Matt
> > >
> > >
> > > On Thu, Dec 17, 2015 at 6:15 PM, Ryan Blue  wrote:
> > >
> > >> Branching from master at the start of 0.4.1-SNAPSHOT and
> cherry-picking
> > >> makes sense to me.
> > >>
> > >> rb
> > >>
> > >>
> > >> On 12/17/2015 12:29 PM, Joe Witt wrote:
> > >>
> > >>> team,
> > >>>
> > >>> matt clarke just discovered an interesting case that appears to
> expose
> > >>> a defect in site-to-site.  The details of it are still being worked
> > >>> out as you can see in NIFI-1301.  And this issue has been around for
> a
> > >>> very long time but it still feels like something worth addressing in
> > >>> an incremental/bug release (0.4.1).
> > >>>
> > >>> I looked at already addressed bugs on 050 and added the to fix
> > >>> versions of 041 as well.  What I am wondering here is a bit of a
> > >>> proper usage and thinking with Git.  Would it make sense to branch
> off
> > >>> master right where 0.4.1-SNAPSHOT started, then cherry pick the
> > >>> commits into this new branch, and just release that branch never
> > >>> needing then to merge that back to master since these fixes are all
> > >>> already on master anyway?
> > >>>
> > >>>
> > >>>
> >
> https://issues.apache.org/jira/browse/NIFI-1301?jql=project%20%3D%20NIFI%20AND%20fixVersion%20%3D%200.4.1%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> > >>>
> > >>> Thanks
> > >>> Joe
> > >>>
> > >>>
> > >>
> > >> --
> > >> Ryan Blue
> > >> Software Engineer
> > >> Cloudera, Inc.
> > >>
> > >
> > >
> >
>



-- 
Sean

Re: discuss nifi 0.4.1

[Oleg Zhurakousky]

I think we want to exclude new features and make it a true maintenance release, 
so only bugs should go into 0.4.1   

> On Dec 17, 2015, at 6:17 PM, Matt Gilman  wrote:
> 
> Are there some commits on master that we don't want included in 0.4.1? If
> not, wouldn't we just follow our normal release process?
> 
> Matt
> 
> On Thu, Dec 17, 2015 at 6:15 PM, Ryan Blue  wrote:
> 
>> Branching from master at the start of 0.4.1-SNAPSHOT and cherry-picking
>> makes sense to me.
>> 
>> rb
>> 
>> 
>> On 12/17/2015 12:29 PM, Joe Witt wrote:
>> 
>>> team,
>>> 
>>> matt clarke just discovered an interesting case that appears to expose
>>> a defect in site-to-site.  The details of it are still being worked
>>> out as you can see in NIFI-1301.  And this issue has been around for a
>>> very long time but it still feels like something worth addressing in
>>> an incremental/bug release (0.4.1).
>>> 
>>> I looked at already addressed bugs on 050 and added the to fix
>>> versions of 041 as well.  What I am wondering here is a bit of a
>>> proper usage and thinking with Git.  Would it make sense to branch off
>>> master right where 0.4.1-SNAPSHOT started, then cherry pick the
>>> commits into this new branch, and just release that branch never
>>> needing then to merge that back to master since these fixes are all
>>> already on master anyway?
>>> 
>>> 
>>> https://issues.apache.org/jira/browse/NIFI-1301?jql=project%20%3D%20NIFI%20AND%20fixVersion%20%3D%200.4.1%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>>> 
>>> Thanks
>>> Joe
>>> 
>>> 
>> 
>> --
>> Ryan Blue
>> Software Engineer
>> Cloudera, Inc.
>> 

Re: discuss nifi 0.4.1

[Tony Kurc]

s/features/buxfixes/

On Thu, Dec 17, 2015 at 6:50 PM, Tony Kurc  wrote:

> Is there a reason to not just cut a 0.5.0 instead of grafting 0.5.0
> features onto 0.4.1?
>
> On Thu, Dec 17, 2015 at 6:38 PM, Oleg Zhurakousky <
> ozhurakou...@hortonworks.com> wrote:
>
>> I think we want to exclude new features and make it a true maintenance
>> release, so only bugs should go into 0.4.1
>>
>> > On Dec 17, 2015, at 6:17 PM, Matt Gilman 
>> wrote:
>> >
>> > Are there some commits on master that we don't want included in 0.4.1?
>> If
>> > not, wouldn't we just follow our normal release process?
>> >
>> > Matt
>> >
>> > On Thu, Dec 17, 2015 at 6:15 PM, Ryan Blue  wrote:
>> >
>> >> Branching from master at the start of 0.4.1-SNAPSHOT and cherry-picking
>> >> makes sense to me.
>> >>
>> >> rb
>> >>
>> >>
>> >> On 12/17/2015 12:29 PM, Joe Witt wrote:
>> >>
>> >>> team,
>> >>>
>> >>> matt clarke just discovered an interesting case that appears to expose
>> >>> a defect in site-to-site.  The details of it are still being worked
>> >>> out as you can see in NIFI-1301.  And this issue has been around for a
>> >>> very long time but it still feels like something worth addressing in
>> >>> an incremental/bug release (0.4.1).
>> >>>
>> >>> I looked at already addressed bugs on 050 and added the to fix
>> >>> versions of 041 as well.  What I am wondering here is a bit of a
>> >>> proper usage and thinking with Git.  Would it make sense to branch off
>> >>> master right where 0.4.1-SNAPSHOT started, then cherry pick the
>> >>> commits into this new branch, and just release that branch never
>> >>> needing then to merge that back to master since these fixes are all
>> >>> already on master anyway?
>> >>>
>> >>>
>> >>>
>> https://issues.apache.org/jira/browse/NIFI-1301?jql=project%20%3D%20NIFI%20AND%20fixVersion%20%3D%200.4.1%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>> >>>
>> >>> Thanks
>> >>> Joe
>> >>>
>> >>>
>> >>
>> >> --
>> >> Ryan Blue
>> >> Software Engineer
>> >> Cloudera, Inc.
>> >>
>>
>>
>

Re: discuss nifi 0.4.1

[Tony Kurc]

Is there a reason to not just cut a 0.5.0 instead of grafting 0.5.0
features onto 0.4.1?

On Thu, Dec 17, 2015 at 6:38 PM, Oleg Zhurakousky <
ozhurakou...@hortonworks.com> wrote:

> I think we want to exclude new features and make it a true maintenance
> release, so only bugs should go into 0.4.1
>
> > On Dec 17, 2015, at 6:17 PM, Matt Gilman 
> wrote:
> >
> > Are there some commits on master that we don't want included in 0.4.1? If
> > not, wouldn't we just follow our normal release process?
> >
> > Matt
> >
> > On Thu, Dec 17, 2015 at 6:15 PM, Ryan Blue  wrote:
> >
> >> Branching from master at the start of 0.4.1-SNAPSHOT and cherry-picking
> >> makes sense to me.
> >>
> >> rb
> >>
> >>
> >> On 12/17/2015 12:29 PM, Joe Witt wrote:
> >>
> >>> team,
> >>>
> >>> matt clarke just discovered an interesting case that appears to expose
> >>> a defect in site-to-site.  The details of it are still being worked
> >>> out as you can see in NIFI-1301.  And this issue has been around for a
> >>> very long time but it still feels like something worth addressing in
> >>> an incremental/bug release (0.4.1).
> >>>
> >>> I looked at already addressed bugs on 050 and added the to fix
> >>> versions of 041 as well.  What I am wondering here is a bit of a
> >>> proper usage and thinking with Git.  Would it make sense to branch off
> >>> master right where 0.4.1-SNAPSHOT started, then cherry pick the
> >>> commits into this new branch, and just release that branch never
> >>> needing then to merge that back to master since these fixes are all
> >>> already on master anyway?
> >>>
> >>>
> >>>
> https://issues.apache.org/jira/browse/NIFI-1301?jql=project%20%3D%20NIFI%20AND%20fixVersion%20%3D%200.4.1%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
> >>>
> >>> Thanks
> >>> Joe
> >>>
> >>>
> >>
> >> --
> >> Ryan Blue
> >> Software Engineer
> >> Cloudera, Inc.
> >>
>
>

Re: discuss nifi 0.4.1

[Ryan Blue]

Branching from master at the start of 0.4.1-SNAPSHOT and cherry-picking 
makes sense to me.


rb

On 12/17/2015 12:29 PM, Joe Witt wrote:

team,

matt clarke just discovered an interesting case that appears to expose
a defect in site-to-site.  The details of it are still being worked
out as you can see in NIFI-1301.  And this issue has been around for a
very long time but it still feels like something worth addressing in
an incremental/bug release (0.4.1).

I looked at already addressed bugs on 050 and added the to fix
versions of 041 as well.  What I am wondering here is a bit of a
proper usage and thinking with Git.  Would it make sense to branch off
master right where 0.4.1-SNAPSHOT started, then cherry pick the
commits into this new branch, and just release that branch never
needing then to merge that back to master since these fixes are all
already on master anyway?

https://issues.apache.org/jira/browse/NIFI-1301?jql=project%20%3D%20NIFI%20AND%20fixVersion%20%3D%200.4.1%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC

Thanks
Joe




--
Ryan Blue
Software Engineer
Cloudera, Inc.

Re: discuss nifi 0.4.1

[Matt Gilman]

I see, that does appear to be the case. What your suggesting sounds good.
Though we should review the tickets that addressed UI bugs/improvements. I
realize you probably specifically just chose the JIRAs that addressed bugs.
I'd want to make sure that the tickets included don't have a dependency on
the tickets excluded. For instance, merge conflicts because a commit in an
included ticket is based off the code base after a commit in an excluded
ticket.

Matt

On Thu, Dec 17, 2015 at 6:17 PM, Matt Gilman 
wrote:

> Are there some commits on master that we don't want included in 0.4.1? If
> not, wouldn't we just follow our normal release process?
>
> Matt
>
>
> On Thu, Dec 17, 2015 at 6:15 PM, Ryan Blue  wrote:
>
>> Branching from master at the start of 0.4.1-SNAPSHOT and cherry-picking
>> makes sense to me.
>>
>> rb
>>
>>
>> On 12/17/2015 12:29 PM, Joe Witt wrote:
>>
>>> team,
>>>
>>> matt clarke just discovered an interesting case that appears to expose
>>> a defect in site-to-site.  The details of it are still being worked
>>> out as you can see in NIFI-1301.  And this issue has been around for a
>>> very long time but it still feels like something worth addressing in
>>> an incremental/bug release (0.4.1).
>>>
>>> I looked at already addressed bugs on 050 and added the to fix
>>> versions of 041 as well.  What I am wondering here is a bit of a
>>> proper usage and thinking with Git.  Would it make sense to branch off
>>> master right where 0.4.1-SNAPSHOT started, then cherry pick the
>>> commits into this new branch, and just release that branch never
>>> needing then to merge that back to master since these fixes are all
>>> already on master anyway?
>>>
>>>
>>> https://issues.apache.org/jira/browse/NIFI-1301?jql=project%20%3D%20NIFI%20AND%20fixVersion%20%3D%200.4.1%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC
>>>
>>> Thanks
>>> Joe
>>>
>>>
>>
>> --
>> Ryan Blue
>> Software Engineer
>> Cloudera, Inc.
>>
>
>

Re: discuss nifi 0.4.1

[Sean Busbey]

On Thu, Dec 17, 2015 at 5:50 PM, Tony Kurc  wrote:

> s/features/buxfixes/
>
> On Thu, Dec 17, 2015 at 6:50 PM, Tony Kurc  wrote:
>
> > Is there a reason to not just cut a 0.5.0 instead of grafting 0.5.0
> > features onto 0.4.1?
> >
>

This is a good question.

Some downstream users might have different change processes for a patch vs
minor release, so making a 0.4.1 that fixes what we determine to be a
substantial gap in the 0.4 line would be nice for them.

While we might be a young project now, it would be good to already have the
habit practiced for when we have more users in enterprise settings.

On the other hand, 0.4.0 just happened, so a release in 3 days would
minimize the number of "stuck on 0.4.0" folks.

-- 
Sean

discuss nifi 0.4.1

[Joe Witt]

team,

matt clarke just discovered an interesting case that appears to expose
a defect in site-to-site.  The details of it are still being worked
out as you can see in NIFI-1301.  And this issue has been around for a
very long time but it still feels like something worth addressing in
an incremental/bug release (0.4.1).

I looked at already addressed bugs on 050 and added the to fix
versions of 041 as well.  What I am wondering here is a bit of a
proper usage and thinking with Git.  Would it make sense to branch off
master right where 0.4.1-SNAPSHOT started, then cherry pick the
commits into this new branch, and just release that branch never
needing then to merge that back to master since these fixes are all
already on master anyway?

https://issues.apache.org/jira/browse/NIFI-1301?jql=project%20%3D%20NIFI%20AND%20fixVersion%20%3D%200.4.1%20ORDER%20BY%20due%20ASC%2C%20priority%20DESC%2C%20created%20ASC

Thanks
Joe

Re: discuss nifi 0.4.1

[Ryan Blue]

Another reason to release 0.4.1 is to allow the additions that warrant 
0.5.0 to have more validation before release. With a regular release 
cycle, features can go in at the beginning to have more time for 
catching bugs in them. I also agree with what Sean said below.


rb

On 12/17/2015 04:00 PM, Sean Busbey wrote:

On Thu, Dec 17, 2015 at 5:50 PM, Tony Kurc  wrote:


s/features/buxfixes/

On Thu, Dec 17, 2015 at 6:50 PM, Tony Kurc  wrote:


Is there a reason to not just cut a 0.5.0 instead of grafting 0.5.0
features onto 0.4.1?





This is a good question.

Some downstream users might have different change processes for a patch vs
minor release, so making a 0.4.1 that fixes what we determine to be a
substantial gap in the 0.4 line would be nice for them.

While we might be a young project now, it would be good to already have the
habit practiced for when we have more users in enterprise settings.

On the other hand, 0.4.0 just happened, so a release in 3 days would
minimize the number of "stuck on 0.4.0" folks.




--
Ryan Blue
Software Engineer
Cloudera, Inc.

Re: discuss nifi 0.4.1

[Tony Kurc]

I'm not sure I understand "more validation" reasoning - won't features at
the end have very little validation?

On Thu, Dec 17, 2015 at 7:26 PM, Ryan Blue  wrote:

> Another reason to release 0.4.1 is to allow the additions that warrant
> 0.5.0 to have more validation before release. With a regular release cycle,
> features can go in at the beginning to have more time for catching bugs in
> them. I also agree with what Sean said below.
>
> rb
>
> On 12/17/2015 04:00 PM, Sean Busbey wrote:
>
>> On Thu, Dec 17, 2015 at 5:50 PM, Tony Kurc  wrote:
>>
>> s/features/buxfixes/
>>>
>>> On Thu, Dec 17, 2015 at 6:50 PM, Tony Kurc  wrote:
>>>
>>> Is there a reason to not just cut a 0.5.0 instead of grafting 0.5.0
 features onto 0.4.1?


>>>
>> This is a good question.
>>
>> Some downstream users might have different change processes for a patch vs
>> minor release, so making a 0.4.1 that fixes what we determine to be a
>> substantial gap in the 0.4 line would be nice for them.
>>
>> While we might be a young project now, it would be good to already have
>> the
>> habit practiced for when we have more users in enterprise settings.
>>
>> On the other hand, 0.4.0 just happened, so a release in 3 days would
>> minimize the number of "stuck on 0.4.0" folks.
>>
>>
>
> --
> Ryan Blue
> Software Engineer
> Cloudera, Inc.
>

Re: discuss nifi 0.4.1

[Ryan Blue]

Yes, which affects when you time getting something into master. Larger 
features that are done just before a release (more risk) can get pushed 
so that they are committed after a release instead of just before one. 
Regular releases ensure the penalty for choosing to get into the next 
release aren't too high.


You could make the argument that master should always be in a releasable 
state, but I think that even when reviews are done right there is risk 
for some features. All I want to note is that a regular release cadence 
helps mitigate that risk when we stick to it.


rb

On 12/17/2015 04:32 PM, Tony Kurc wrote:

I'm not sure I understand "more validation" reasoning - won't features at
the end have very little validation?

On Thu, Dec 17, 2015 at 7:26 PM, Ryan Blue  wrote:


Another reason to release 0.4.1 is to allow the additions that warrant
0.5.0 to have more validation before release. With a regular release cycle,
features can go in at the beginning to have more time for catching bugs in
them. I also agree with what Sean said below.

rb

On 12/17/2015 04:00 PM, Sean Busbey wrote:


On Thu, Dec 17, 2015 at 5:50 PM, Tony Kurc  wrote:

s/features/buxfixes/


On Thu, Dec 17, 2015 at 6:50 PM, Tony Kurc  wrote:

Is there a reason to not just cut a 0.5.0 instead of grafting 0.5.0

features onto 0.4.1?





This is a good question.

Some downstream users might have different change processes for a patch vs
minor release, so making a 0.4.1 that fixes what we determine to be a
substantial gap in the 0.4 line would be nice for them.

While we might be a young project now, it would be good to already have
the
habit practiced for when we have more users in enterprise settings.

On the other hand, 0.4.0 just happened, so a release in 3 days would
minimize the number of "stuck on 0.4.0" folks.




--
Ryan Blue
Software Engineer
Cloudera, Inc.






--
Ryan Blue
Software Engineer
Cloudera, Inc.

Re: discuss nifi 0.4.1

[Sean Busbey]

On Thu, Dec 17, 2015 at 6:32 PM, Tony Kurc  wrote:

> I'm not sure I understand "more validation" reasoning - won't features at
> the end have very little validation?
>
> On Thu, Dec 17, 2015 at 7:26 PM, Ryan Blue  wrote:
>
> > Another reason to release 0.4.1 is to allow the additions that warrant
> > 0.5.0 to have more validation before release. With a regular release
> cycle,
> > features can go in at the beginning to have more time for catching bugs
> in
> > them. I also agree with what Sean said below.
> >
>

I presume Ryan just meant that the things that have gone in now would have
more time.

This is the current history since 0.4.0 branched for RC:

* 04e9606 - (HEAD, origin/master, origin/HEAD, master) NIFI-1290 Document th
* 7c87968 - NIFI-1218 addressed PR comments (29 hours ago)
* 3763523 - NIFI-1218 upgraded Kafka to 0.9.0.0 client API Tested and valida
* b19ff7c - NIFI-1215: - Only showing the run duration setting when applicab
* 51b8ecd - NIFI-1185: - Using banners from the NCM rather than replicating
* c75b5cf - NIFI-1119: - Addressing race condition that caused the revision
* 17be1c2 - NIFI-1206: - Only enabling the enable/disable toolbar icon when
* f9f0443 - NIFI-1119: - Also refreshing flow revision when the user clicks
*   a7b09a5 - NIFI-1122 release vote passess. Merge branch 'NIFI-1122_nifi-0
|\
| * d755e43 - (origin/NIFI-1122_nifi-0.4.0-RC2) NIFI-1122_nifi-0.4.0-RC2prep
| * b66c029 - (nifi-0.4.0-RC2, nifi-0.4.0) NIFI-1122_nifi-0.4.0-RC2prepare r
* | 8070a9f - NIFI-1104: - Using the appropriate attributes based on the con
* | 854c667 - NIFI-1211 Adding a .travis.yml to provide CI and adding an exc
|/
* fb65cf1 - NIFI-1271: Yield funnels and ports for nifi.bored.yield.duration

Nothing here gives me heartburn about 0.5.0 going out on short release
cycle.


-- 
Sean