public inbox for dwz@sourceware.org
 help / color / mirror / Atom feed
* dwz 0.14 release?
@ 2021-02-10 12:06 Mark Wielaard
  2021-02-11  9:15 ` Tom de Vries
  0 siblings, 1 reply; 12+ messages in thread
From: Mark Wielaard @ 2021-02-10 12:06 UTC (permalink / raw)
  To: dwz

Hi,

I was wondering what we still need to do to get a 0.14 release out?
It would be nice to release now that we support DWARF5 as GCC11 outputs
it by default now. There are some DWARF5 constructs we still don't
support, but they aren't really required because they are non-default.

The only real issue is the combination of DWARF5 and dwz --odr. We see
the following failures in the testsuite:

There are still failures with the ODR support when building the
testcases with -gdwarf-5, specifically:

FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-class-ns.sh
FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-def-decl.sh
FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-loc.sh
FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-struct.sh
FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-struct-ns.sh
FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-union.sh
FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-class.sh
FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-union-ns.sh

I haven't really investigated why that is. But we can always say
that ODR support is experimental and doesn't yet work for DWARF5.

Cheers,

Mark

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: dwz 0.14 release?
  2021-02-10 12:06 dwz 0.14 release? Mark Wielaard
@ 2021-02-11  9:15 ` Tom de Vries
  2021-02-12 10:08   ` Mark Wielaard
  0 siblings, 1 reply; 12+ messages in thread
From: Tom de Vries @ 2021-02-11  9:15 UTC (permalink / raw)
  To: Mark Wielaard, dwz

On 2/10/21 1:06 PM, Mark Wielaard wrote:
> Hi,
> 
> I was wondering what we still need to do to get a 0.14 release out?
> It would be nice to release now that we support DWARF5 as GCC11 outputs
> it by default now. There are some DWARF5 constructs we still don't
> support, but they aren't really required because they are non-default.
> 
> The only real issue is the combination of DWARF5 and dwz --odr. We see
> the following failures in the testsuite:
> 
> There are still failures with the ODR support when building the
> testcases with -gdwarf-5, specifically:
> 
> FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-class-ns.sh
> FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-def-decl.sh
> FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-loc.sh
> FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-struct.sh
> FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-struct-ns.sh
> FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-union.sh
> FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-class.sh
> FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-union-ns.sh
> 
> I haven't really investigated why that is. But we can always say
> that ODR support is experimental and doesn't yet work for DWARF5.

I can't reproduce this, can you open an PR with more details?

Anyway, odr will be experimental.  It still need to marked as such.

Furthermore, I still need to go through the PR list and clean up.

Thanks,
- Tom

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: dwz 0.14 release?
  2021-02-11  9:15 ` Tom de Vries
@ 2021-02-12 10:08   ` Mark Wielaard
  2021-02-19  1:16     ` Mark Wielaard
  0 siblings, 1 reply; 12+ messages in thread
From: Mark Wielaard @ 2021-02-12 10:08 UTC (permalink / raw)
  To: Tom de Vries, dwz

Hi Tom,

On Thu, 2021-02-11 at 10:15 +0100, Tom de Vries wrote:
> On 2/10/21 1:06 PM, Mark Wielaard wrote:
> > The only real issue is the combination of DWARF5 and dwz --odr. We
> > see the following failures in the testsuite:
> > 
> > There are still failures with the ODR support when building the
> > testcases with -gdwarf-5, specifically:
> > 
> > FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-class-ns.sh
> > FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-def-decl.sh
> > FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-loc.sh
> > FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-struct.sh
> > FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-struct-ns.sh
> > FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-union.sh
> > FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-class.sh
> > FAIL: /opt/local/src/dwz/testsuite/dwz.tests/odr-union-ns.sh
> > 
> > I haven't really investigated why that is. But we can always say
> > that ODR support is experimental and doesn't yet work for DWARF5.
> 
> I can't reproduce this, can you open an PR with more details?

