This was an easy fix. Once this gets merged I believe we have direction to move forward with 3.3.0 release process.
Who would like to be release manager? On Mon, Mar 14, 2022 at 6:06 PM Mike Beckerle <[email protected]> wrote: > So the 3 blocking issues have been fixed/merged. > > However, of several bugs found over the last few days, this one is quite > problematic: > > https://issues.apache.org/jira/browse/DAFFODIL-2673 > > I am going to try to fix this in the next day, and if it proves to be > harder than that, postpone it until post 3.3.0. > > > > On Fri, Mar 11, 2022 at 10:37 AM Steve Lawrence <[email protected]> > wrote: > >> Agreed. +1 to start the release processes once these are resolved. >> >> On 3/10/22 6:05 PM, Interrante, John A (GE Research, US) wrote: >> > Fixing these 3 tickets seems sufficient to me. >> > >> > -----Original Message----- >> > From: Mike Beckerle <[email protected]> >> > Sent: Wednesday, March 9, 2022 6:00 PM >> > To: [email protected] >> > Subject: EXT: Re: [DISCUSS] need to release Daffodil 3.3.0 >> > >> > Once the revert/fix for regressions is merged, I think we're down to >> just these 3 tickets as really critical for Daffodil 3.3.0 release: >> > >> > DAFFODIL-2652 <https://issues.apache.org/jira/browse/DAFFODIL-2652> - >> Ability to disable all alignment >> > >> > Given the number of outstanding bugs associated with unparser deadlock >> and alignment I think this feature is an important hedge allowing progress >> to be made by schema authors even if they run into these unparser/alignment >> related issues (like DAFFODIL-2662 or DAFFODIL-2666 which are hard to fix, >> and I think we don't want to hold back the release for those fixes because >> they will take a while.) >> > >> > DAFFODIL-2650 <https://issues.apache.org/jira/browse/DAFFODIL-2650> - >> using config file with cli parse or save parser causes backtrace >> > >> > Major usability issue when dealing with DFDL schemas that issue many >> warnings. >> > >> > DAFFODIL-2267 <https://issues.apache.org/jira/browse/DAFFODIL-2267> - >> Warnings emitted on pre-compiled parsers >> > >> > Major usability issue when dealing with DFDL schemas that issue many >> warnings in deployed Daffodil-based applications. Clutters the log with too >> many things users have to know can be ignored. >> > >> > I will say these latter 2 bugs have been a huge pain in the neck to me >> of late in debugging efforts associated with some DFDL schema work. They >> just so clutter the output that you really can't see what is going on >> sometimes. >> > >> > Thoughts? Is fixing these enough for us to do a release of 3.3.0 ? >> > >> > On Wed, Mar 9, 2022 at 2:06 PM Mike Beckerle <[email protected]> >> wrote: >> > >> >> I just opened a PR which reverts a change which fixed a bug >> >> (DAFFODIL-2626), but caused a number of regressions detected only by >> >> other DFDL schemas such as NITF. (DAFFODIL-2666 and DAFFODIL-2662 are >> >> regressions it caused.) >> >> >> >> The original bug is preferable to these regressions. >> >> >> >> This will get us closer to a releasable 3.3.0. >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Mar 2, 2022 at 2:12 PM Mike Beckerle <[email protected]> >> wrote: >> >> >> >>> I've marked all the alignment/cyclic-deadlock regressions as blockers >> >>> for >> >>> 3.3.0 along with the "hammer" to >> >>> just turn off alignment. >> >>> >> >>> The fixing suggested in the thread here may be the fix, or the >> "hammer" >> >>> fix, but the regressions on unparsing have to be addressed in 3.3.0, >> >>> i.e., asap, before we can release it. >> >>> >> >>> I think other things we "almost" got working, like prefixed length >> >>> fixes (of various bugs) could wait for a later release. >> >>> >> >>> There are numerous user projects I know about that are depending on >> >>> 3.3.0 coming out quite soon now, without regressions. >> >>> >> >>> >> >>> On Wed, Feb 23, 2022 at 11:19 AM Steve Lawrence >> >>> <[email protected]> >> >>> wrote: >> >>> >> >>>> I assume this is caused by alignment regions not getting optimized >> >>>> out with the recent changes to the alignment algorithm. It's now >> >>>> more correct, but it's more pessimistic. >> >>>> >> >>>> A hammer to just disable alignment might be a reasonable solution, >> >>>> but I'd be concerned there are alignment regions that are needed, >> >>>> it's not usually obvious, especially in complex schemas. >> >>>> >> >>>> I think the main change that causes regions to fail to optimize out >> >>>> is that we can't optimize out alignment related to global >> >>>> declarations because we don't know the alignment of the references. >> >>>> >> >>>> I added comments in >> >>>> https://issues.apache.org/jira/browse/DAFFODIL-2626 >> >>>> that discuss this issue, and a potential fixe. I believe we just >> >>>> need to require that alignment of global decl's to be the same as >> >>>> their references. I hope that this would allow more optimization of >> >>>> alignment regions. One issue was raised about global complexType's, >> >>>> who's alignment only comes from the references, with no information >> >>>> on the declaration. So that also causes issues with this approach. >> >>>> >> >>>> I think implementing one or both of these options as tunables might >> >>>> help improve the alignment issue and would be reasonable to get in >> 3.3.0. >> >>>> >> >>>> >> >>>> On 2/23/22 11:08 AM, Mike Beckerle wrote: >> >>>>> So, we seem to be seeing a lot of regressions in various DFDL >> >>>>> schemas >> >>>> like >> >>>>> most recently NITF, previously PNG. >> >>>>> >> >>>>> What if users run into this in their own DFDL schemas? >> >>>>> >> >>>>> These are showing unparser deadlocks due to cyclic relationships. >> >>>>> At >> >>>> one >> >>>>> time we discussed adding a "big hammer" property or tunable that >> >>>>> simply turns off alignment, as a workaround for all these sorts of >> >>>>> alignment issues. I am wondering if we will need that so that >> >>>>> users can work >> >>>> around >> >>>>> these alignment issues in their schemas. >> >>>>> >> >>>>> Changing these schemas for 3.3.0 compatibility is highly >> >>>>> undesirable >> >>>> (as >> >>>>> was done for PNG), even if the changes are backward compatible. >> >>>>> >> >>>>> (Though if the schemas are actually incorrect in some way that >> >>>>> we're >> >>>> now >> >>>>> detecting more effectively, that is the right fix.) >> >>>>> >> >>>>> >> >>>>> >> >>>>> On Tue, Feb 22, 2022 at 11:38 AM Interrante, John A (GE Research, >> >>>>> US) < [email protected]> wrote: >> >>>>> >> >>>>>> +1 >> >>>>>> >> >>>>>> I personally have no blocker or urgent issues that must be fixed >> >>>> before >> >>>>>> the next release (only some things I will need to start working >> >>>>>> on in >> >>>> the C >> >>>>>> backend, "Runtime 2," to handle some more complicated schemas). >> >>>>>> >> >>>>>> How will the roadmap for upcoming releases ( >> >>>>>> >> >>>> https://cwiki.apache.org/confluence/display/DAFFODIL/Roadmap+for+Upc >> >>>> oming+Releases >> >>>> ) >> >>>>>> change as a result of 3.3.0 being released asap? >> >>>>>> >> >>>>>> John >> >>>>>> >> >>>>>> -----Original Message----- >> >>>>>> From: Mike Beckerle <[email protected]> >> >>>>>> Sent: Tuesday, February 22, 2022 10:44 AM >> >>>>>> To: [email protected] >> >>>>>> Subject: EXT: [DISCUSS] need to release Daffodil 3.3.0 >> >>>>>> >> >>>>>> WARNING: This email originated from outside of GE. Please >> >>>>>> validate the sender's email address before clicking on links or >> >>>>>> attachments as >> >>>> they may >> >>>>>> not be safe. >> >>>>>> >> >>>>>> A number of people are asking for 3.3.0, with its many bug fixes, >> >>>>>> to >> >>>> be >> >>>>>> released asap. >> >>>>>> >> >>>>>> Are there any remaining issues that must be fixed before this >> release? >> >>>>>> >> >>>>>> Otherwise I'd like to suggest we release 3.3.0. >> >>>>>> >> >>>>> >> >>>> >> >>>> >> >>
