Re: discuss nifi 0.4.1
all - as you can see the RC vote thread is out. I'll send the customary vote thread helper e-mail in a sec. Oleg - i am pretty sure i captured your two kafka patches properly but if you can verify they look good on the ticket that would be great. Thanks Joe On Sat, Dec 19, 2015 at 8:09 AM, Oleg Zhurakousky wrote: > 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
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
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
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
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
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
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
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
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
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
Re: discuss nifi 0.4.1
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
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
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
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
Re: discuss nifi 0.4.1
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
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
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
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
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. > >> > > > > >
Re: discuss nifi 0.4.1
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
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
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
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.
discuss nifi 0.4.1
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