https://sourceware.org/bugzilla/show_bug.cgi?id=27400
Let me know if you need any test binaries and I'll attach them to the
bug.

> Anyway, odr will be experimental.  It still need to marked as such.

Also opened a bug for that:
https://sourceware.org/bugzilla/show_bug.cgi?id=27401

And another to document the status of DWARF 5:
https://sourceware.org/bugzilla/show_bug.cgi?id=27402

I'll resolve that by updating dwz.1 with an overview of the current
support for DWARF 5 in dwz.

> Furthermore, I still need to go through the PR list and clean up.

We have about 50 open bugs. I can go through them and see if any of
them is a showstopper/regression since 0.13, but given that various
distros have switched to current git trunk already I think what we have
now is consistently better than 0.13. What would be the most convenient
to mark up the bugs?

Thanks,

Mark 

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: dwz 0.14 release?
  2021-02-12 10:08   ` Mark Wielaard
@ 2021-02-19  1:16     ` Mark Wielaard
  2021-02-26 23:37       ` Mark Wielaard
  0 siblings, 1 reply; 12+ messages in thread
From: Mark Wielaard @ 2021-02-19  1:16 UTC (permalink / raw)
  To: Tom de Vries, dwz

Hi Tom,

On Fri, Feb 12, 2021 at 11:08:42AM +0100, Mark Wielaard wrote:
> > > I haven't really investigated why that is. But we can always say
> > > that ODR support is experimental and doesn't yet work for DWARF5.
> > 
> > I can't reproduce this, can you open an PR with more details?
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=27400
> Let me know if you need any test binaries and I'll attach them to the
> bug.

So, this was fixed already. And we found some subtle other bugs.

> > Anyway, odr will be experimental.  It still need to marked as such.
> 
> Also opened a bug for that:
> https://sourceware.org/bugzilla/show_bug.cgi?id=27401
> 
> And another to document the status of DWARF 5:
> https://sourceware.org/bugzilla/show_bug.cgi?id=27402
> 
> I'll resolve that by updating dwz.1 with an overview of the current
> support for DWARF 5 in dwz.

I just pushed a patch for this.

> > Furthermore, I still need to go through the PR list and clean up.
> 
> We have about 50 open bugs. I can go through them and see if any of
> them is a showstopper/regression since 0.13, but given that various
> distros have switched to current git trunk already I think what we have
> now is consistently better than 0.13. What would be the most convenient
> to mark up the bugs?

There are 53 open bugs right now. I looked briefly at all of
them. Most are ideas for improvements of various forms. For more
optimizations or supporting certain DWARF constructs. A couple simply
don't have enough information to replicate the issue. Or are for
things that are hard to support, like the mips bug (26738) or the
emit-relocs issue (24345).

I don't believe any of the bugs are regressions since 0.13. But the
following 6 bugs seem good to take a quick look at to see if a fix is
easy, but none of them seem like real showstoppers for a
release. Since there are a lot of things fixed and new features since
0.13 I think we should do a release as soon as we know these aren't
fixed in a couple of days.

https://sourceware.org/bugzilla/show_bug.cgi?id=26252
[odr] dwz.c:11404: write_die: Assertion `value && refdcu->cu_kind != CU_ALT'
      failed. #2 
For which you just posted a patch.

https://sourceware.org/bugzilla/show_bug.cgi?id=24275
hardlink handling leaves temporary file if not file compressed
This is mostly an annoyance, but I haven't figured out the code to fix it.

https://sourceware.org/bugzilla/show_bug.cgi?id=27401
Document that the --odr flag is currently experimental
Would be nice to have documented what works and what still needs work
There are a couple of ODR bugs for which I didn't know the current
status, e.g. Bug 24198 (which is the tracker bug?)

https://sourceware.org/bugzilla/show_bug.cgi?id=27363
Emit more detailed diagnostic output for "Unknown DWARF" 
This has improved a bit. I don't think we need to go so far as the
reporter would like. But we could add a bit more output to some of the
errors like we did in commit 4705796eb "Add DIE offsets in error
messages to make it easier to find what is wrong."

