Ok, all the critical issues for 3.3.0 are fixed now. Any volunteers for release manager?
On Mon, Mar 14, 2022 at 7:24 PM Mike Beckerle <[email protected]> wrote: > 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. >>> >>>>>> >>> >>>>> >>> >>>> >>> >>>> >>> >>>