https://sourceware.org/bugzilla/show_bug.cgi?id=25252
dwz: returns exit status 1, causing FTBFS in deal.ii
This seems partially fixed, but still has a patch that looks
plausible, but I don't really know if it is still needed.

https://sourceware.org/bugzilla/show_bug.cgi?id=25459
Forward pseudo-reference triggers error
Seems like a real issue. And has a test binary that triggers the
issue. On the other hand this test binary is slightly odd. It is
referenced in a couple of other bug reports, but it seems unclear how
it was ever generated. This might not be easily fixable without adding
a new pass over the whole DIE tree. Unless someone has a clever idea.

Cheers,

Mark

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: dwz 0.14 release?
  2021-02-19  1:16     ` Mark Wielaard
@ 2021-02-26 23:37       ` Mark Wielaard
  2021-03-01 10:49         ` tdevries
  0 siblings, 1 reply; 12+ messages in thread
From: Mark Wielaard @ 2021-02-26 23:37 UTC (permalink / raw)
  To: Tom de Vries, dwz

Hi,

I propose we do a release on Monday March 1. Unless people think there
are still some release critical issues that need to be resolved first.

On Fri, Feb 19, 2021 at 02:16:12AM +0100, Mark Wielaard wrote:
> There are 53 open bugs right now. I looked briefly at all of
> them. Most are ideas for improvements of various forms. For more
> optimizations or supporting certain DWARF constructs. A couple simply
> don't have enough information to replicate the issue. Or are for
> things that are hard to support, like the mips bug (26738) or the
> emit-relocs issue (24345).
> 
> I don't believe any of the bugs are regressions since 0.13. But the
> following 6 bugs seem good to take a quick look at to see if a fix is
> easy, but none of them seem like real showstoppers for a
> release. Since there are a lot of things fixed and new features since
> 0.13 I think we should do a release as soon as we know these aren't
> fixed in a couple of days.
> 
> https://sourceware.org/bugzilla/show_bug.cgi?id=26252
> [odr] dwz.c:11404: write_die: Assertion `value && refdcu->cu_kind != CU_ALT'
>       failed. #2 
> For which you just posted a patch.

This (and bug 25439) have been fixed by commit 3312feb17 "Fix CK_BAD
propagation for --odr".

> https://sourceware.org/bugzilla/show_bug.cgi?id=24275
> hardlink handling leaves temporary file if not file compressed
> This is mostly an annoyance, but I haven't figured out the code to fix it.

Status still the same.

> https://sourceware.org/bugzilla/show_bug.cgi?id=27401
> Document that the --odr flag is currently experimental
> Would be nice to have documented what works and what still needs work
> There are a couple of ODR bugs for which I didn't know the current
> status, e.g. Bug 24198 (which is the tracker bug?)

Documentation patch has been posted:
https://sourceware.org/pipermail/dwz/2021q1/000980.html

> https://sourceware.org/bugzilla/show_bug.cgi?id=27363
> Emit more detailed diagnostic output for "Unknown DWARF" 
> This has improved a bit. I don't think we need to go so far as the
> reporter would like. But we could add a bit more output to some of the
> errors like we did in commit 4705796eb "Add DIE offsets in error
> messages to make it easier to find what is wrong."

With another followup commit 1e2beb218 "Print abbrev or DIE offset for
Unknown DWARF error message". The error messages can still be
improved, so lets keep the bug open for now.

> https://sourceware.org/bugzilla/show_bug.cgi?id=25252
> dwz: returns exit status 1, causing FTBFS in deal.ii
> This seems partially fixed, but still has a patch that looks
> plausible, but I don't really know if it is still needed.

Unclear how to test this. So still open.

> https://sourceware.org/bugzilla/show_bug.cgi?id=25459
> Forward pseudo-reference triggers error
> Seems like a real issue. And has a test binary that triggers the
> issue. On the other hand this test binary is slightly odd. It is
> referenced in a couple of other bug reports, but it seems unclear how
> it was ever generated. This might not be easily fixable without adding
> a new pass over the whole DIE tree. Unless someone has a clever idea.

No updates.

Some other bugs updated since last Friday:

- https://sourceware.org/bugzilla/show_bug.cgi?id=27449
  dwz: 1: Unknown DWARF DW_OP_0
  Thanks to the new diagnostics tracked down to possible GCC bug.

- https://sourceware.org/bugzilla/show_bug.cgi?id=27463
  [dwz] Unhandled DW_FORM_sdata for DW_AT_decl_line
  Filed and fixed.

- https://sourceware.org/bugzilla/show_bug.cgi?id=27474
  [dwz] Report unknown dwarf problem only once
  Another request for better error diagnostics

- https://sourceware.org/bugzilla/show_bug.cgi?id=27438
  [dwz, odr, multifile] Multifile after odr not optimal
  Filed and fixed

- https://sourceware.org/bugzilla/show_bug.cgi?id=25398
  [dwz, fixed-needs-testcase] CU referenced from PU
  Patch posted, needs review:
  https://sourceware.org/pipermail/dwz/2021q1/000976.html

- https://sourceware.org/bugzilla/show_bug.cgi?id=25424
  CU referenced from PU (--odr-mode=link case)
  Patch posted, needs review:
  https://sourceware.org/pipermail/dwz/2021q1/000974.html

- https://sourceware.org/bugzilla/show_bug.cgi?id=27464
  CU referenced from PU (--odr-mode=link case) (bis)
  Patch posted, needs, review:
  https://sourceware.org/pipermail/dwz/2021q1/000975.html

- https://sourceware.org/bugzilla/show_bug.cgi?id=27466
  [dwz] Improve heuristics for odr
  New enhancement bug

- https://sourceware.org/bugzilla/show_bug.cgi?id=27429
  [dwz, testsuite] mode 4 in checksum_ref_die not exercised in test-suite
  Patch posted, needs review:
  https://sourceware.org/pipermail/dwz/2021q1/000957.html

- https://sourceware.org/bugzilla/show_bug.cgi?id=27440
  [dwz, dwarf5] Add --dwarf-5 flag to generate .debug_sup, ref_sup and
  strp_sup
  Implemented

- https://sourceware.org/bugzilla/show_bug.cgi?id=24978
  [dwz] Segmentation fault for two-files-too-many-dies-2.sh on
  arm-linux-gnueabihf with binutils trunk and gcc-9 branch
  Resolved, worksforme.

Cheers,

Mark

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: dwz 0.14 release?
  2021-02-26 23:37       ` Mark Wielaard
@ 2021-03-01 10:49         ` tdevries
  2021-03-01 11:17           ` Mark Wielaard
  2021-03-05  7:26           ` Tom de Vries
  0 siblings, 2 replies; 12+ messages in thread
From: tdevries @ 2021-03-01 10:49 UTC (permalink / raw)
  To: Mark Wielaard; +Cc: dwz

On 2021-02-27 00:37, Mark Wielaard wrote:
> Hi,
> 
> I propose we do a release on Monday March 1. Unless people think there
> are still some release critical issues that need to be resolved first.
> 

I'd like to postpone by a week.  I've cleaned up odr state, and now I'd 
like to spent some time on other issues.  In particular, I'd like to fix 
the temp file thingy.

Thanks,
- Tom

> On Fri, Feb 19, 2021 at 02:16:12AM +0100, Mark Wielaard wrote:
>> There are 53 open bugs right now. I looked briefly at all of
>> them. Most are ideas for improvements of various forms. For more
>> optimizations or supporting certain DWARF constructs. A couple simply
>> don't have enough information to replicate the issue. Or are for
>> things that are hard to support, like the mips bug (26738) or the
>> emit-relocs issue (24345).
>> 
>> I don't believe any of the bugs are regressions since 0.13. But the
>> following 6 bugs seem good to take a quick look at to see if a fix is
>> easy, but none of them seem like real showstoppers for a
>> release. Since there are a lot of things fixed and new features since
>> 0.13 I think we should do a release as soon as we know these aren't
>> fixed in a couple of days.
>> 
>> https://sourceware.org/bugzilla/show_bug.cgi?id=26252
>> [odr] dwz.c:11404: write_die: Assertion `value && refdcu->cu_kind != 
>> CU_ALT'
>>       failed. #2
>> For which you just posted a patch.
> 
> This (and bug 25439) have been fixed by commit 3312feb17 "Fix CK_BAD
> propagation for --odr".
> 
>> https://sourceware.org/bugzilla/show_bug.cgi?id=24275
>> hardlink handling leaves temporary file if not file compressed
>> This is mostly an annoyance, but I haven't figured out the code to fix 
>> it.
> 
> Status still the same.
> 
>> https://sourceware.org/bugzilla/show_bug.cgi?id=27401
>> Document that the --odr flag is currently experimental
>> Would be nice to have documented what works and what still needs work
>> There are a couple of ODR bugs for which I didn't know the current
>> status, e.g. Bug 24198 (which is the tracker bug?)
> 
> Documentation patch has been posted:
> https://sourceware.org/pipermail/dwz/2021q1/000980.html
> 
>> https://sourceware.org/bugzilla/show_bug.cgi?id=27363
>> Emit more detailed diagnostic output for "Unknown DWARF"
>> This has improved a bit. I don't think we need to go so far as the
>> reporter would like. But we could add a bit more output to some of the
>> errors like we did in commit 4705796eb "Add DIE offsets in error
>> messages to make it easier to find what is wrong."
> 
> With another followup commit 1e2beb218 "Print abbrev or DIE offset for
> Unknown DWARF error message". The error messages can still be
> improved, so lets keep the bug open for now.
> 
>> https://sourceware.org/bugzilla/show_bug.cgi?id=25252
>> dwz: returns exit status 1, causing FTBFS in deal.ii
>> This seems partially fixed, but still has a patch that looks
>> plausible, but I don't really know if it is still needed.
> 
> Unclear how to test this. So still open.
> 
>> https://sourceware.org/bugzilla/show_bug.cgi?id=25459
>> Forward pseudo-reference triggers error
>> Seems like a real issue. And has a test binary that triggers the
>> issue. On the other hand this test binary is slightly odd. It is
>> referenced in a couple of other bug reports, but it seems unclear how
>> it was ever generated. This might not be easily fixable without adding
>> a new pass over the whole DIE tree. Unless someone has a clever idea.
> 
> No updates.
> 
> Some other bugs updated since last Friday:
> 
> - https://sourceware.org/bugzilla/show_bug.cgi?id=27449
>   dwz: 1: Unknown DWARF DW_OP_0
>   Thanks to the new diagnostics tracked down to possible GCC bug.
> 
> - https://sourceware.org/bugzilla/show_bug.cgi?id=27463
>   [dwz] Unhandled DW_FORM_sdata for DW_AT_decl_line
>   Filed and fixed.
> 
> - https://sourceware.org/bugzilla/show_bug.cgi?id=27474
>   [dwz] Report unknown dwarf problem only once
>   Another request for better error diagnostics
> 
> - https://sourceware.org/bugzilla/show_bug.cgi?id=27438
>   [dwz, odr, multifile] Multifile after odr not optimal
>   Filed and fixed
> 
> - https://sourceware.org/bugzilla/show_bug.cgi?id=25398
>   [dwz, fixed-needs-testcase] CU referenced from PU
>   Patch posted, needs review:
>   https://sourceware.org/pipermail/dwz/2021q1/000976.html
> 
> - https://sourceware.org/bugzilla/show_bug.cgi?id=25424
>   CU referenced from PU (--odr-mode=link case)
>   Patch posted, needs review:
>   https://sourceware.org/pipermail/dwz/2021q1/000974.html
> 
> - https://sourceware.org/bugzilla/show_bug.cgi?id=27464
>   CU referenced from PU (--odr-mode=link case) (bis)
>   Patch posted, needs, review:
>   https://sourceware.org/pipermail/dwz/2021q1/000975.html
> 
> - https://sourceware.org/bugzilla/show_bug.cgi?id=27466
>   [dwz] Improve heuristics for odr
>   New enhancement bug
> 
> - https://sourceware.org/bugzilla/show_bug.cgi?id=27429
>   [dwz, testsuite] mode 4 in checksum_ref_die not exercised in 
> test-suite
>   Patch posted, needs review:
>   https://sourceware.org/pipermail/dwz/2021q1/000957.html
> 
> - https://sourceware.org/bugzilla/show_bug.cgi?id=27440
>   [dwz, dwarf5] Add --dwarf-5 flag to generate .debug_sup, ref_sup and
>   strp_sup
>   Implemented
> 
> - https://sourceware.org/bugzilla/show_bug.cgi?id=24978
>   [dwz] Segmentation fault for two-files-too-many-dies-2.sh on
>   arm-linux-gnueabihf with binutils trunk and gcc-9 branch
>   Resolved, worksforme.
> 
> Cheers,
> 
> Mark

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: dwz 0.14 release?
  2021-03-01 10:49         ` tdevries
@ 2021-03-01 11:17           ` Mark Wielaard
  2021-03-01 12:40             ` Tom de Vries
  2021-03-05  7:26           ` Tom de Vries
  1 sibling, 1 reply; 12+ messages in thread
From: Mark Wielaard @ 2021-03-01 11:17 UTC (permalink / raw)
  To: tdevries; +Cc: dwz

Hi Tom,

On Mon, 2021-03-01 at 11:49 +0100, tdevries wrote:
> On 2021-02-27 00:37, Mark Wielaard wrote:
> > I propose we do a release on Monday March 1. Unless people think
> > there
> > are still some release critical issues that need to be resolved first.
> 
> I'd like to postpone by a week.  I've cleaned up odr state, and now I'd 
> like to spent some time on other issues.  In particular, I'd like to fix 
> the temp file thingy.

OK, but could we then pick that as a concrete goal and date for the
release please? There have been requests for a 0.14 release since
January. I did try to make sure we had up to date lists of pending bugs
and I believe there are no regressions anymore. That doesn't mean we
cannot designate some existing bugs as release critical. The temp file
thingy (PR24275) does indeed seem nasty and it would be great to get it
fixed.

So shall we say that when PR24275 is fixed and no new release critical
issues (regressions) are found by Monday March 8, then we'll do a 0.14
release?

I am a little afraid we will simply never do a release because there is
always one more thing to hack on. And the last release was in August
2019. There have been lots of bugs fixed since then and some nice new
features added.

It would be good if we did regular (say every 3 or 6 months) releases.
Just to make sure people can upgrade and get the new bug fixes and
features more regularly without having to pick arbitrary git checkouts.

Thanks,

Mark

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: dwz 0.14 release?
  2021-03-01 11:17           ` Mark Wielaard
@ 2021-03-01 12:40             ` Tom de Vries
  0 siblings, 0 replies; 12+ messages in thread
From: Tom de Vries @ 2021-03-01 12:40 UTC (permalink / raw)
  To: Mark Wielaard; +Cc: dwz

On 3/1/21 12:17 PM, Mark Wielaard wrote:
> Hi Tom,
> 
> On Mon, 2021-03-01 at 11:49 +0100, tdevries wrote:
>> On 2021-02-27 00:37, Mark Wielaard wrote:
>>> I propose we do a release on Monday March 1. Unless people think
>>> there
>>> are still some release critical issues that need to be resolved first.
>>
>> I'd like to postpone by a week.  I've cleaned up odr state, and now I'd 
>> like to spent some time on other issues.  In particular, I'd like to fix 
>> the temp file thingy.
> 
> OK, but could we then pick that as a concrete goal and date for the
> release please?

Sure.

> There have been requests for a 0.14 release since
> January.

Ahem...  for much longer actually ;)

> I did try to make sure we had up to date lists of pending bugs
> and I believe there are no regressions anymore. That doesn't mean we
> cannot designate some existing bugs as release critical. The temp file
> thingy (PR24275) does indeed seem nasty and it would be great to get it
> fixed.

Yeah, it still gets reported by package maintainers, so I'd really like
to fix this.  I already have a tentative patch (on top of trunk).

> So shall we say that when PR24275 is fixed and no new release critical
> issues (regressions) are found by Monday March 8, then we'll do a 0.14
> release?
> 

Sounds good.

> I am a little afraid we will simply never do a release because there is
> always one more thing to hack on. And the last release was in August
> 2019. There have been lots of bugs fixed since then and some nice new
> features added.
> 

I agree that it's good to do a release now-ish.  I also expect to run
out of dwz-hack-time in a week, so I'm not so afraid of the keep-hacking
scenario.

> It would be good if we did regular (say every 3 or 6 months) releases.
> Just to make sure people can upgrade and get the new bug fixes and
> features more regularly without having to pick arbitrary git checkouts.

Agreed, regular release are good (though dwz hacking has tended to
happen in rare bursts, so it may not always make sense).  Anyway, I
intended to do a release long ago, but got all tied up in the odr stuff
instead. So thanks for driving this, much appreciated :)

Thanks,
- Tom

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: dwz 0.14 release?
  2021-03-01 10:49         ` tdevries
  2021-03-01 11:17           ` Mark Wielaard
@ 2021-03-05  7:26           ` Tom de Vries
  2021-03-05 16:24             ` Tom de Vries
  1 sibling, 1 reply; 12+ messages in thread
From: Tom de Vries @ 2021-03-05  7:26 UTC (permalink / raw)
  To: Mark Wielaard; +Cc: dwz

On 3/1/21 11:49 AM, tdevries wrote:
> On 2021-02-27 00:37, Mark Wielaard wrote:
>> Hi,
>>
>> I propose we do a release on Monday March 1. Unless people think there
>> are still some release critical issues that need to be resolved first.
>>
> 
> I'd like to postpone by a week.  I've cleaned up odr state, and now I'd
> like to spent some time on other issues.  In particular, I'd like to fix
> the temp file thingy.
> 

That's fixed now.

I've done some more bugzilla enhancement marking, now the only
non-enhancement open PRs are:
- PR24441 - Some crashes found by fuzzing
- PR25459 - Forward pseudo-reference triggers error

AFAIC, from the open PR perspective, we're good for the release.

I'll do one more round of gdb testing against dwz, and then hopefully we
can release on Monday.

Thanks,
- Tom

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: dwz 0.14 release?
  2021-03-05  7:26           ` Tom de Vries
@ 2021-03-05 16:24             ` Tom de Vries
  2021-03-08  7:14               ` Tom de Vries
  0 siblings, 1 reply; 12+ messages in thread
From: Tom de Vries @ 2021-03-05 16:24 UTC (permalink / raw)
  To: Mark Wielaard; +Cc: dwz

On 3/5/21 8:26 AM, Tom de Vries wrote:
> On 3/1/21 11:49 AM, tdevries wrote:
>> On 2021-02-27 00:37, Mark Wielaard wrote:
>>> Hi,
>>>
>>> I propose we do a release on Monday March 1. Unless people think there
>>> are still some release critical issues that need to be resolved first.
>>>
>>
>> I'd like to postpone by a week.  I've cleaned up odr state, and now I'd
>> like to spent some time on other issues.  In particular, I'd like to fix
>> the temp file thingy.
>>
> 
> That's fixed now.
> 
> I've done some more bugzilla enhancement marking, now the only
> non-enhancement open PRs are:
> - PR24441 - Some crashes found by fuzzing
> - PR25459 - Forward pseudo-reference triggers error
> 
> AFAIC, from the open PR perspective, we're good for the release.
> 
> I'll do one more round of gdb testing against dwz, and then hopefully we
> can release on Monday.

That's done, I've tested against both target boards cc-with-dwz and
cc-with-dwz-m.  No regressions found.

Thanks,
- Tom

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: dwz 0.14 release?
  2021-03-05 16:24             ` Tom de Vries
@ 2021-03-08  7:14               ` Tom de Vries
  2021-03-08  7:22                 ` Mark Wielaard
  0 siblings, 1 reply; 12+ messages in thread
From: Tom de Vries @ 2021-03-08  7:14 UTC (permalink / raw)
  To: Mark Wielaard; +Cc: dwz

On 3/5/21 5:24 PM, Tom de Vries wrote:
> On 3/5/21 8:26 AM, Tom de Vries wrote:
>> On 3/1/21 11:49 AM, tdevries wrote:
>>> On 2021-02-27 00:37, Mark Wielaard wrote:
>>>> Hi,
>>>>
>>>> I propose we do a release on Monday March 1. Unless people think there
>>>> are still some release critical issues that need to be resolved first.
>>>>
>>>
>>> I'd like to postpone by a week.  I've cleaned up odr state, and now I'd
>>> like to spent some time on other issues.  In particular, I'd like to fix
>>> the temp file thingy.
>>>
>>
>> That's fixed now.
>>
>> I've done some more bugzilla enhancement marking, now the only
>> non-enhancement open PRs are:
>> - PR24441 - Some crashes found by fuzzing
>> - PR25459 - Forward pseudo-reference triggers error
>>
>> AFAIC, from the open PR perspective, we're good for the release.
>>
>> I'll do one more round of gdb testing against dwz, and then hopefully we
>> can release on Monday.
> 
> That's done, I've tested against both target boards cc-with-dwz and
> cc-with-dwz-m.  No regressions found.

I've done a review of copyright in the toplevel files.  AFAICT, that
looks good.

I can do the release (that is, running the scripts in contrib/release/*
and drafting release announcement).  OK, or does anybody else want to do
that?

Thanks,
- Tom

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: dwz 0.14 release?
  2021-03-08  7:14               ` Tom de Vries
@ 2021-03-08  7:22                 ` Mark Wielaard
  0 siblings, 0 replies; 12+ messages in thread
From: Mark Wielaard @ 2021-03-08  7:22 UTC (permalink / raw)
  To: Tom de Vries; +Cc: dwz


Hi Tom,

Tom de Vries wrote:
> On 3/5/21 5:24 PM, Tom de Vries wrote:
>> On 3/5/21 8:26 AM, Tom de Vries wrote:
>>> AFAIC, from the open PR perspective, we're good for the release.
>>>
>>> I'll do one more round of gdb testing against dwz, and then hopefully we
>>> can release on Monday.
>>
>> That's done, I've tested against both target boards cc-with-dwz and
>> cc-with-dwz-m.  No regressions found.
>
> I've done a review of copyright in the toplevel files.  AFAICT, that
> looks good.

Things look good for a release.

> I can do the release (that is, running the scripts in contrib/release/*
> and drafting release announcement).  OK, or does anybody else want to do
> that?

Whatever is most convenient for you. If you like me to do it just ask.

Thanks,

Mark

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2021-03-08  7:22 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-02-10 12:06 dwz 0.14 release? Mark Wielaard
2021-02-11  9:15 ` Tom de Vries
2021-02-12 10:08   ` Mark Wielaard
2021-02-19  1:16     ` Mark Wielaard
2021-02-26 23:37       ` Mark Wielaard
2021-03-01 10:49         ` tdevries
2021-03-01 11:17           ` Mark Wielaard
2021-03-01 12:40             ` Tom de Vries
2021-03-05  7:26           ` Tom de Vries
2021-03-05 16:24             ` Tom de Vries
2021-03-08  7:14               ` Tom de Vries
2021-03-08  7:22                 ` Mark Wielaard

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).